From murdoch at stats.uwo.ca  Thu May  5 14:07:47 2005
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Thu May  5 14:07:32 2005
Subject: [Rd] documenation for arrows() is backwards (PR#7839)
In-Reply-To: <x2mzralymp.fsf@turmalin.kubism.ku.dk>
References: <20050505104043.57151A1FA@slim.kubism.ku.dk>
	<x2mzralymp.fsf@turmalin.kubism.ku.dk>
Message-ID: <427A0C93.4050606@stats.uwo.ca>

Peter Dalgaard wrote:
> hoffman.mm+R-project.org@ebi.ac.uk writes:
> 
> 
>>Full_Name: Michael Hoffman
>>Version: 2.1.0
>>OS: Linux (Fedora Core 3, kernel 2.6.11-1.14_FC3)
>>Submission from: (NULL) (193.62.199.8)
>>
>>
>>help(arrows) says:
>>
>>"""
>>     arrows(x0, y0, x1, y1, length = 0.25, angle = 30, code = 2,
>>            col = par("fg"), lty = NULL, lwd = par("lwd"), xpd = NULL)
>>
>>...
>>
>>     If 'code=2' an arrowhead is drawn at '(x0[i],y0[i])' and if
>>     'code=1' an arrowhead is drawn at '(x1[i],y1[i])'.  If 'code=3' a
>>     head is drawn at both ends of the arrow.  Unless 'length = 0',
>>     when no head is drawn.
>>"""
>>
>>If you do:
>>
>>plot(c(-1, 1), c(-1, 1), col=0)
>>arrows(x0=0, y0=0, x1=0, y1=1, code=2)
>>
>>it is pretty clear that the arrowhead is drawn at x1, y1 with code=2. If you
>>switch to code=1, the arrowhead is drawn at x0, y0. Either the documentation or
>>the function is incorrect.
> 
> 
> One way to decide is to compare with Splus. Now that doesn't have a
> 'code' argument and the arguments are named x1,y1,x2,y2 (I wonder why
> R wanted to be different here?), but they do put the arrowheads at the
> *to* end, which does seem to be the sensible thing to do. 
> 
> Arguably, using 'code=2' as the default is a bit weird, 

An argument for the current encoding is that it encodes arrowhead end in 
the bits of code:  00 = no arrowhead, 01 = arrowhead at origin, 10 = 
arrowhead at destination, 11 = arrowhead at both.

 > but changing
 > it could be quite painful. I.e., we should fix the docs.

Yes, definitely.

> BTW, the docs also might say that code=0 makes arrows behave like
> segments(). It is also a bit strange that the code argument isn't
> vectorized, which might have been useful. 

Yes, that would be a reasonable change.

Duncan


[Rd] documenation for arrows() is backwards (PR#7839)
Duncan Murdoch