Re: [Rd] xy.coords
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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Collaborator Wanted: permutation test package
Recent simulation findings reveal that permutation tests are more powerful than ANOV when data are drawn from non-normal populations such as mixtures of normals or Weibull distributions. I would like to offer my code in package form and am looking for a collaborator who will: a. verify results b. simplify code where appropriate c. suggest option format for routines c. help me offer code in package form Phillip Good Huntington Beach CA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@r-project.org mailing list >>>https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo
[Rd] New R folder names bring out Windows batch file bug
Just wanted to point out to anyone trying to write Windows
batch files that the new R-whatever folder names bring out
a bug in Windows batch files related to short file names.
In particular, this code (which is to the best of my understanding,
valid) gives an error. The solution appears to be to use long file
names, and make sure you quote them, rather than short ones.
That does require that R be able to handle such long names and
I think R does, in fact, handle them but at one time it did not in
all cases so use of short file names is likely just a workaround
from older times. This does not affect R itself as far as I know
but did affect my batchfiles which I have revised. I am using
Windows XP.
C:\>set apath=\Program Files\R\R-2.2.1
C:\>for /f "delims=" %a in ("%apath%") do set AA=%~sa
C:\>set aa
AA=C:\PROGRA~1\R\R-22~1.1.2.1
C:\>cd %aa%
The system cannot find the path specified.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New R folder names bring out Windows batch file bug
On 12/31/2005 3:59 PM, Gabor Grothendieck wrote:
> Just wanted to point out to anyone trying to write Windows
> batch files that the new R-whatever folder names bring out
> a bug in Windows batch files related to short file names.
>
> In particular, this code (which is to the best of my understanding,
> valid) gives an error. The solution appears to be to use long file
> names, and make sure you quote them, rather than short ones.
> That does require that R be able to handle such long names and
> I think R does, in fact, handle them but at one time it did not in
> all cases so use of short file names is likely just a workaround
> from older times. This does not affect R itself as far as I know
> but did affect my batchfiles which I have revised. I am using
> Windows XP.
>
>C:\>set apath=\Program Files\R\R-2.2.1
>C:\>for /f "delims=" %a in ("%apath%") do set AA=%~sa
>C:\>set aa
>AA=C:\PROGRA~1\R\R-22~1.1.2.1
>C:\>cd %aa%
>The system cannot find the path specified.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Please let us know Microsoft's response to your bug report.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 chan
Re: [Rd] New R folder names bring out Windows batch file bug
Although I independently discovered this bug; its apparently
well known to the experts. I asked about it on the batch
newsgroup and those knowledgable on this immediately identified
it as such. I think all one can do is work around it.
On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 12/31/2005 3:59 PM, Gabor Grothendieck wrote:
> > Just wanted to point out to anyone trying to write Windows
> > batch files that the new R-whatever folder names bring out
> > a bug in Windows batch files related to short file names.
> >
> > In particular, this code (which is to the best of my understanding,
> > valid) gives an error. The solution appears to be to use long file
> > names, and make sure you quote them, rather than short ones.
> > That does require that R be able to handle such long names and
> > I think R does, in fact, handle them but at one time it did not in
> > all cases so use of short file names is likely just a workaround
> > from older times. This does not affect R itself as far as I know
> > but did affect my batchfiles which I have revised. I am using
> > Windows XP.
> >
> >C:\>set apath=\Program Files\R\R-2.2.1
> >C:\>for /f "delims=" %a in ("%apath%") do set AA=%~sa
> >C:\>set aa
> >AA=C:\PROGRA~1\R\R-22~1.1.2.1
> >C:\>cd %aa%
> >The system cannot find the path specified.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> Please let us know Microsoft's response to your bug report.
>
> Duncan Murdoch
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
