From ggrothendieck at gmail.com  Sat Dec 31 22:09:01 2005
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Sat, 31 Dec 2005 16:09:01 -0500
Subject: [Rd] xy.coords
In-Reply-To: <43B6EC80.7080202@stats.uwo.ca>
References: <971536df0512301910k1e98e8e9pd4aa00149fedf1af@mail.gmail.com>
	<43B68554.9030505@stats.uwo.ca>
	<971536df0512310557l1e3ea702ic9f4444b7583f4a7@mail.gmail.com>
	<43B6B983.1060408@stats.uwo.ca>
	<971536df0512310921g43f340e6ufec047b7c07f53da@mail.gmail.com>
	<43B6C44A.10103@stats.uwo.ca>
	<971536df0512310957y750d8eb7oa23f38aa39db647c@mail.gmail.com>
	<43B6CD5B.4040307@stats.uwo.ca>
	<971536df0512311226r1b9817a1q206bbe1a72a7d800@mail.gmail.com>
	<43B6EC80.7080202@stats.uwo.ca>
Message-ID: <971536df0512311309v1d39103am90f10759932e509c@mail.gmail.com>

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
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>______________________________________________
> >>>R-devel at r-project.org mailing list
> >>>https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



[Rd] xy.coords
Gabor Grothendieck