xy.coords

On 12/31/05, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 12/31/2005 3:26 PM, Gabor Grothendieck wrote:

I think this is just playng with words.

I'm starting to be convinced of that by the fact that you haven't posted
any sample code where using a single parameter would be desirable.

Loose coupling is a general principle that should be followed as a matter
of course and does not need case by case justification.  If there were
a performance issue, say, one might justify circumventing
otherwise desirable principles but there is no conflicting tradeoff here.

The fact that its always been

like that is not sufficient and is not related to consistency.
xyz.coords also does not work in accordance with the help file
so the fact that the error extends to it just means they are both
in error.

Modularity means loose coupling -- i.e. a function should be
as independent as possible from its surroundings.  The fact
that the second argument is not missing in uses within R base
is not a valid argument for appropriate attention to this principle.

Furthermore, its clear that the current way it works is not even
the intended way -- the intended and better way is as documented
and the software, not the documentation, ought to be changed.

Take a look at the examples.  It's pretty clear that it is working as
intended, and the documentation incorrectly says "missing" where it
means "NULL".

Duncan Murdoch

On 12/31/05, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 12/31/2005 12:57 PM, Gabor Grothendieck wrote:

It does not achieve design consistency.

It's consistent with the way it has been for at least 7 years, and is
consistent with xyz.coords().

One would have to

specify NULL but that should not really be necessary.

In fact, one almost never needs to specify NULL there.  It's the default
value for y in the high level functions that call xy.coords, so it is
put there automatically.

Duncan Murdoch

On 12/31/05, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 12/31/2005 12:21 PM, Gabor Grothendieck wrote:

I think the point is that (1) it does not work as documented and (2) in
most functions one can omit unnecessary args without having
to specify NULL so its behvaior seems inconsistent from a design
viewpoint.  By allowing either missing or NULL it will work as documented,
and probably intended, yet continue to be backward compatible with
existing usages.

But a simpler change is to change the documentation, and it achieves all
of those objectives.

Duncan Murdoch

On 12/31/05, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 12/31/2005 8:57 AM, Gabor Grothendieck wrote:

It could be changed to missing(y) || is.null(y) and the docs amended.
That way existing code will continue to work and code that otherwise
gives an error currently, but should have worked, will now work too.

Can you give an example where you would want to use xy.coords(y ~ x)?
Normally xy.coords() is used in other functions, and they can default y
to NULL (see plot.default, for example).

Duncan Murdoch

On 12/31/05, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

On 12/30/2005 10:10 PM, Gabor Grothendieck wrote:

In ?xy.coords it says:

If 'y' is missing and 'x' is a

formula: of the form 'yvar ~ xvar'. 'xvar' and 'yvar' are used as
     x and y variables.

list: containing components 'x' and 'y', these are used to define
     plotting coordinates.

time series: the x values are taken to be 'time(x)' and the y
     values to be the time series.

matrix with two columns: the first is assumed to contain the x
     values and the second the y values.

however, in fact, if y is missing an error is given. e.g.

x <- 1:3
y <- 4:6
xy.coords(y ~ x) # error
xy.coords(cbind(x, y)) # error
xy.coords(ts(y)) # error

Looking at the code, is.null(y) in the first line of the
body should be missing(y) .

It would be better to change the docs to say "if 'y' is NULL ...".  The
code has been the way it is for years and years, and is widely used.

Changing the test to missing(y) would mean all existing uses that put a
NULL there would need to be changed.

Adding a default value of NULL to y would have less impact, but I'd
still be worried about it having long-range bad effects.

Duncan Murdoch