Re: [Rd] select.list() not on front of other windows
That's a known problem with Windows: I think such widgets are not intended to be used in non-GUI applications. I've committed a workaround that seems to alleviate it. On Sun, 13 May 2007, Henrik Bengtsson wrote: > When calling > > select.list(letters[1:3]) > > in a fresh R session (R v2.4.1, v2.5.0, v2.6.0 devel) on WinXP using > *Rterm*, the dialog does *not* come up on front of other windows the > first time you call it. Under Rgui it works just fine. > > If you do: > > 1) select.list(letters[1:3]) > 2) bring the window to front manually > 3) select an option and press OK > 4) select.list(letters[1:3]) > > it the (second) dialog comes up in front of all other windows. > > /Henrik > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relist, an inverse operator to unlist
Nice ideas, Gabor and Andrew.
While I agree with Andrew that such a utility makes for nicer
and considerably better maintainable code in examples like his,
and I do like to provide "inverse operator functions" in R
whenever sensible,
OTOH, we have strived to keep R's "base" package as lean and
clean as possible, so I think this had to go to "utils".
One further small proposal: I'd use class name "relistable"
since that's what the object of this class are
and hence as.relistable().
What do other R-develers think?
Martin
> "GaGr" == Gabor Grothendieck <[EMAIL PROTECTED]>
> on Mon, 14 May 2007 02:54:22 -0400 writes:
GaGr> unlist would not attach a skeleton to every vector it
GaGr> returns, only the relist method of unlist would.
GaGr> That way just that method needs to be added and no
GaGr> changes to unlist itself are needed.
GaGr> Before applying unlist to an object you would coerce
GaGr> the object to class "relist" to force the relist
GaGr> method of unlist to be invoked.
GaGr> Here is an outline of the code:
GaGr> as.relist <- function(x) {
GaGr> if (!inherits(x, "relist")) class(x) <- c("relist", class(x))
GaGr> x
GaGr> }
GaGr> unlist.relist <- function(x, ...) {
GaGr> y <- x
GaGr> cl <- class(y)
GaGr> class(y) <- cl[- grep("relist", cl)]
GaGr> z <- unlist(y)
GaGr> attr(z, "relist") <- y
GaGr> as.relist(z)
GaGr> }
GaGr> relist <- function(x, skeleton = attr(x, "relist")) {
GaGr> # simpler version of relist so test can be executed
GaGr> skeleton
GaGr> }
GaGr> # test
GaGr> x <- list(a = 1:2, b = 3)
GaGr> class(as.relist(x))
GaGr> unlist(as.relist(x))
GaGr> relist(unlist(as.relist(x)))
GaGr> On 5/14/07, Andrew Clausen <[EMAIL PROTECTED]> wrote:
>> Hi GaGr,
>>
>> Thanks for the interesting suggestion. I must confess I got lost -- is
>> it something like this?
>> * unlist() could attach skeleton to every vector it returns.
>> * relist() could then use the skeleton attached to the vector to
reconstruct
>> the object. The interface might be
>>
>> relist <- function(flesh, skeleton=attributes(flesh)$skeleton)
>>
>> For example:
>>
>> par <- list(mean=c(0, 0), vcov(rbind(c(1, 1), c(1, 1
>> vector.for.optim <- unlist(par)
>> print(attributes(vector.optim)$skeleton)# the skeleton is stored!
>> converted.back.again <- relist(par)
>>
>> Some concerns:
>> * the metadata might get lost in some applications -- although it seems
>> to work fine with optim(). But, if we provide both interfaces (where
>> skeleton=flesh$skeleton is the default), then there should be no problem.
>> * would there be any bad side-effects of changing the existing unlist
>> interface? I suppose an option like "save.skeleton" could be added to
unlist.
>> I expect there would be some objections to enabling this as default
behaviour,
>> as it would significantly increase the storage requirements of the
output.
>>
>> Cheers,
>> Andrew
>>
>> On Sun, May 13, 2007 at 07:02:37PM -0400, GaGr Grothendieck wrote:
>> > I suggest you define a "relist" class and then define an unlist
>> > method for it which stores the skeleton as an attribute. Then
>> > one would not have to specify skeleton in the relist command
>> > so
>> >
>> > relist(unlist(relist(x))) === x
>> >
>> > 1. relist(x) is the same as x except it gets an additional class
"relist".
>> > 2. unlist(relist(x)) invokes the relist method of unlist on relist(x)
>> > returning another relist object
>> > 3. relist(unlist(relist(x))) then recreates relist(x)
>> >
>> >
>> > On 5/13/07, Andrew Clausen <[EMAIL PROTECTED]> wrote:
>> > >Hi all,
>> > >
>> > >I wrote a function called relist, which is an inverse to the existing
>> > >unlist function:
>> > >
>> > > http://www.econ.upenn.edu/~clausen/computing/relist.R
>> > >
>> > >Some functions need many parameters, which are most easily
represented in
>> > >complex structures. Unfortunately, many mathematical functions in R,
>> > >including optim, nlm, and grad can only operate on functions whose
domain
>> > >is
>> > >a vector. R has a function to convert complex objects into a vector
>> > >representation. This file provides an inverse operation called
"unlist" to
>> > >convert vectors back to the convenient structural representation.
>> > >Together,
>> > >these functions allow structured functions to have simple mathematical
>> > >interfaces.
>> > >
>> > >For example, a likelihood function for a multivariate normal model
needs a
>> > >variance-covariance matrix and a mean vector. It would be most
convenient
>> > >to
>> > >represent it as a list containing a vector and a matrix. A typical
>> > >paramet
Re: [Rd] Native implementation of rowMedians()
Hi Henrik,
> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> on Sun, 13 May 2007 21:14:24 -0700 writes:
HenrikB> Hi,
HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for matrices that
HenrikB> handles missing values implemented in C. It has been optimized for
HenrikB> memory and speed. To avoid coercing integers to doubles, and hence
HenrikB> allocate an additional 200% memory, there is one C function for
HenrikB> integers and one for doubles.
HenrikB> The rowMedians() implementation is currently sitting in my non-CRAN
HenrikB> package R.native available by:
HenrikB> source("http://www.braju.com/R/hbLite.R";)
HenrikB> hbLite("R.native")
HenrikB> library(R.native)
HenrikB> example(rowMedians)
HenrikB> The source code package is available at:
HenrikB> http://www.braju.com/R/repos/R.native_0.1.2.tar.gz
HenrikB> Before I submit a package to CRAN consisting of pretty much just
HenrikB> rowMedians(), would it make more sense for it to go into one of the
HenrikB> core packages? If so, how should I proceed?
As they say: You have to convince at least one member of R-core
that ``it's worth it''. {Then he may have to bear the battle
with dissenting core members ;- }
I'm quite interested, but really you have to do the work of unbundling
it from all the R.oo stuff before I have another longer look.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Best Practise
Hello,
Just a quick question on best practise. I am converting quite a bit of
legacy C code into R packages and have the following situation:
(1) Legacy object with a double* array in, all over code so don't want to
change any more than I have to.
(2) Do something like:
SEXP arrayToPassToR;
PROTECT( arrayToPassToR = allocVector( REALSXP, n ) );
for(i=0; i < n; i++) {
REAL(arrayToPassToR)[i] = oldCarray[i]; < very slow way
to copy
data, can I use memcpy/pointer assignment here to remove the loop without
running into garbage collector?
}
UNPROTECT( arrayToPassToR );
SEXP returnValueFromR;
(3) Have made it to call back to an R function which returns a new /
different SEXP double array.
returnValueFromR = Test_tryEval(...);
(4) Copy back to oldCArray
for(i=0; i < n; i++) {
oldCarray[i] = REAL(returnValueFromR)[i]; <--- can I use
memcpy/pointer
assignment here to remove loop?
}
UNPROTECT(1);
I have done the long winded copy as I am a bit paranoid about the garbage
collection. My question is is it legitimate to do the following
double* oldCArray = REAL(arrayToPassToR);
UNPROTECT(1); // where the 1 would remove protection from
arrayToPassToR
and potential garbage collection
-- assume arrayToPassToR was garbage collected by R --
Rprintf("%f", oldCArray[0]);
because if arrayToPassToR is garbage collected then oldCArray will cause a
SEGFAULT when it is accessed afterwards, won't it?
Many thanks
Tom
--
PS Note this is the new email address - delete [EMAIL PROTECTED] as it
won't work soon!
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
On Mon, 14 May 2007, Martin Maechler wrote:
> Hi Henrik,
>> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
>> on Sun, 13 May 2007 21:14:24 -0700 writes:
>
>HenrikB> Hi,
>HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for matrices that
>HenrikB> handles missing values implemented in C. It has been optimized
> for
>HenrikB> memory and speed. To avoid coercing integers to doubles, and
> hence
>HenrikB> allocate an additional 200% memory, there is one C function for
>HenrikB> integers and one for doubles.
>
>HenrikB> The rowMedians() implementation is currently sitting in my
> non-CRAN
>HenrikB> package R.native available by:
>
>HenrikB> source("http://www.braju.com/R/hbLite.R";)
>HenrikB> hbLite("R.native")
>HenrikB> library(R.native)
>HenrikB> example(rowMedians)
>
>HenrikB> The source code package is available at:
>
>HenrikB> http://www.braju.com/R/repos/R.native_0.1.2.tar.gz
>
>HenrikB> Before I submit a package to CRAN consisting of pretty much just
>HenrikB> rowMedians(), would it make more sense for it to go into one of
> the
>HenrikB> core packages? If so, how should I proceed?
>
> As they say: You have to convince at least one member of R-core
> that ``it's worth it''. {Then he may have to bear the battle
> with dissenting core members ;- }
>
> I'm quite interested, but really you have to do the work of unbundling
> it from all the R.oo stuff before I have another longer look.
Also, the 'a version of rowMedians' made me wonder what other version
there was, and it seems there is one in Biobase which looks a more
natural home.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grep with fixed=TRUE and ignore.case=TRUE
On Fri, 11 May 2007, Petr Savicky wrote:
> On Wed, May 09, 2007 at 06:41:23AM +0100, Prof Brian Ripley wrote:
>> I suggest you collaborate with the person who replied that he thought this
>> was a good idea to supply patches against the R-devel sources for
>> scrutiny.
>
> A possible solution is to use strncasecmp instead of strncmp
> in function fgrep_one in R-devel/src/main/character.c.
>
> Corresponding modification of character.c is at
> http://www.cs.cas.cz/~savicky/ignore_case/character.c
> and diff file w.r.t. the original character.c (downloaded today) is at
> http://www.cs.cas.cz/~savicky/ignore_case/diff.txt
>
> This seems to work in my installation of R-devel:
>
> > x <- c("D.G cat", "d.g cat", "dog cat")
> > z <- "d.g"
> > grep(z, x, ignore.case = F, fixed = T)
> [1] 2
> > grep(z, x, ignore.case = T, fixed = T) # this is the new behavior
> [1] 1 2
> > grep(z, x, ignore.case = T, fixed = F)
> [1] 1 2 3
> >
>
> Since fgrep_one is used many times in character.c, adding igcase_opt as
> an additional argument would imply extensive changes to the file.
> So, I introduced a new function fgrep_one_igcase called only once in
> the file. Another solution is possible.
>
> I do not understand well handling multibyte chars, so I did not test
> the function with real multibyte chars, although the code for
> this option is used.
Thanks for looking into this.
strncasecmp is not standard C (not even C99), but R does have a substitute
for it. Unfortunately strncasecmp is not usable with multibyte charsets:
Linux systems have wcsncasecmp but that is not portable. In these days of
widespread use of UTF-8 that is a blocking issue, I am afraid.
In the case of grep I think all you need is
grep(tolower(pattern), tolower(x), fixed = TRUE)
and similarly for regexpr.
> Ignore case option is not meaningfull in gsub.
sub("abc", "123", c("ABCD", "abcd"), ignore.case=TRUE)
is different from 'ignore.case=FALSE', and I see the meaning as clear.
So what did you mean? (Unfortunately the tolower trick does not work for
[g]sub.)
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9666) 'aggregate' should preserve level ordering of
On Tue, 8 May 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Lutz Prechelt
> Version: 2.4.1
> OS: Windows XP
> Submission from: (NULL) (160.45.111.67)
>
>
> aggregate (from package stats) should preserve the
> ordering of levels of factors it works on and also their
> 'ordered' attribute if present.
> But it does not.
In fact it treats all grouping variables consistently, reducing them to
their levels and then data.frame does as.factor on the resulting column.
It is not at all clear this is desirable. Take the example on the help
page: 'Cold' is reported as a factor even though it is logical. It seems
better not to coerce any of the grouping factors when putting into the
data frame but rather to index the original variable, and I have
implemented that for R-devel: as a side effect your example works as you
would like. This does mean that grouping variables that are not factors
and cannot be inserted into a data frame will no longer work.
> Here is an example:
>
> ff = factor(c("a","b","a","b"),levels=c("b","a"),ordered=T)
> agg = aggregate(1:4, list(groups=ff), sum)
> print(levels(agg$groups)) # should be: "b" "a"
> [1] "a" "b"
> print(is.ordered(agg$groups)) # should be: TRUE
> [1] FALSE
>
> -
>
> ?aggregate ignores the issue completely:
> - the terms 'order' or 'level' do not occur in the
> text at all
> - the term 'factor' is mentioned only once:
> "The elements of the list will be coerced to
> factors (if they are not already factors)."
>
> -
>
> This issue made me write the following code used
> for preparing the data for a barchart:
>
> df.a = aggregate(df[,value.var],
> list(grouping=dfgrouping, other=dfsubbar.var),
> FUN=FUN)
> if (is.factor(dfsubbar.var)) { # R 2.4: this should be done by 'aggregate'
>df.a$other = factor(df.a$other,
>levels=levels(dfsubbar.var),
>ordered=is.ordered(dfsubbar.var))
> }
>
> Cumbersome.
>
> R is great anyway. Thanks for your service building it!
>
> Lutz Prechelt
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] round(#, digits=x) unreliable for x=2 (PR#9682)
Full_Name: Scott Wilkinson Version: 2.3.1 OS: WinXP Pro Submission from: (NULL) (140.253.203.4) In the example below round() does not report to the specified number of digits when the last digit to be reported is zero: Compare behaviour for 0.897575 and 0.946251. Ditto for signif(). The number of sigfigs is ambiguous unless the reader knows this behaviour. Is this a bug or intended behaviour? Is there a work-around? #Example code: number <- 0.897575 # this one isn't reported to 2 decimal places 0.90 as expected #number <- 0.946251 # when the last reported digit is non-zero it gives expected behaviour Round3 <- round(number, digits=3) Round2 <- round(number, digits=2) #why 0.9 and not 0.90 for 0.897575? Round1 <- round(number, digits=1) Signif3 <- signif(number, digits=3) Signif2 <- signif(number, digits=2)#why 0.9 and not 0.90 0.897575? Signif1 <- signif(number, digits=1) Results <- data.frame(Round3, Round2, Round1, Signif3, Signif2, Signif1) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
On 5/14/07, Martin Maechler <[EMAIL PROTECTED]> wrote:
> Hi Henrik,
> > "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> > on Sun, 13 May 2007 21:14:24 -0700 writes:
>
> HenrikB> Hi,
> HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for matrices
> that
> HenrikB> handles missing values implemented in C. It has been optimized
> for
> HenrikB> memory and speed. To avoid coercing integers to doubles, and
> hence
> HenrikB> allocate an additional 200% memory, there is one C function for
> HenrikB> integers and one for doubles.
>
> HenrikB> The rowMedians() implementation is currently sitting in my
> non-CRAN
> HenrikB> package R.native available by:
>
> HenrikB> source("http://www.braju.com/R/hbLite.R";)
> HenrikB> hbLite("R.native")
> HenrikB> library(R.native)
> HenrikB> example(rowMedians)
>
> HenrikB> The source code package is available at:
>
> HenrikB> http://www.braju.com/R/repos/R.native_0.1.2.tar.gz
>
> HenrikB> Before I submit a package to CRAN consisting of pretty much just
> HenrikB> rowMedians(), would it make more sense for it to go into one of
> the
> HenrikB> core packages? If so, how should I proceed?
>
> As they say: You have to convince at least one member of R-core
> that ``it's worth it''. {Then he may have to bear the battle
> with dissenting core members ;- }
>
> I'm quite interested, but really you have to do the work of unbundling
> it from all the R.oo stuff before I have another longer look.
Great. The R code without R.oo (that's what it does), will be
rowMedians.matrix <- function(x, na.rm=FALSE, ...) {
.Call("rowMedians", x, as.logical(na.rm), PACKAGE="R.native");
}
rowMedians <- function(...) UseMethod("rowMedians", ...)
and the C code is in src/rowMedians.c, and the doc in
man/rowMedians.matrix.R (all in
http://www.braju.com/R/repos/R.native_0.1.2.tar.gz).
Thanks
Henrik
PS. I'll be off email until Friday (US time). DS.
>
> Martin
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
On 5/14/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> On Mon, 14 May 2007, Martin Maechler wrote:
>
> > Hi Henrik,
> >> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> >> on Sun, 13 May 2007 21:14:24 -0700 writes:
> >
> >HenrikB> Hi,
> >HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for matrices
> > that
> >HenrikB> handles missing values implemented in C. It has been optimized
> > for
> >HenrikB> memory and speed. To avoid coercing integers to doubles, and
> > hence
> >HenrikB> allocate an additional 200% memory, there is one C function for
> >HenrikB> integers and one for doubles.
> >
> >HenrikB> The rowMedians() implementation is currently sitting in my
> > non-CRAN
> >HenrikB> package R.native available by:
> >
> >HenrikB> source("http://www.braju.com/R/hbLite.R";)
> >HenrikB> hbLite("R.native")
> >HenrikB> library(R.native)
> >HenrikB> example(rowMedians)
> >
> >HenrikB> The source code package is available at:
> >
> >HenrikB> http://www.braju.com/R/repos/R.native_0.1.2.tar.gz
> >
> >HenrikB> Before I submit a package to CRAN consisting of pretty much just
> >HenrikB> rowMedians(), would it make more sense for it to go into one of
> > the
> >HenrikB> core packages? If so, how should I proceed?
> >
> > As they say: You have to convince at least one member of R-core
> > that ``it's worth it''. {Then he may have to bear the battle
> > with dissenting core members ;- }
> >
> > I'm quite interested, but really you have to do the work of unbundling
> > it from all the R.oo stuff before I have another longer look.
>
> Also, the 'a version of rowMedians' made me wonder what other version
> there was, and it seems there is one in Biobase which looks a more
> natural home.
The rowMedians() in Biobase utilizes rowQ() in ditto. I actually
started of by adding support for missing values to rowQ() resulting in
the method rowQuantiles(), for which there are also internal functions
for both integer and double matrices. rowQuantiles() is in R.native
too, but since it has much less CPU milage I wanted to wait with that.
The rowMedians() is developed from my rowQuantiles() optimized for
the 50% quantile.
Why do you think it is more natural to host rowMedians() in Biobase
than in one of the core R packages? Biobase comes with a lot of
overhead for people not in the Bio-world.
/Henrik
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
On Mon, 14 May 2007, Henrik Bengtsson wrote: > On 5/14/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: >> >> > Hi Henrik, >> >> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]> >> >> on Sun, 13 May 2007 21:14:24 -0700 writes: >> > >> >HenrikB> Hi, >> >HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for >> matrices that >> >HenrikB> handles missing values implemented in C. It has been [...] >> Also, the 'a version of rowMedians' made me wonder what other version >> there was, and it seems there is one in Biobase which looks a more >> natural home. > > The rowMedians() in Biobase utilizes rowQ() in ditto. I actually > started of by adding support for missing values to rowQ() resulting in > the method rowQuantiles(), for which there are also internal functions > for both integer and double matrices. rowQuantiles() is in R.native > too, but since it has much less CPU milage I wanted to wait with that. > The rowMedians() is developed from my rowQuantiles() optimized for > the 50% quantile. > > Why do you think it is more natural to host rowMedians() in Biobase > than in one of the core R packages? Biobase comes with a lot of > overhead for people not in the Bio-world. Because that is where there seems to be a need for it, and having multiple functions of the same name in different packages is not ideal (and even with namespaces can cause confusion). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round(#, digits=x) unreliable for x=2 (PR#9682)
On 13/05/2007 8:46 PM, [EMAIL PROTECTED] wrote: > Full_Name: Scott Wilkinson > Version: 2.3.1 > OS: WinXP Pro > Submission from: (NULL) (140.253.203.4) > > > In the example below round() does not report to the specified number of digits > when the last digit to be reported is zero: Compare behaviour for 0.897575 and > 0.946251. Ditto for signif(). The number of sigfigs is ambiguous unless the > reader knows this behaviour. Is this a bug or intended behaviour? Is there a > work-around? It's not a bug. It has nothing to do with round(), it is the way R prints numbers by default. If you ask to print 0.90, you'll get [1] 0.9 because 0.9 and 0.90 are the same number. If you want trailing zeros to print, you need to specify a format to do that, e.g. > noquote(format(0.9, nsmall=2)) [1] 0.90 The noquote stops the "" from printing. You could also use sprintf() or formatC() for more C-like format specifications. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9676) dump function and compatibility of .RData files
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --27464147-1671525898-1179141186=:28940 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 11 May 2007, [EMAIL PROTECTED] wrote: > Full_Name: frédéric Gosselin > Version: 2.5 & 2.2.1 > OS: windows XP pro > Submission from: (NULL) (195.221.118.52) > > > (i) I cannot read .Rdata saved with R2.5 with R2.2.1. I think it was the same > with R2.4 vs R2.2.1. If you use new features in 2.5.0 (sic) then that is not a bug. We do not claim forwards compatibility of formats (that is that R 2.2.1 can read files written in later versions of R). Without a reproducible example there is nothing more to add. > (ii) I have found the strange following problem, using the dump function: > dump(ls(),"text.txt") > > in the text.txt file, there are a lot of "L" added at the end of > numbers, particularly in the .Dim attributes. This makes the file > undreadable (at least in R2.2.1 but alos probably in S-Plus...) Please do read the help page: it points you to ?.deparseOpts for options for backwards and S-PLUS compatibility. The file is readable in R >= 2.5.0 and moreover is a more accurate representation than before. > I do not know in which respect both potential bugs are related. Only in that the same user misunderstood both. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 --27464147-1671525898-1179141186=:28940-- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] changing the mode of a factor (PR#9675)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-942662499-1179141762=:28940
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <[EMAIL PROTECTED]>
How about the following NEWS item (a bug fix)
o Assigning class "factor" to an object now requires it has
integer (and not say double) codes.
? (Changing the mode to double amounted to creating a new double vector
and then assigning the attributes of the old object including the class.
We gave a more specific error message in this case in an attempt to be
helpful )
>From ?factor
'factor' returns an object of class '"factor"' which has a set of
integer codes the length of 'x' with a '"levels"' attribute of
mode 'character'. If 'ordered' is true (or 'ordered' is used) the
result has class 'c("ordered", "factor")'.
So a factor necessarily has integer codes. That you were able to change
the mode in earlier versions of R was a bug that has been fixed.
You may well want one of the answers to FAQ 7.10.
Please take note of the 'BUGS' section in the FAQ and the posting guide:
three incorrect bug items in one day is unhelpful.
On Fri, 11 May 2007, [EMAIL PROTECTED] wrote:
> Full_Name: Frédéric Gosselin
> Version: 2.5 vs 2.4 and 2.2.1
> OS: windows XP
> Submission from: (NULL) (195.221.118.52)
>
>
> #
> L3 <- LETTERS[1:3]
> (d <- data.frame(cbind(x=1, y=1:10), fac=as.factor(sample(L3, 10,
> repl=TRUE
> mode(d[,3])<-"numeric"
> ###
>
> when trying to change the mode of a column in a data.frame that is a factor to
> numeric(cf. preceding code), the following error occurs (in French) in R 2.5:
>
> Erreur dans `storage.mode<-`(`*tmp*`, value = "double") :
>le mode de stockage d'un objet "factor" ne peut être modifié
>
> The same thing works fine in R2.4 and 2.2.1.
>
> It does not seem to correspond to new things announced in the NEWS file for
> the
> 2.5 version...
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
--27464147-942662499-1179141762=:28940--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] file separator inconsistencies on windows?
tempdir() on windows returns the path using "\\" as file separator. But .Platform$file.sep returns "/". As a result, you get inconsistencies like: > file.path(tempdir(), "foo") [1] "C:\\WINDOWS\\Temp\\RtmpYEIXrb/foo" # Mix of \\ and / I'm not sure if this can cause problems but I thought I'd let you know just in case. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Mon, 14 May 2007 11:39:18 +0100 (BST) writes:
BDR> On Mon, 14 May 2007, Henrik Bengtsson wrote:
>> On 5/14/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
>>>
>>> > Hi Henrik,
>>> >> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
>>> >> on Sun, 13 May 2007 21:14:24 -0700 writes:
>>> >
>>> >HenrikB> Hi,
>>> >HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for
>>> matrices that
>>> >HenrikB> handles missing values implemented in C. It has been
BDR> [...]
>>> Also, the 'a version of rowMedians' made me wonder what other version
>>> there was, and it seems there is one in Biobase which looks a more
>>> natural home.
>>
>> The rowMedians() in Biobase utilizes rowQ() in ditto. I actually
>> started of by adding support for missing values to rowQ() resulting in
>> the method rowQuantiles(), for which there are also internal functions
>> for both integer and double matrices. rowQuantiles() is in R.native
>> too, but since it has much less CPU milage I wanted to wait with that.
>> The rowMedians() is developed from my rowQuantiles() optimized for
>> the 50% quantile.
>>
>> Why do you think it is more natural to host rowMedians() in Biobase
>> than in one of the core R packages? Biobase comes with a lot of
>> overhead for people not in the Bio-world.
BDR> Because that is where there seems to be a need for it, and having
multiple
BDR> functions of the same name in different packages is not ideal (and
even
BDR> with namespaces can cause confusion).
That's correct, of course.
However, I still think that quantiles (and statistics derived
from them) in general and medians in particular are under-used
by many user groups. For some useRs, speed can be an important
reason and for that I had made a big effort to provide runmed()
in R, and I think it would be worthwhile to provide fast rowwise
medians and quantiles, here as well.
Also, BTW, I think it will be worthwhile to provide (R<->C) API
versions of median() and quantile() {with less options than the
R functions, most probably!!},
such that we'd hopefully see less re-invention of the wheel
happening in every package that needs such quantiles in its C code.
Biobase is in quite active maintenance, and I'd assume its
maintainers will remove rowMedians() from there (or first
replace it with a wrapper in order to deal with the namespace
issue you mentioned) as soon as R has its own function
with the same (or better) functionality.
In order to facilitate the transition, we'd have to make sure
that such a 'stats' function does behave " >= " to the bioBase
one.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
We did think about this a lot, and decided it was better to have
something like rowQ, which really returns requested order statistics,
letting the user manipulate them on the return for their own version of
median, or other quantiles, was a better approach. I would be happy to
have this in R itself, if there is sufficient interest and we can remove
the one in Biobase (without the need for deprecation/defunct as long as
the args are compatible). But, if the decision is to return a particular
estimate of a quantile, then we would probably want to keep our function
around, with its current name.
best wishes
Robert
Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Mon, 14 May 2007 11:39:18 +0100 (BST) writes:
>
> BDR> On Mon, 14 May 2007, Henrik Bengtsson wrote:
> >> On 5/14/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> >>>
> >>> > Hi Henrik,
> >>> >> "HenrikB" == Henrik Bengtsson <[EMAIL PROTECTED]>
> >>> >> on Sun, 13 May 2007 21:14:24 -0700 writes:
> >>> >
> >>> >HenrikB> Hi,
> >>> >HenrikB> I've got a version of rowMedians(x, na.rm=FALSE) for
> >>> matrices that
> >>> >HenrikB> handles missing values implemented in C. It has been
>
> BDR> [...]
>
> >>> Also, the 'a version of rowMedians' made me wonder what other version
> >>> there was, and it seems there is one in Biobase which looks a more
> >>> natural home.
> >>
> >> The rowMedians() in Biobase utilizes rowQ() in ditto. I actually
> >> started of by adding support for missing values to rowQ() resulting in
> >> the method rowQuantiles(), for which there are also internal functions
> >> for both integer and double matrices. rowQuantiles() is in R.native
> >> too, but since it has much less CPU milage I wanted to wait with that.
> >> The rowMedians() is developed from my rowQuantiles() optimized for
> >> the 50% quantile.
> >>
> >> Why do you think it is more natural to host rowMedians() in Biobase
> >> than in one of the core R packages? Biobase comes with a lot of
> >> overhead for people not in the Bio-world.
>
> BDR> Because that is where there seems to be a need for it, and having
> multiple
> BDR> functions of the same name in different packages is not ideal (and
> even
> BDR> with namespaces can cause confusion).
>
> That's correct, of course.
> However, I still think that quantiles (and statistics derived
> from them) in general and medians in particular are under-used
> by many user groups. For some useRs, speed can be an important
> reason and for that I had made a big effort to provide runmed()
> in R, and I think it would be worthwhile to provide fast rowwise
> medians and quantiles, here as well.
>
> Also, BTW, I think it will be worthwhile to provide (R<->C) API
> versions of median() and quantile() {with less options than the
> R functions, most probably!!},
> such that we'd hopefully see less re-invention of the wheel
> happening in every package that needs such quantiles in its C code.
>
> Biobase is in quite active maintenance, and I'd assume its
> maintainers will remove rowMedians() from there (or first
> replace it with a wrapper in order to deal with the namespace
> issue you mentioned) as soon as R has its own function
> with the same (or better) functionality.
> In order to facilitate the transition, we'd have to make sure
> that such a 'stats' function does behave " >= " to the bioBase
> one.
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Native implementation of rowMedians()
On 14 May 2007 at 14:31, Martin Maechler wrote: | However, I still think that quantiles (and statistics derived | from them) in general and medians in particular are under-used | by many user groups. For some useRs, speed can be an important | reason and for that I had made a big effort to provide runmed() | in R, and I think it would be worthwhile to provide fast rowwise | medians and quantiles, here as well. Seconded. I don't see anything particular 'bio' about that. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] file separator inconsistencies on windows?
On Mon, 14 May 2007, Ernest Turro wrote: > tempdir() on windows returns the path using "\\" as file separator. Yes, it is explicitly documented to. > But .Platform$file.sep returns "/". As a result, you get > inconsistencies like: > > > file.path(tempdir(), "foo") > > [1] "C:\\WINDOWS\\Temp\\RtmpYEIXrb/foo" # Mix of \\ and / > > I'm not sure if this can cause problems but I thought I'd let you > know just in case. It doesn't cause problems AFAIK. The main place you need \ is when passing filepaths to a Windows shell, a few Windows executables and a very few API functions (where we convert in the wrappers). OTOH, / is needed when passing to a Unix-like shell, make Note that e.g. shell() on Windows has an argument to translate / to \ if necessary. There is a problem with network shares like \\machine\path\to\file. Those are essentially incompatible with POSIX and a lot of the tools we use for R, but I've started to make them work as far as is practicable. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best Practise
Tom McCallum <[EMAIL PROTECTED]> writes:
> Hello,
>
>
> Just a quick question on best practise. I am converting quite a bit of
> legacy C code into R packages and have the following situation:
>
> (1) Legacy object with a double* array in, all over code so don't want to
> change any more than I have to.
>
> (2) Do something like:
> SEXP arrayToPassToR;
> PROTECT( arrayToPassToR = allocVector( REALSXP, n ) );
> for(i=0; i < n; i++) {
> REAL(arrayToPassToR)[i] = oldCarray[i]; < very slow way
> to copy
> data, can I use memcpy/pointer assignment here to remove the loop without
> running into garbage collector?
You can use memcpy and that should be no different semantically from
the loop. You cannot reassign the pointer.
Perhaps it is possible to refactor the part of your legacy code that
allocates the vector to begin with? Then you can use R's allocVector
and send the pointer to the alloc'd vector off to your code.
> (3) Have made it to call back to an R function which returns a new /
> different SEXP double array.
> returnValueFromR = Test_tryEval(...);
> (4) Copy back to oldCArray
> for(i=0; i < n; i++) {
> oldCarray[i] = REAL(returnValueFromR)[i]; <--- can I use
> memcpy/pointer
> assignment here to remove loop?
> }
> UNPROTECT(1);
Depending on how you will use oldCarray, you may not need a copy at
all. If you have a function that takes a double* then you can pass in
REAL(returnValueFromR).
> I have done the long winded copy as I am a bit paranoid about the garbage
> collection. My question is is it legitimate to do the following
>
> double* oldCArray = REAL(arrayToPassToR);
> UNPROTECT(1); // where the 1 would remove protection from
> arrayToPassToR
> and potential garbage collection
> -- assume arrayToPassToR was garbage collected by R --
> Rprintf("%f", oldCArray[0]);
>
> because if arrayToPassToR is garbage collected then oldCArray will cause a
> SEGFAULT when it is accessed afterwards, won't it?
If you UNPROTECT arrayToPassToR, then the next time R's gc runs
oldCArray will be invalid.
It isn't clear to me from your post what exactly you are trying to do
(and your subject line is confusing, this isn't a best practice
question IMO, but a how do I use R objects in C question).
Perhaps the above hints will get you going. I would recommend reading
over the relevant sections of the Writing R Extensions manual and the
R internals manual.
+ 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
[Rd] RFC: allow packages to advertise vignettes on Windows
Hello,
The vignette concept, which started in Bioconductor, seems to be
catching on. They are supported by R CMD build/check and documented
in the Writing R Extensions manual. I think vignettes are a fantastic
way to introduce new users to a package. However, getting new users
to realize that a vignette is available can be challenging.
For some time now, we have had a function in Biobase that creates a
"Vignettes" menu item in the R Windows GUI and gives packages a
mechanism to register their vignettes so that they appear on this
menu. I would like to see this functionality included in R so that
there can be a standard mechanism that doesn't depend on Biobase of
registering a package's vignettes with one of the R GUIs (currently
only Windows is supported, but I imagine the OS X GUI could also
implement this).
Below is the implementation we have been using. Is there an R-core
member I can interest in pushing this along? I'm willing to submit a
patch with documentation, etc.
+ seth
addVigs2WinMenu <- function(pkgName) {
if ((.Platform$OS.type == "windows") && (.Platform$GUI == "Rgui")
&& interactive()) {
vigFile <- system.file("Meta", "vignette.rds", package=pkgName)
if (!file.exists(vigFile)) {
warning(sprintf("%s contains no vignette, nothing is added to the
menu bar", pkgName))
} else {
vigMtrx <- .readRDS(vigFile)
vigs <- file.path(.find.package(pkgName), "doc", vigMtrx[,"PDF"])
names(vigs) <- vigMtrx[,"Title"]
if (!"Vignettes" %in% winMenuNames())
winMenuAdd("Vignettes")
pkgMenu <- paste("Vignettes", pkgName, sep="/")
winMenuAdd(pkgMenu)
for (i in vigs) {
item <- sub(".pdf", "", basename(i))
winMenuAddItem(pkgMenu, item, paste("shell.exec(\"",
as.character(i), "\")", sep = ""))
}
} ## else
ans <- TRUE
} else {
ans <- FALSE
}
ans
}
--
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
[Rd] set_seed
Hi, All: It seemed set_seed is usable only when Rmath is used as a standalone library, then what should I use when I need to link to R.dll. Thanks . tong __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: allow packages to advertise vignettes on Windows
On 14/05/2007 7:15 PM, Seth Falcon wrote:
> Hello,
>
> The vignette concept, which started in Bioconductor, seems to be
> catching on. They are supported by R CMD build/check and documented
> in the Writing R Extensions manual. I think vignettes are a fantastic
> way to introduce new users to a package. However, getting new users
> to realize that a vignette is available can be challenging.
>
> For some time now, we have had a function in Biobase that creates a
> "Vignettes" menu item in the R Windows GUI and gives packages a
> mechanism to register their vignettes so that they appear on this
> menu. I would like to see this functionality included in R so that
> there can be a standard mechanism that doesn't depend on Biobase of
> registering a package's vignettes with one of the R GUIs (currently
> only Windows is supported, but I imagine the OS X GUI could also
> implement this).
>
> Below is the implementation we have been using. Is there an R-core
> member I can interest in pushing this along? I'm willing to submit a
> patch with documentation, etc.
I'm interested in making vignettes more visible. Putting them on the
menu is not the only way, but since you're offering to do the work, I
think it's a good idea :-).
A few questions:
- Should packages need to take any action to register their vignettes,
or should this happen automatically for anything that the vignette()
function would recognize as a vignette?
My recommendation would be for automatic installation.
- Should it happen when the package is installed or when it is attached?
This is harder. vignette() detects installed vignettes, which is fine
if not many packages have them. But I think the hope is that most
packages will eventually, and then I think you wouldn't want the menu to
list every package. Maybe default to attached packages, but expose the
function below for people who want more?
- Should they appear in a top level Vignettes menu, or as a submenu of
the Help menu?
I'd lean towards keeping the top level placement, since you've already
got an audience who are used to that.
By the way, another way to expose vignettes is to have them
automatically added to the package help topic, with links in formats
that support them. I think we should do that too, but I don't know if
it'll happen soon.
Duncan Murdoch
>
> + seth
>
> addVigs2WinMenu <- function(pkgName) {
> if ((.Platform$OS.type == "windows") && (.Platform$GUI == "Rgui")
> && interactive()) {
> vigFile <- system.file("Meta", "vignette.rds", package=pkgName)
> if (!file.exists(vigFile)) {
> warning(sprintf("%s contains no vignette, nothing is added to the
> menu bar", pkgName))
> } else {
> vigMtrx <- .readRDS(vigFile)
> vigs <- file.path(.find.package(pkgName), "doc", vigMtrx[,"PDF"])
> names(vigs) <- vigMtrx[,"Title"]
>
> if (!"Vignettes" %in% winMenuNames())
> winMenuAdd("Vignettes")
> pkgMenu <- paste("Vignettes", pkgName, sep="/")
> winMenuAdd(pkgMenu)
> for (i in vigs) {
> item <- sub(".pdf", "", basename(i))
> winMenuAddItem(pkgMenu, item, paste("shell.exec(\"",
> as.character(i), "\")", sep = ""))
> }
> } ## else
> ans <- TRUE
> } else {
> ans <- FALSE
> }
> ans
> }
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: allow packages to advertise vignettes on Windows
Duncan Murdoch <[EMAIL PROTECTED]> writes: > I'm interested in making vignettes more visible. Putting them on the > menu is not the only way, but since you're offering to do the work, I > think it's a good idea :-). Excellent :-) > A few questions: > > - Should packages need to take any action to register their > vignettes, or should this happen automatically for anything that the > vignette() function would recognize as a vignette? > > My recommendation would be for automatic installation. That seems ok to me. Currently, we have a system that requires package authors to register their vignette in .onAttach (more on that below). I can't really think of a case where a package provides vignettes and doesn't want them easily accessible to new users in a GUI environment. > - Should it happen when the package is installed or when it is >attached? > > This is harder. vignette() detects installed vignettes, which is fine > if not many packages have them. But I think the hope is that most > packages will eventually, and then I think you wouldn't want the menu > to list every package. Maybe default to attached packages, but expose > the function below for people who want more? My feeling is that this is only appropriate for attached packages. As you point out, adding an entry for every installed package could create a cluttered menu (and present implementation challenges to avoid slowness). I also think that packages that get loaded via other packages name spaces should remain in stealth mode. There is another reason to only list vignettes for attached packages. One of the primary uses of a vignette is to allow the user to work through an example use case interactively. This requires the package to be attached in almost all cases. > - Should they appear in a top level Vignettes menu, or as a submenu > of the Help menu? > > I'd lean towards keeping the top level placement, since you've already > got an audience who are used to that. Sounds good. > By the way, another way to expose vignettes is to have them > automatically added to the package help topic, with links in formats > that support them. I think we should do that too, but I don't know if > it'll happen soon. Also sounds good, but one thing at a time, I guess. If there is some agreement about vignettes being automatically added and that this only happens when a package is attached, then I can look into modifying the existing function to handle this. + 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
Re: [Rd] set_seed
On Mon, 14 May 2007, Tong Wang wrote: > Hi, All: > It seemed set_seed is usable only when Rmath is used as a standalone > library, then what should I use when I need to link to R.dll. When you link to R.dll you are running R, so you can call set.seed() via eval or via do_setseed. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] set_seed
In this case, how do I choose numbers to make sure set_seed(n1,n2) and set.seed(n) produce the same result ? I am asking because my C code worked correctly if I compile it to produce .exe file and ran it , but it gave strange results if it is compiled to .dll file and dynamically loaded into R and call with .C( ). To debug, I need to let them produce the same random number under two different situation so I can tell what is wrong in R. Thanks a lot. - Original Message - From: Prof Brian Ripley <[EMAIL PROTECTED]> Date: Monday, May 14, 2007 9:40 pm Subject: Re: [Rd] set_seed To: Tong Wang <[EMAIL PROTECTED]> Cc: R-devel > On Mon, 14 May 2007, Tong Wang wrote: > > > Hi, All: > > > It seemed set_seed is usable only when Rmath is used as a > standalone > > library, then what should I use when I need to link to R.dll. > > When you link to R.dll you are running R, so you can call > set.seed() via > eval or via do_setseed. > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] optim bug (PR#9684)
Full_Name: Christina Merz Version: R version 2.5.0 (2007-04-23) OS: mingw32 Submission from: (NULL) (213.70.209.132) R> version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.0 year 2007 month 04 day23 svn rev41293 language R version.string R version 2.5.0 (2007-04-23) - R> sessionInfo() R version 2.5.0 (2007-04-23) i386-pc-mingw32 locale: LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" [7] "base" --- 'optim' does not accept arguments called 'u'. Here is an example: R> fun<-function(x,u) (x-u)^2 R> optim(7,fn=fun,u=9) Fehler in fn(par, ...) : Argument "u" fehlt (ohne Standardwert) Zusätzlich: Warning message: bounds can only be used with method L-BFGS-B in: optim(7, fn = fun, u = 9) while R> fun<-function(x,y) (x-y)^2 R> optim(7,fn=fun,y=9) $par [1] 8.999854 $value [1] 2.145767e-08 $counts function gradient 28 NA $convergence [1] 0 $message NULL Warning message: one-diml optimization by Nelder-Mead is unreliable: use optimize in: optim(7, fn = fun, y = 9) -Christina __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Calling erf function in package NORMT3 produce a R crash on Linux/AMD opteron (PR#9683)
Full_Name: Benjamin Leblanc
Version: 2.4.1 and 2.5.0
OS: Ubuntu Linux 7.04 AMD64
Submission from: (NULL) (195.83.84.213)
Here is an example script that may crash under R with Linux AMD 64 bit
platforms
library('NORMT3')
a <- 1:1000/1000
erf(a)
I did several tests:
- opensuse 10.2 x86_64 with R 2.4.1 and R 2.5.0, produce systematically a frozen
R session
- ubuntu 7.04 AMD64, R 2.4.1 and R version 2.5.0 (2007-04-23), produce a memory
corruption
Here is an example with core dump on ubuntu 7.04 AMD64, R version 2.5.0
(2007-04-23):
> a <- 1:100/200
> erf(a)
*** glibc detected *** /usr/lib/R/bin/exec/R: malloc(): memory corruption:
0x01308500 ***
=== Backtrace: =
/lib/libc.so.6[0x2b0cc3b9f1d1]
/lib/libc.so.6(__libc_malloc+0x7d)[0x2b0cc3ba098d]
/usr/lib/R/lib/libR.so(Rf_allocVector+0x4cc)[0x2b0cc36e9c3c]
/usr/lib/R/lib/libR.so[0x2b0cc368d42b]
/usr/lib/R/lib/libR.so(Rf_eval+0x6ea)[0x2b0cc36bfb6a]
/usr/lib/R/lib/libR.so[0x2b0cc36c2370]
/usr/lib/R/lib/libR.so(Rf_eval+0x48b)[0x2b0cc36bf90b]
/usr/lib/R/lib/libR.so[0x2b0cc36c0ca2]
/usr/lib/R/lib/libR.so(Rf_eval+0x48b)[0x2b0cc36bf90b]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x286)[0x2b0cc36c2be6]
/usr/lib/R/lib/libR.so(Rf_eval+0x2f4)[0x2b0cc36bf774]
/usr/lib/R/lib/libR.so[0x2b0cc36c0618]
/usr/lib/R/lib/libR.so(Rf_eval+0x552)[0x2b0cc36bf9d2]
/usr/lib/R/lib/libR.so(Rf_applyClosure+0x286)[0x2b0cc36c2be6]
/usr/lib/R/lib/libR.so(Rf_eval+0x2f4)[0x2b0cc36bf774]
/usr/lib/R/lib/libR.so(Rf_ReplIteration+0x2de)[0x2b0cc36e2f4e]
/usr/lib/R/lib/libR.so(run_Rmainloop+0xc2)[0x2b0cc36e3112]
/usr/lib/R/bin/exec/R(main+0x1b)[0x40088b]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2b0cc3b4c8e4]
/usr/lib/R/bin/exec/R[0x4007aa]
=== Memory map:
0040-00401000 r-xp 08:02 8669401
/usr/lib/R/bin/exec/R
0050-00501000 rw-p 08:02 8669401
/usr/lib/R/bin/exec/R
00501000-01b4b000 rw-p 00501000 00:00 0 [heap]
2b0cc33e2000-2b0cc33fe000 r-xp 08:02 14549011
/lib/ld-2.5.so
2b0cc33fe000-2b0cc3401000 rw-p 2b0cc33fe000 00:00 0
2b0cc35fd000-2b0cc35ff000 rw-p 0001b000 08:02 14549011
/lib/ld-2.5.so
2b0cc35ff000-2b0cc384b000 r-xp 08:02 8669405
/usr/lib/R/lib/libR.so
2b0cc384b000-2b0cc394b000 ---p 0024c000 08:02 8669405
/usr/lib/R/lib/libR.so
2b0cc394b000-2b0cc395e000 rw-p 0024c000 08:02 8669405
/usr/lib/R/lib/libR.so
2b0cc395e000-2b0cc39f8000 rw-p 2b0cc395e000 00:00 0
2b0cc39f8000-2b0cc3a23000 r-xp 08:02 8669404
/usr/lib/R/lib/libRblas.so
2b0cc3a23000-2b0cc3b22000 ---p 0002b000 08:02 8669404
/usr/lib/R/lib/libRblas.so
2b0cc3b22000-2b0cc3b23000 rw-p 0002a000 08:02 8669404
/usr/lib/R/lib/libRblas.so
2b0cc3b23000-2b0cc3b24000 r--p 08:02 8028234
/usr/lib/locale/fr_FR.utf8/LC_MESSAGES/SYS_LC_MESSAGES
2b0cc3b24000-2b0cc3b2b000 r--s 08:02 9273579
/usr/lib/gconv/gconv-modules.cache
2b0cc3b2f000-2b0cc3c76000 r-xp 08:02 14549029
/lib/libc-2.5.so
2b0cc3c76000-2b0cc3e76000 ---p 00147000 08:02 14549029
/lib/libc-2.5.so
2b0cc3e76000-2b0cc3e79000 r--p 00147000 08:02 14549029
/lib/libc-2.5.so
2b0cc3e79000-2b0cc3e7b000 rw-p 0014a000 08:02 14549029
/lib/libc-2.5.so
2b0cc3e7b000-2b0cc3e8 rw-p 2b0cc3e7b000 00:00 0
2b0cc3e8-2b0cc3f19000 r-xp 08:02 11288626
/usr/lib/libgfortran.so.1.0.0
2b0cc3f19000-2b0cc4118000 ---p 00099000 08:02 11288626
/usr/lib/libgfortran.so.1.0.0
2b0cc4118000-2b0cc411a000 rw-p 00098000 08:02 11288626
/usr/lib/libgfortran.so.1.0.0
2b0cc411a000-2b0cc411b000 rw-p 2b0cc411a000 00:00 0
2b0cc411b000-2b0cc419c000 r-xp 08:02 14549060
/lib/libm-2.5.so
2b0cc419c000-2b0cc439b000 ---p 00081000 08:02 14549060
/lib/libm-2.5.so
2b0cc439b000-2b0cc439d000 rw-p 0008 08:02 14549060
/lib/libm-2.5.so
2b0cc439d000-2b0cc43aa000 r-xp 08:02 14549054
/lib/libgcc_s.so.1
2b0cc43aa000-2b0cc45aa000 ---p d000 08:02 14549054
/lib/libgcc_s.so.1
2b0cc45aa000-2b0cc45ab000 rw-p d000 08:02 14549054
/lib/libgcc_s.so.1
2b0cc45ab000-2b0cc45e1000 r-xp 08:02 14549102
/lib/libreadline.so.5.2
2b0cc45e1000-2b0cc47e1000 ---p 00036000 08:02 14549102
/lib/libreadline.soAbandon (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] read.table() can't read in this table (But Splus can) (PR#9685)
Full_Name: vax, 9000
Version: 2.4.0, 2.2.1
OS: 2.4.0: Mac OS X; 2.2.1: Linux
Submission from: (NULL) (192.35.79.70)
To reproduce this bug, first go to the website "http://llmpp.nih.gov/DLBCL/"; and
download the 14.8M data set "Web Figure 1 Data file". The direct link is
"http://llmpp.nih.gov/DLBCL/NEJM_Web_Fig1data";. Save it as "datafile.txt"
Then, start R, type in command "x <- read.table("datafile.txt", header=TRUE,
sep="\t")". The data has 7400 lines, but not all lines could be read in by R.
Easier test data set:
Use the command "head -n 100 datafile.txt > shortdatafile.txt" to extract the
first 100 lines. The R command "x <- read.table("datafile.txt", header=TRUE,
sep="\t")" could not read in even this 100 lines of data.
But Splus can, with the same command. What is wrong?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] XML parsing under R / Extracting nodes’ v alues
Hi, I have an XML file which contains among other nodes : ===myXMLfile.xml=== (…) 2 2 (...) 5 2000 (…) ===End file=== I need to extract those values and to make them R variables such as: nbRelations = 2 nbActors = 2 nbRuns = 5 nbSteps = 2000 I read the help and have seen the examples of the xml package, it seems that I need to use xmlTreeParse() function but I don't know how exactly as I'm not an R advanced programmer, please can anyone show me how to do that explicitly ? Any help would be much appreciated Thanks, Abdel University of Boumerdès Algeria __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R (PR#9686)
Full_Name: Chiadi Onyike Version: 2.5 OS: Mac OS 10.4.9 Submission from: (NULL) (71.248.49.27) Every time I launch the program, I get the following message: 2007-05-15 01:10:00.959 Installer[2410] *** -[NSBundle load]: Error loading code /Users/chiadionyike/Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL for bundle /Users/chiadionyike/Library/InputManagers/SIMBL/SIMBL.bundle, error code 2 (link edit error code 0, error number 0 ()) I would like to completely erase R and re-install it, but I cannot find instructions anywhere on how to do this. Can you tell me how to fix this bug or how to uninstall the program and then reinstall it? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optim bug (PR#9684)
This is not a bug, but as documented on the help page: ...: Further arguments to be passed to 'fn' and 'gr'. Beware of partial matching to earlier arguments. You have partial matching to 'upper'. On Mon, 14 May 2007, [EMAIL PROTECTED] wrote: Full_Name: Christina Merz Version: R version 2.5.0 (2007-04-23) OS: mingw32 Submission from: (NULL) (213.70.209.132) R> version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 5.0 year 2007 month 04 day23 svn rev41293 language R version.string R version 2.5.0 (2007-04-23) - R> sessionInfo() R version 2.5.0 (2007-04-23) i386-pc-mingw32 locale: LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" [7] "base" --- 'optim' does not accept arguments called 'u'. Here is an example: R> fun<-function(x,u) (x-u)^2 R> optim(7,fn=fun,u=9) Fehler in fn(par, ...) : Argument "u" fehlt (ohne Standardwert) Zusätzlich: Warning message: bounds can only be used with method L-BFGS-B in: optim(7, fn = fun, u = 9) while R> fun<-function(x,y) (x-y)^2 R> optim(7,fn=fun,y=9) $par [1] 8.999854 $value [1] 2.145767e-08 $counts function gradient 28 NA $convergence [1] 0 $message NULL Warning message: one-diml optimization by Nelder-Mead is unreliable: use optimize in: optim(7, fn = fun, y = 9) -Christina __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
