Re: [Rd] CHAR(STRING_ELT( - OK but CHAR(asChar(STRING_ELT( - not, why?
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> > on Mon, 23 Jul 2007 13:22:16 +0100 (BST) writes: BDR> I think you are asking why calling asChar on a CHARSXP gives NA_STRING. BDR> In particular, the calls you mention *are* perfectly OK and work as BDR> intended. BDR> As barely documented in R-exts, asChar is designed for vector arguments: a BDR> CHARSXP is not a vector. It gives NA_STRING for invalid inputs. BDR> The as family of functions are designed to coerce as necessary user BDR> inputs, and CHARSXPs are not visible at R level. BDR> In general, with internal functions you are expected to BDR> read the code to find out what they do before using BDR> them. [..] BDR> There is no R '2.4', but the behaviour of asChar was the same in R 2.4.0 BDR> except for the adding of SYMSXP at BDR> - BDR> r40358 | maechler | 2007-01-04 11:07:04 + (Thu, 04 Jan 2007) | 1 line BDR> eliminate CHAR_STAR in methods/src/ as per old "todo" BDR> - BDR> which message does not help me at all. Perhaps Martin can explain? I had to " svn diff -r40357:40358 " to see : What I did was to basically add else if(TYPEOF(x) == SYMSXP) return PRINTNAME(x); to asChar() which allowed to eliminate a macro and a similar if() in C code from methods where there's been a long standing "TODO" about this. The only change this could have was to *not* return an NA in the 'symbol/name' cases it gave NA before. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changes in the MEMSS package (data sets from Pinheiro and Bates, 2000, without the groupedData classes)
Some time ago Deepayan and I created a package called MEMSS for the data sets from the nlme package as data frames but not groupedData objects. Because of advances that Deepayan has made in lattice graphics many of the specialized plotting methods for the groupedData objects are no longer needed. It is easier and less confusing to store these data sets as data frames rather than as groupedData objects. I propose making two further changes in these objects. Those objects typically had factors converted to ordered factors in an artificial way and I plan to revert them to factors. Also, I will relabel any factors with (26 or fewer) numeric levels with letters and to remove the "ginfo" attribute. Please tell me if this will cause you hardship because you have used these data sets in your work and depend on the current formulation. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes in the MEMSS package (data sets from Pinheiro and Bates, 2000, without the groupedData classes)
Does this include datasets such as CO2 and ChickWeight which are in the datasets package? Could you post a list of the specific datasets you are referring to so there is no confusion what this is about. On 7/24/07, Douglas Bates <[EMAIL PROTECTED]> wrote: > Some time ago Deepayan and I created a package called MEMSS for the > data sets from the nlme package as data frames but not groupedData > objects. Because of advances that Deepayan has made in lattice > graphics many of the specialized plotting methods for the groupedData > objects are no longer needed. It is easier and less confusing to > store these data sets as data frames rather than as groupedData > objects. > > I propose making two further changes in these objects. Those objects > typically had factors converted to ordered factors in an artificial > way and I plan to revert them to factors. Also, I will relabel any > factors with (26 or fewer) numeric levels with letters and to remove > the "ginfo" attribute. > > Please tell me if this will cause you hardship because you have used > these data sets in your work and depend on the current formulation. > > __ > 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] Changes in the MEMSS package (data sets from Pinheiro and Bates, 2000, without the groupedData classes)
On 7/24/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > Does this include datasets such as CO2 and ChickWeight > which are in the datasets package? > Could you post a list of the specific datasets you are referring to > so there is no confusion what this is about. I am only referring to the datasets in the MEMSS package. There will be CO2, ChickWeight, Theoph, etc. datasets in the MEMSS package without the groupedData classes. However, the versions in the datasets package will stay as they are unless and until R-core decides to change them. Having datasets in the datasets package and in the MEMSS package with the same name will produce a warning when you attach the MEMSS package. However, I generally use datasets with a call like data(Rail, package = "MEMSS") which doesn't cause a warning (it is assumed that if you are this explicit about the data set then you probably want exactly that version and haven't accidently overridden the other). The bottom line is that unless you have been in the habit of attaching the MEMSS package or getting data sets from it as above then you won't notice any difference. > On 7/24/07, Douglas Bates <[EMAIL PROTECTED]> wrote: > > Some time ago Deepayan and I created a package called MEMSS for the > > data sets from the nlme package as data frames but not groupedData > > objects. Because of advances that Deepayan has made in lattice > > graphics many of the specialized plotting methods for the groupedData > > objects are no longer needed. It is easier and less confusing to > > store these data sets as data frames rather than as groupedData > > objects. > > > > I propose making two further changes in these objects. Those objects > > typically had factors converted to ordered factors in an artificial > > way and I plan to revert them to factors. Also, I will relabel any > > factors with (26 or fewer) numeric levels with letters and to remove > > the "ginfo" attribute. > > > > Please tell me if this will cause you hardship because you have used > > these data sets in your work and depend on the current formulation. > > > > __ > > 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] Changes in the MEMSS package (data sets from Pinheiro and Bates, 2000, without the groupedData classes)
On a related note CO2 and ChickWeight in datasets have nlme specific attributes so either those datasets themselves should be moved to nlme or the nlme specific attributes removed in datasets as well. On 7/24/07, Douglas Bates <[EMAIL PROTECTED]> wrote: > On 7/24/07, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > > Does this include datasets such as CO2 and ChickWeight > > which are in the datasets package? > > > Could you post a list of the specific datasets you are referring to > > so there is no confusion what this is about. > > I am only referring to the datasets in the MEMSS package. There will > be CO2, ChickWeight, Theoph, etc. datasets in the MEMSS package > without the groupedData classes. However, the versions in the > datasets package will stay as they are unless and until R-core decides > to change them. > > Having datasets in the datasets package and in the MEMSS package with > the same name will produce a warning when you attach the MEMSS > package. However, I generally use datasets with a call like > > data(Rail, package = "MEMSS") > > which doesn't cause a warning (it is assumed that if you are this > explicit about the data set then you probably want exactly that > version and haven't accidently overridden the other). > > The bottom line is that unless you have been in the habit of attaching > the MEMSS package or getting data sets from it as above then you won't > notice any difference. > > > On 7/24/07, Douglas Bates <[EMAIL PROTECTED]> wrote: > > > Some time ago Deepayan and I created a package called MEMSS for the > > > data sets from the nlme package as data frames but not groupedData > > > objects. Because of advances that Deepayan has made in lattice > > > graphics many of the specialized plotting methods for the groupedData > > > objects are no longer needed. It is easier and less confusing to > > > store these data sets as data frames rather than as groupedData > > > objects. > > > > > > I propose making two further changes in these objects. Those objects > > > typically had factors converted to ordered factors in an artificial > > > way and I plan to revert them to factors. Also, I will relabel any > > > factors with (26 or fewer) numeric levels with letters and to remove > > > the "ginfo" attribute. > > > > > > Please tell me if this will cause you hardship because you have used > > > these data sets in your work and depend on the current formulation. > > > > > > __ > > > 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] dict package: dictionary data structure for R
On 7/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote: > Bill Dunlap <[EMAIL PROTECTED]> writes: > > With environments, if you use a prime number for the size > > you get considerably better results. E.g., > > > Perhaps new.env() should push the requested size up > > to the next prime by default. > > Perhaps. I think we should also investigate other hashing functions > since computing the next prime and doing so for resizes will take > longer than not having to do it and it will add complexity to the > code. An alternative is to hard-wiring primes within a reasonable range: http://primes.utm.edu/lists/small/millions/ http://www.math.utah.edu/~pa/math/p1.html Maybe primes close to 2^n are good enough for this problem: http://primes.utm.edu/lists/2small/ Just my $.02 /Henrik > > + seth > > -- > Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center > http://bioconductor.org > > __ > 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] dict package: dictionary data structure for R
> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> on Tue, 24 Jul 2007 18:58:04 +0200 writes:
HenrikB> On 7/23/07, Seth Falcon <[EMAIL PROTECTED]> wrote:
>> Bill Dunlap <[EMAIL PROTECTED]> writes:
>> > With environments, if you use a prime number for the size
>> > you get considerably better results. E.g.,
>>
>> > Perhaps new.env() should push the requested size up
>> > to the next prime by default.
>>
>> Perhaps. I think we should also investigate other hashing functions
>> since computing the next prime and doing so for resizes will take
>> longer than not having to do it and it will add complexity to the
>> code.
HenrikB> An alternative is to hard-wiring primes within a reasonable range:
HenrikB> http://primes.utm.edu/lists/small/millions/
HenrikB> http://www.math.utah.edu/~pa/math/p1.html
HenrikB> Maybe primes close to 2^n are good enough for this problem:
HenrikB> http://primes.utm.edu/lists/2small/
Yes, I had a similar thought
Note that you don't need web sites for prime numbers:
my R factorization utilities I had mentioned a few times,
e.g., here
http://tolstoy.newcastle.edu.au/R/help/05/01/10007.html
can give the first few hundred thousand primes quickly enough:
> source("ftp://stat.ethz.ch/U/maechler/R/prime-numbers-fn.R";)
> system.time(PS3 <- prime.sieve(prime.sieve(prime.sieve(
user system elapsed
0.446 0.006 0.452
> head(PS3, 20)
[1] 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71
> tail(PS3, 20)
[1] 273233 273253 273269 273271 273281 273283 273289 273311 273313 273323
[11] 273349 273359 273367 273433 273457 273473 273503 273517 273521 273527
>
There are more prime / factorization utilities in that simple R
source file, but
as I say there, one should really use C code to do this;
but then R has become so fast ...
Martin Maechler, ETH Zurich
HenrikB> Just my $.02
HenrikB> /Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Accuracy of qt for df=1 (PR#9804)
Full_Name: Morten Welinder Version: 2.2.0 OS: Linux Submission from: (NULL) (216.223.241.229) The qt function for df=1 is implemented as... q = - tan((P+1) * M_PI_2); Adding 1 kills accuracy for P near 0. A better way is to use q = cot(P * M_PI_2); or q = 1/tan(P * M_PI_2); __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
