xy.coords

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

xy.coords

Gabor Grothendieck
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) .

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Gabor Grothendieck
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.

On 12/31/05, Duncan Murdoch <[hidden email]> 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
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
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 <[hidden email]> 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
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Gabor Grothendieck
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.

On 12/31/05, Duncan Murdoch <[hidden email]> 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 <[hidden email]> 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
> >>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
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 <[hidden email]> 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 <[hidden email]> 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
>>>>
>>
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Gabor Grothendieck
It does not achieve design consistency.  One would have to
specify NULL but that should not really be necessary.

On 12/31/05, Duncan Murdoch <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>>
> >>
> >>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>
>>>>
>>>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Gabor Grothendieck
I think this is just playng with words.  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.


On 12/31/05, Duncan Murdoch <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>>>>
> >>>>
> >>>>
> >>
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
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.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>______________________________________________
>>>[hidden email] mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Gabor Grothendieck
On 12/31/05, Duncan Murdoch <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>______________________________________________
> >>>[hidden email] mailing list
> >>>https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: xy.coords

Duncan Murdoch
On 12/31/2005 4:09 PM, Gabor Grothendieck wrote:

> On 12/31/05, Duncan Murdoch <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>______________________________________________
>>>>>[hidden email] mailing list
>>>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>>
>>>______________________________________________
>>>[hidden email] mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel