Re: [Rd] R_alloc problems in R v1.11
Kjell Konis wrote:
> On 6 Jul 2005, at 22:06, Uwe Ligges wrote:
>
>
>>Marie-Hélène Ouellette wrote:
>>
>>
>>>I'm using the R v1.11 on Macintoch and I seem to have a problem
>>>with the
>>>
>>
>>There is no version 1.11, and there never was. Current is 2.1.1
>>anything
>>older than 2.x.y is unsupported these days.
>
>
> The latest version of R for OSX available on CRAN (R-2.1.0a.dmg)
> reports itself as "Version 1.11 (1.11)". This is actually the
> version of the Macintosh GUI and not the underlying R framework
> (which is 2.1.0) but it is found where traditional mac users are
> going to look to find the version information: R -> About R.
>
> I think I may have also stumbled across a tiny little bug in .C. I
> forgot to capitalize Hello:
>
> > .C("hello", as.integer(5))
> Error in .C("hello", as.integer(5)) : "C" function name not in load
> table
No, it is intended to say "C" or "Fortran", AFAICS.
Uwe Ligges
> I think it should say '"hello" function name not in load table'.
>
> Kjell
>
> __
> 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] Sys.timzone() returns NA - problem caused by as.POSIXlt? (PR#7994)
Full_Name: Martin Keller-Ressel
Version: 2.1.1
OS: Windows 2000
Submission from: (NULL) (128.130.51.88)
Sys.timezone() returns NA although the environment variable TZ is set to GMT
and
Sys.time() returns the correct time and date including the right timezone.
The problem is probably due to as.POSIXlt() which is used by Sys.timezone().
The problem has been confirmed by Uwe Ligges for R 2.1.1 on Windows NT 4.0.
See below for a R session outlining the problem:
> Sys.getenv("TZ")
TZ
"GMT"
> Sys.time()
[1] "2005-07-07 10:28:11 GMT"
> Sys.timezone()
[1] NA
> Sys.timezone
function ()
{
z <- as.POSIXlt(Sys.time())
attr(z, "tzone")[2 + z$isdst]
}
> z <- as.POSIXlt(Sys.time())
> attributes(z)
$names
[1] "sec" "min" "hour" "mday" "mon" "year" "wday" "yday" "isdst"
$class
[1] "POSIXt" "POSIXlt"
$tzone
[1] "GMT"
> attr(z,"tzone")
[1] "GMT"
> z$isdst
[1] 0
> attr(z,"tzone")[2]
[1] NA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SSD() documentation (PR#7993)
> "arnima" == arnima <[EMAIL PROTECTED]> > on Thu, 7 Jul 2005 05:40:53 +0200 (CEST) writes: arnima> There are a couple of harmless typos in the arnima> documentation for the stats::SSD function, where arnima> "varianve" should be "variance" arnima> "followint" should be "following" Thank you, I will fix these shortly. Martin arnima> Arni arnima> R 2.1.1pat 2005-07-04 on WinXP __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load...or else...
At 19:46 2005-07-06, you wrote:
>Marie-Hélène Ouellette wrote:
>>Hi everybody,
>>I'm working on Mac OS X and R-2.1.0 (by the way, sorry for the multiple
>>emails last time, had a technical problem, and thanks for the
>>constructive comments.)
>>I have a .R function which calls a .C function. The R function's name is
>>K_MEANSR.R and the other is K_MEANSC.C.
>>I compile it with 'R CMD SHLIB K_MEANSC.C' in the terminal. I get both
>>.so and .o files.
>>I use the function
>> > dyn.load ('K_MEANSC.so')
>>with no error. We can, I believe, see here that it is loaded:
>>
>> > getLoadedDLLs()
>>
>>Filename
>>base base
>>grDevices
>>/Library/Frameworks/R.framework/Resources/library/grDevices/libs/grDevices.so
>>stats /Library/Frameworks/R.framework/Resources/library/stats/libs/stats.so
>>methods
>>/Library/Frameworks/R.framework/Resources/library/methods/libs/methods.so
>>K_MEANSC
>>/Users/admin/Desktop/Marie/Marie_labo_29_juin/K-means_versions/MAC/K_MEANSC.so
>>R_X11 /Library/Frameworks/R.framework/Resources/modules/R_X11.so
>>Dynamic.Lookup
>>base FALSE
>>grDevices FALSE
>>stats FALSE
>>methodsFALSE
>>K_MEANSCTRUE
>>R_X11 TRUE
>>
>>I then source the R code:
>> > source(file.choose())
>>Construct a matrix that I will use for the analysis:
>> > tab<-c(1,1,3,4,6,6,3,5,7,67,5,6,65,3,5,1,5,42,3,567,6,4,7,7)
>> > tab<-matrix(tab,6,4)
>>And try to use the function:
>> > K_MEANSR(tab,centers=c(2,4))
>>[1] "AA"
>>[1] "AAA"
>>[1] "A"
>>[1] "B"
>>Error in .C("K_MEANSC", xrows = as.integer(xrows), xcols =
>>as.integer(xcols), :
>> "C" function name not in load table
>>Everything that is printed on the screen is correct, but why does it says
>>that 'K_MEANSC' function is not in load table??? It then just stops at
>>that stage of the .R function.
>
>What does your declaration of the function look like in the K_MEANSC.C
>file? R needs to know the name of the exported function, not the name of
>the .so file.
>
>Duncan Murdoch
It's in the form:
K_MEANSC<- function(arguments...)
{
}
So the name of my .C function is also K_MEANSC...
Marie-Hélène
==
Marie-Hélène Ouellette
UNIVERSITE DE MONTRÉAL
Département de sciences biologiques
Tél. (514) 343-6111 poste 1233
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with dyn.load...or else...
On 7/7/2005 10:16 AM, Marie-Hélène Ouellette wrote:
> At 19:46 2005-07-06, you wrote:
>>Marie-Hélène Ouellette wrote:
>>>Hi everybody,
>>>I'm working on Mac OS X and R-2.1.0 (by the way, sorry for the multiple
>>>emails last time, had a technical problem, and thanks for the
>>>constructive comments.)
>>>I have a .R function which calls a .C function. The R function's name is
>>>K_MEANSR.R and the other is K_MEANSC.C.
>>>I compile it with 'R CMD SHLIB K_MEANSC.C' in the terminal. I get both
>>>.so and .o files.
>>>I use the function
>>> > dyn.load ('K_MEANSC.so')
>>>with no error. We can, I believe, see here that it is loaded:
>>>
>>> > getLoadedDLLs()
>>>
>>>Filename
>>>base base
>>>grDevices
>>>/Library/Frameworks/R.framework/Resources/library/grDevices/libs/grDevices.so
>>>stats /Library/Frameworks/R.framework/Resources/library/stats/libs/stats.so
>>>methods
>>>/Library/Frameworks/R.framework/Resources/library/methods/libs/methods.so
>>>K_MEANSC
>>>/Users/admin/Desktop/Marie/Marie_labo_29_juin/K-means_versions/MAC/K_MEANSC.so
>>>R_X11 /Library/Frameworks/R.framework/Resources/modules/R_X11.so
>>>Dynamic.Lookup
>>>base FALSE
>>>grDevices FALSE
>>>stats FALSE
>>>methodsFALSE
>>>K_MEANSCTRUE
>>>R_X11 TRUE
>>>
>>>I then source the R code:
>>> > source(file.choose())
>>>Construct a matrix that I will use for the analysis:
>>> > tab<-c(1,1,3,4,6,6,3,5,7,67,5,6,65,3,5,1,5,42,3,567,6,4,7,7)
>>> > tab<-matrix(tab,6,4)
>>>And try to use the function:
>>> > K_MEANSR(tab,centers=c(2,4))
>>>[1] "AA"
>>>[1] "AAA"
>>>[1] "A"
>>>[1] "B"
>>>Error in .C("K_MEANSC", xrows = as.integer(xrows), xcols =
>>>as.integer(xcols), :
>>> "C" function name not in load table
>>>Everything that is printed on the screen is correct, but why does it says
>>>that 'K_MEANSC' function is not in load table??? It then just stops at
>>>that stage of the .R function.
>>
>>What does your declaration of the function look like in the K_MEANSC.C
>>file? R needs to know the name of the exported function, not the name of
>>the .so file.
>>
>>Duncan Murdoch
>
>
> It's in the form:
>
> K_MEANSC<- function(arguments...)
> {
>
> }
> So the name of my .C function is also K_MEANSC...
No, you misunderstood. That's R code; I was asking about the C language
code that you want .C("K_MEANSC", xrows = as.integer(xrows) ... to call.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Brewer colours
Anyone who is interested in using optimal colour palettes should look at the work of Cindy Brewer: www.colorbrewer.org I have written code to use her colour schemes in R. It is included below. Perhaps someone may find this interesting enough to work into a package. Included also is a function showpalette, which was posted here a while back. I don't remember who wrote it. I have copied all the palettes from colorbrewer with the maximum number of colours (which varies per palette). I have written a function that translates these colours directly to rgb, or through interpolation if you need a larger (or smaller) palette. If you need a smaller palette, you may have to go to www.colorbrewer.org for optimal results. There are three types of palettes: - Sequential, from minimal (light) to maximal (dark). There is no white in the original palettes. I added white. - Diverging, from one extreme (dark) through light to another extreme (dark, another colour). - Qualitative, no particular order. To view a palette with the original colours: > showpalette(brewer2rgb(brewerSequential.YlGnBl)) To view the same palette, interpolated to another number of colours: > showpalette(brewer2rgb(brewerSequential.YlGnBl, 19)) Notes: 1. Interpolating Qualitative palettes does not work. You can't get more colours. If you need less, go to www.colorbrewer.org 2. The palettes are tested to consist of colours that are optimally distinguishable to the human eye. Not all palettes may be useful in all circumstances or media. See www.colorbrewer.org for specs per palette and per number of colours. Interpolating to more colours will loose the distinction. The code: # www.colorbrewer.org brewerSequential.PuBu <- array(data = c( 255,255,255, 255,247,251, 236,231,242, 208,209,230, 166,189,219, 116,169,207, 54,144,192, 5,112,176, 4,90,141, 2,56,88), dim = c(3, 10)) brewerSequential.YlGnBl <- array(data = c( 255,255,255, 255,255,217, 237,248,177, 199,233,180, 127,205,187, 65,182,196, 29,145,192, 34,94,168, 37,52,148, 8,29,88), dim = c(3, 10)) brewerSequential.GnBu <- array(data = c( 255,255,255, 247,252,240, 224,243,219, 204,235,197, 168,221,181, 123,204,196, 78,179,211, 43,140,190, 8,104,172, 8,64,129), dim = c(3, 10)) brewerSequential.YlGn <- array(data = c( 255,255,255, 255,255,229, 247,252,185, 217,240,163, 173,221,142, 120,198,121, 65,171,93, 35,132,67, 0,104,55, 0,69,41), dim = c(3, 10)) brewerSequential.BuGn <- array(data = c( 255,255,255, 247,252,253, 229,245,249, 204,236,230, 153,216,201, 102,194,164, 65,174,118, 35,139,69, 0,109,44, 0,68,27), dim = c(3, 10)) brewerSequential.OrRd <- array(data = c( 255,255,255, 255,247,236, 254,232,200, 253,212,158, 253,187,132, 252,141,89, 239,101,72, 215,48,31, 179,0,0, 127,0,0), dim = c(3, 10)) brewerSequential.PuBuGn <- array(data = c( 255,255,255, 255,247,251, 236,226,240, 208,209,230, 166,189,219, 103,169,207, 54,144,192, 2,129,138, 1,108,89, 1,70,54), dim = c(3, 10)) brewerSequential.BuPu <- array(data = c( 255,255,255, 247,252,253, 224,236,244, 191,211,230, 158,188,218, 140,150,198, 140,107,177, 136,65,157, 129,15,124, 77,0,75), dim = c(3, 10)) brewerSequential.RdPu <- array(data = c( 255,255,255, 255,247,243, 253,224,221, 252,197,192, 250,159,181, 247,104,161, 221,52,151, 174,1,126, 122,1,119, 73,0,106), dim = c(3, 10)) brewerSequential.PuRd <- array(data = c( 255,255,255, 247,244,249, 231,225,239, 212,185,218, 201,148,199, 223,101,176, 231,41,138, 206,18,86, 152,0,67, 103,0,31), dim = c(3, 10)) brewerSequential.YlOrRd <- array(data = c( 255,255,255, 255,255,204, 255,237,160, 254,217,118, 254,178,76, 253,141,60, 252,78,42, 227,26,28, 189,0,38, 128,0,38), dim = c(3, 10)) brewerSequential.YlOrBr <- array(data = c( 255,255,255, 255,255,229, 255,247,188, 254,227,145, 254,196,79, 254,153,41, 236,112,20, 204,76,2, 153,52,4, 102,37,6), dim = c(3, 10)) brewerSequential.Purples <- array(data = c( 255,255,255, 252,251,253, 239,237,245, 218,218,235, 188,189,220, 158,154,200, 128,125,186, 106,81,163, 84,39,143, 63,0,125), dim = c(3, 10)) brewerSequential.Blues <- array(data = c( 255,255,255, 247,251,255, 222,235,247, 198,219,239, 158,202,225, 107,174,214, 66,146,198, 33,113,181, 8,81,156, 8,48,107), dim = c(3, 10)) brewerSequential.Greens <- array(data = c( 255,255,255, 247,252,245, 229,245,224, 199,233,192, 161,217,155, 116,196,118, 65,171,93, 35,139,69, 0,109,44, 0,68,27), dim = c(3, 10)) brewerSequential.Oranges <- array(data = c( 255,255,255, 255,245,235, 254,230,206, 253,208,162, 253,174,107, 253,141,60, 241,105,19, 217,72,1, 166,54,3, 127,39,4), dim = c(3, 10)) brewerSequential.Reds <- array(data = c( 255,255,255, 255,245,240, 254,224,210, 252,187,161, 252,146,114, 251,106,74, 239,59,44, 203,24,29, 165,15,21, 103,0,13), dim = c(3, 10)) brewerSequential.Greys <- array(data = c( 255,255,255, 240,240,240, 217,217,217, 189,189,189, 150,150,150, 115,115,115, 82,82,82, 37,37,37, 0,0,0), dim = c(3, 9)) brewerDiverging.PuOr <- array(da
Re: [Rd] Brewer colours
Do you mean something like: http://cran.r-project.org/src/contrib/Descriptions/RColorBrewer.html ? Andy > From: Peter Kleiweg > > > Anyone who is interested in using optimal colour palettes should > look at the work of Cindy Brewer: www.colorbrewer.org > > I have written code to use her colour schemes in R. It is > included below. Perhaps someone may find this interesting enough > to work into a package. > > Included also is a function showpalette, which was posted here a > while back. I don't remember who wrote it. > > I have copied all the palettes from colorbrewer with the maximum > number of colours (which varies per palette). I have written a > function that translates these colours directly to rgb, or > through interpolation if you need a larger (or smaller) palette. > If you need a smaller palette, you may have to go to > www.colorbrewer.org for optimal results. > > There are three types of palettes: > - Sequential, from minimal (light) to maximal (dark). > There is no white in the original palettes. I added white. > - Diverging, from one extreme (dark) through light to another > extreme (dark, another colour). > - Qualitative, no particular order. > > To view a palette with the original colours: > >> showpalette(brewer2rgb(brewerSequential.YlGnBl)) > > To view the same palette, interpolated to another number of > colours: > >> showpalette(brewer2rgb(brewerSequential.YlGnBl, 19)) > > Notes: > > 1. Interpolating Qualitative palettes does not work. You can't > get more colours. If you need less, go to www.colorbrewer.org > > 2. The palettes are tested to consist of colours that are > optimally distinguishable to the human eye. Not all > palettes may be useful in all circumstances or media. See > www.colorbrewer.org for specs per palette and per number of > colours. Interpolating to more colours will loose the > distinction. > > The code: > > # www.colorbrewer.org > > brewerSequential.PuBu <- array(data = c( > 255,255,255, > 255,247,251, > 236,231,242, > 208,209,230, > 166,189,219, > 116,169,207, > 54,144,192, > 5,112,176, > 4,90,141, > 2,56,88), > dim = c(3, 10)) > > brewerSequential.YlGnBl <- array(data = c( > 255,255,255, > 255,255,217, > 237,248,177, > 199,233,180, > 127,205,187, > 65,182,196, > 29,145,192, > 34,94,168, > 37,52,148, > 8,29,88), > dim = c(3, 10)) > > brewerSequential.GnBu <- array(data = c( > 255,255,255, > 247,252,240, > 224,243,219, > 204,235,197, > 168,221,181, > 123,204,196, > 78,179,211, > 43,140,190, > 8,104,172, > 8,64,129), > dim = c(3, 10)) > > brewerSequential.YlGn <- array(data = c( > 255,255,255, > 255,255,229, > 247,252,185, > 217,240,163, > 173,221,142, > 120,198,121, > 65,171,93, > 35,132,67, > 0,104,55, > 0,69,41), > dim = c(3, 10)) > > brewerSequential.BuGn <- array(data = c( > 255,255,255, > 247,252,253, > 229,245,249, > 204,236,230, > 153,216,201, > 102,194,164, > 65,174,118, > 35,139,69, > 0,109,44, > 0,68,27), > dim = c(3, 10)) > > brewerSequential.OrRd <- array(data = c( > 255,255,255, > 255,247,236, > 254,232,200, > 253,212,158, > 253,187,132, > 252,141,89, > 239,101,72, > 215,48,31, > 179,0,0, > 127,0,0), > dim = c(3, 10)) > > brewerSequential.PuBuGn <- array(data = c( > 255,255,255, > 255,247,251, > 236,226,240, > 208,209,230, > 166,189,219, > 103,169,207, > 54,144,192, > 2,129,138, > 1,108,89, > 1,70,54), > dim = c(3, 10)) > > brewerSequential.BuPu <- array(data = c( > 255,255,255, > 247,252,253, > 224,236,244, > 191,211,230, > 158,188,218, > 140,150,198, > 140,107,177, > 136,65,157, > 129,15,124, > 77,0,75), > dim = c(3, 10)) > > brewerSequential.RdPu <- array(data = c( > 255,255,255, > 255,247,243, > 253,224,221, > 252,197,192, > 250,159,181, > 247,104,161, > 221,52,151, > 174,1,126, > 122,1,119, > 73,0,106), > dim = c(3, 10)) > > brewerSequential.PuRd <- array(data = c( > 255,255,255, > 247,244,249, > 231,225,239, > 212,185,218, > 201,148,199, > 223,101,176, > 231,41,138, > 206,18,86, > 152,0,67, > 103,0,31), > dim = c(3, 10)) > > brewerSequential.YlOrRd <- array(data = c( > 255,255,255, > 255,255,204, > 255,237,160, > 254,217,118, > 254,178,76, > 253,141,60, > 252,78,42, > 227,26,28, > 189,0,38, > 128,0,38), > dim = c(3, 10)) > > brewerSequential.YlOrBr <- array(data = c( > 255,255,255, > 255,255,229, > 255,247,188, > 254,227,145, > 254,196,79, > 254,153,41, > 236,112,20, > 204,76,2, > 153,52,4, > 102,37,6), > dim = c(3, 10)) > > brewerSequential.Purples <- array(data = c( > 255,255,255, > 252,251,253, > 239,237,245, > 218,218,235, > 188,189,220, > 158,154,200, > 128,125,186, > 106,81,163, > 84,39,143, > 63,0,125), > dim = c(3, 10)) > > brewerSequential.Blues <- array(data = c( > 255,255,255, > 247,251,255, > 222,235,247, > 198,219,239, > 158,202,225, > 107,174,214, > 66,146,198, > 33,113,181, > 8,81,156, > 8,48,107), > dim = c(3, 10)) > > brewerSequential.Greens <- array(data = c( > 255,255,255, > 247,252,245, > 229,245,224, > 199,233,192, > 161,217,155, > 116,196,118, > 65,1
Re: [Rd] Brewer colours
Liaw, Andy schreef op de 7e dag van de hooimaand van het jaar 2005: > Do you mean something like: > http://cran.r-project.org/src/contrib/Descriptions/RColorBrewer.html > ? Now I feel silly. Well, it was a nice exercise. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv (PR#7992)
This topic already came up about a week ago on R-devel
Subject: write.csv suggestion
[ too bad that "R-devel" is not available via RSiteSearch() ...
{I could send you the back archives, Jon, if you are interested} ]
There, Brian Ripley, explained why this is not a bug, since
it works as documented, "CSV" files are well defined entities
and you can always use write.table() if you want to be flexible.
Brian also changed things for R-devel {to be R 2.2.x} such that
its help page, see
http://stat.ethz.ch/R-manual/R-devel/library/base/html/write.table.html ,
now has
> Usage:
>. . . .
>
> write.csv(...)
> write.csv2(...)
>
> . . . .
>
>
> Arguments:
>. . . .
>
> ...: arguments to 'write.table': 'col.names', 'sep', 'dec' and
> 'qmethod' cannot be altered.
which should make the intention of the write.csv*() wrapper
functions a bit more clear.
Regards,
Martin Maechler, ETH Zurich
> "arnima" == arnima <[EMAIL PROTECTED]>
> on Thu, 7 Jul 2005 05:21:43 +0200 (CEST) writes:
arnima> The write.csv() function is currently implemented as
arnima> function (..., col.names=NA, sep=",", qmethod="double")
arnima> {
arnima> write.table(..., col.names=NA, sep=",", qmethod="double")
arnima> }
arnima> Surely, it should be
arnima> function (..., col.names=NA, sep=",", qmethod="double")
arnima> {
arnima> write.table(..., col.names=col.names, sep=sep, qmethod=qmethod)
arnima> }
arnima> so that the user arguments serve a purpose. This notion is
reflected in
arnima> the implementation of read.csv(), for example, where sep=sep,
quote=quote,
arnima> etc.
arnima> Arni
arnima> R 2.1.1pat 2005-07-04 on WinXP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.csv (PR#7992)
This may not be inconsistent with the documentation but it is
inconsistent with good practice. Wrappers should, in general,
set the default values, as the poster rightly indicated, and not the
values themselves. Its not a coincidence that multiple people
have mentioned this.
On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This topic already came up about a week ago on R-devel
> Subject: write.csv suggestion
>
> [ too bad that "R-devel" is not available via RSiteSearch() ...
>{I could send you the back archives, Jon, if you are interested} ]
>
> There, Brian Ripley, explained why this is not a bug, since
> it works as documented, "CSV" files are well defined entities
> and you can always use write.table() if you want to be flexible.
>
> Brian also changed things for R-devel {to be R 2.2.x} such that
> its help page, see
> http://stat.ethz.ch/R-manual/R-devel/library/base/html/write.table.html ,
> now has
>
> > Usage:
> >. . . .
> >
> > write.csv(...)
> > write.csv2(...)
> >
> > . . . .
> >
> >
> > Arguments:
> >. . . .
> >
> > ...: arguments to 'write.table': 'col.names', 'sep', 'dec' and
> > 'qmethod' cannot be altered.
>
> which should make the intention of the write.csv*() wrapper
> functions a bit more clear.
>
> Regards,
> Martin Maechler, ETH Zurich
>
> > "arnima" == arnima <[EMAIL PROTECTED]>
> > on Thu, 7 Jul 2005 05:21:43 +0200 (CEST) writes:
>
>arnima> The write.csv() function is currently implemented as
>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>arnima> {
>arnima> write.table(..., col.names=NA, sep=",", qmethod="double")
>arnima> }
>
>arnima> Surely, it should be
>
>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>arnima> {
>arnima> write.table(..., col.names=col.names, sep=sep, qmethod=qmethod)
>arnima> }
>
>arnima> so that the user arguments serve a purpose. This notion is
> reflected in
>arnima> the implementation of read.csv(), for example, where sep=sep,
> quote=quote,
>arnima> etc.
>
>
>arnima> Arni
>
>arnima> R 2.1.1pat 2005-07-04 on WinXP
>
> __
> 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] write.csv (PR#7992)
On 7/7/2005 12:38 PM, Gabor Grothendieck wrote:
> This may not be inconsistent with the documentation but it is
> inconsistent with good practice. Wrappers should, in general,
> set the default values, as the poster rightly indicated, and not the
> values themselves. Its not a coincidence that multiple people
> have mentioned this.
The old header (which teasingly displayed some parameters and then
ignored them) was clearly wrong, but the new one doesn't display the
parameters.
This is pretty reasonable practice. It's a wrapper that provides a
subset of the functionality, but is guaranteed to produce a legal file
of the type it claims to produce. I don't see anything wrong with it.
Duncan Murdoch
>
> On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> This topic already came up about a week ago on R-devel
>> Subject: write.csv suggestion
>>
>> [ too bad that "R-devel" is not available via RSiteSearch() ...
>>{I could send you the back archives, Jon, if you are interested} ]
>>
>> There, Brian Ripley, explained why this is not a bug, since
>> it works as documented, "CSV" files are well defined entities
>> and you can always use write.table() if you want to be flexible.
>>
>> Brian also changed things for R-devel {to be R 2.2.x} such that
>> its help page, see
>> http://stat.ethz.ch/R-manual/R-devel/library/base/html/write.table.html ,
>> now has
>>
>> > Usage:
>> >. . . .
>> >
>> > write.csv(...)
>> > write.csv2(...)
>> >
>> > . . . .
>> >
>> >
>> > Arguments:
>> >. . . .
>> >
>> > ...: arguments to 'write.table': 'col.names', 'sep', 'dec' and
>> > 'qmethod' cannot be altered.
>>
>> which should make the intention of the write.csv*() wrapper
>> functions a bit more clear.
>>
>> Regards,
>> Martin Maechler, ETH Zurich
>>
>> > "arnima" == arnima <[EMAIL PROTECTED]>
>> > on Thu, 7 Jul 2005 05:21:43 +0200 (CEST) writes:
>>
>>arnima> The write.csv() function is currently implemented as
>>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>>arnima> {
>>arnima> write.table(..., col.names=NA, sep=",", qmethod="double")
>>arnima> }
>>
>>arnima> Surely, it should be
>>
>>arnima> function (..., col.names=NA, sep=",", qmethod="double")
>>arnima> {
>>arnima> write.table(..., col.names=col.names, sep=sep, qmethod=qmethod)
>>arnima> }
>>
>>arnima> so that the user arguments serve a purpose. This notion is
>> reflected in
>>arnima> the implementation of read.csv(), for example, where sep=sep,
>> quote=quote,
>>arnima> etc.
>>
>>
>>arnima> Arni
>>
>>arnima> R 2.1.1pat 2005-07-04 on WinXP
>>
>> __
>> 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/r-devel
Re: [Rd] write.csv (PR#7992)
I just checked the svn. I did not realize it had been changed that way
so you are right, its better and possibly marginally acceptable although
I do think it would be preferable to set the defaults rather than the
values though I would no longer argue as strongly.
On 7/7/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 7/7/2005 12:38 PM, Gabor Grothendieck wrote:
> > This may not be inconsistent with the documentation but it is
> > inconsistent with good practice. Wrappers should, in general,
> > set the default values, as the poster rightly indicated, and not the
> > values themselves. Its not a coincidence that multiple people
> > have mentioned this.
>
> The old header (which teasingly displayed some parameters and then
> ignored them) was clearly wrong, but the new one doesn't display the
> parameters.
>
> This is pretty reasonable practice. It's a wrapper that provides a
> subset of the functionality, but is guaranteed to produce a legal file
> of the type it claims to produce. I don't see anything wrong with it.
>
> Duncan Murdoch
>
>
> >
> > On 7/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> This topic already came up about a week ago on R-devel
> >> Subject: write.csv suggestion
> >>
> >> [ too bad that "R-devel" is not available via RSiteSearch() ...
> >>{I could send you the back archives, Jon, if you are interested} ]
> >>
> >> There, Brian Ripley, explained why this is not a bug, since
> >> it works as documented, "CSV" files are well defined entities
> >> and you can always use write.table() if you want to be flexible.
> >>
> >> Brian also changed things for R-devel {to be R 2.2.x} such that
> >> its help page, see
> >> http://stat.ethz.ch/R-manual/R-devel/library/base/html/write.table.html ,
> >> now has
> >>
> >> > Usage:
> >> >. . . .
> >> >
> >> > write.csv(...)
> >> > write.csv2(...)
> >> >
> >> > . . . .
> >> >
> >> >
> >> > Arguments:
> >> >. . . .
> >> >
> >> > ...: arguments to 'write.table': 'col.names', 'sep', 'dec' and
> >> > 'qmethod' cannot be altered.
> >>
> >> which should make the intention of the write.csv*() wrapper
> >> functions a bit more clear.
> >>
> >> Regards,
> >> Martin Maechler, ETH Zurich
> >>
> >> > "arnima" == arnima <[EMAIL PROTECTED]>
> >> > on Thu, 7 Jul 2005 05:21:43 +0200 (CEST) writes:
> >>
> >>arnima> The write.csv() function is currently implemented as
> >>arnima> function (..., col.names=NA, sep=",", qmethod="double")
> >>arnima> {
> >>arnima> write.table(..., col.names=NA, sep=",", qmethod="double")
> >>arnima> }
> >>
> >>arnima> Surely, it should be
> >>
> >>arnima> function (..., col.names=NA, sep=",", qmethod="double")
> >>arnima> {
> >>arnima> write.table(..., col.names=col.names, sep=sep, qmethod=qmethod)
> >>arnima> }
> >>
> >>arnima> so that the user arguments serve a purpose. This notion is
> >> reflected in
> >>arnima> the implementation of read.csv(), for example, where sep=sep,
> >> quote=quote,
> >>arnima> etc.
> >>
> >>
> >>arnima> Arni
> >>
> >>arnima> R 2.1.1pat 2005-07-04 on WinXP
> >>
> >> __
> >> 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/r-devel
Re: [Rd] .Rbuildignore {was: ... upgrading an R (WINDOWS) installation ..}
On 6 Jul 2005, [EMAIL PROTECTED] wrote: > In fact, on Windows R is not case sensitive in the 1st or 3rd word > on the line "R CMD install", only in the 2nd, so I can see Gabor's > point. However, I have to admit I always use "Rcmd install"; I put > the "R CMD ..." version in place to help Unix refugees. And this is appreciated by those of us that want to build packages on different platforms in an automated fashion :-) Although I agree with other posters in this thread that ports generally work best when they behave as natively as possible, it is the case that many R users use R on *both* Windows and Linux and because of this, the consistency is very helpful. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
