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
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...
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(data = c( 127,59,8,
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,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))
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
