[Rd] xy.coords

[Duncan Murdoch]

On 12/31/2005 4:09 PM, Gabor Grothendieck wrote:
> 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.

Generally I agree, but I've just committed the doc change only, for 
these reasons:

  - xy.coords is likely to be used by high-level plot functions that 
have  inputs like plot.default; if they follow its pattern closely, then 
they'll never need a one-parameter call.  This will encourage consistency.

  - the interface to those functions has been unchanged for years, and I 
don't like changing old interfaces without strong reasons.

This was really a borderline case, but the fact that I couldn't think of 
a situation where it would be good to use a one parameter call to 
xy.coords tipped the balance in my mind.

Duncan Murdoch


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