[Moved to R-devel, where it probably should have started and it is
getting to C-level functions now.]
abline is not 'misbehaving' (don't be rude about the work of
volunteers who are in your audience), but behaving in the same way as
other graphics calls.
The real story is this (and R is Open Source, so you can read the code
too).
Most base graphics functions call GClip to set the graphics clip state
before drawing). GClip only does anything if the xpd state has
changed since the last time it was used, and in the case of a plot
like this with axes which were drawn in the margins, it has done so.
Now, the tricky bit is 'was used', which can be very hard to
determine. Just setting the par is not enough: it has to be 'used'.
What I have done in R-devel is make clip() 'use' xpd, and that will
ensure that the clip region it sets persists until xpd is next
changed. There the example works as I believe you intended.
On Sat, 24 Jan 2009, Greg Snow wrote:
> This is a known issue, the documentation of clip talks about some plotting
functions resetting the clipping region and some don't. abline is
apparently one of those that plots first, then resets the clipping region (so
the first time it doesn't acknowledge it, but does afterwards). The
function clipplot in the TeachingDemos package uses a similar kludge to what you
do below (and I guess that puts my standing in the hall of fame at even higher
risk than yours) except that it uses the box function with a transparent box to
reset the clipping region, which means that you get strange boxes if your
graphics device does not handle transparency. It was a question like yours that
I asked in order to try to eliminate the kludge from clipplot that originally
lead to the clip function being added, and it does cover the initial cases that
I asked about.
>
> In order to change things to work like we would like (always resetting the
clipping region at the appropriate place so that clip always does what we
expect) will probably require going through every basic command that could put
something into the plot and figure out exactly when to have them reset the
clipping region (which may not be a simple decision, doing it too early may
break existing code). The amount of tedious work required for not much return
places this fairly low on the priority list, especially when there is a work
around (as you have found), even if it feels like a bit of a kludge.
>
> So while this probably does not fix your problem, at least hopefully this
helps you understand a bit more of what is happening here, and at least you know
that you are not alone in hall of kludge infamy.
>
> --
> Gregory (Greg) L. Snow Ph.D.
> Statistical Data Center
> Intermountain Healthcare
> greg.snow at imail.org
> 801.408.8111
>
>
>> -----Original Message-----
>> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-
>> project.org] On Behalf Of Jim Lemon
>> Sent: Saturday, January 24, 2009 2:51 AM
>> To: r-help at r-project.org
>> Subject: [R] Is abline misbehaving?
>>
>> Hi experts,
>> I was graciously offered a function to enhance abline by restricting
>> the
>> extent of the line to less than the plotting region. This seems a
>> useful
>> idea, and it looked like the easiest way to program it was to set up a
>> clipping region with "clip", draw the abline and then restore
the
>> previous clipping region. Let us call this function ablineclip. After
>> quite a bit of testing, I have found that the first call to ablineclip
>> ignores the clipping region. It's not that simple. Successive calls
to
>> ablineclip respect the clipping region, even if it changes. I can
>> reproduce the behavior like this:
>>
>> plot(-3:3,-3:3)
>> clip(-2,2,-2,2)
>> abline(v=0)
>> clip(-2,2,-2,2)
>> abline(h=0)
>>
>>
>> The first abline ignores the clip, the second respects it. I have
>> programmed around this, with the pathetic kludge of calling
"abline"
>> with a line outside the plotting area, calling "clip" a
second time,
>> and
>> then calling "abline" with the line that was requested. While
this
>> works, my place in programming history will be ineradicably compromised
>> if the Programmers' Hall of Fame ever finds out. Any suggestions?
>>
>> R-2.7.2
>> FC9 Linux
>>
>> Jim
>>
>> ______________________________________________
>> R-help at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-
>> guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595