[Rd] class unions?
the code below has me confused:
setClassUnion("index", c("numeric", "character", "logical"))
extends("numeric") # i don't see the class union
library(Matrix)
extends("numeric") # now i see the class union
i am aware that the "Matrix" package separately defines the "index"
class union.
is it the case that class definitions need to occur in packages?
i am also having trouble dispatching on class unions defined in the
global environment,
which may just be the same problem. see code below:
setClassUnion("numORchar", c("numeric", "character"))
foo <- function(x) "Default"
setMethod("foo", signature(x = "numORchar"),
function(x) "numORchar")
foo(2) # gives the default method
franklin
> version
_
platform powerpc-apple-darwin8.7.0
arch powerpc
os darwin8.7.0
system powerpc, darwin8.7.0
status
major 2
minor 4.0
year 2006
month 10
day03
svn rev39566
language R
version.string R version 2.4.0 (2006-10-03)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] operator :: and symbols not in the namespace of a package with a namespace (PR#9279)
Full_Name: Thomas Friedrichsmeier
Version: 2.4.0
OS: GNU/Linux
Submission from: (NULL) (84.61.116.51)
Since R 2.4.0, operator "::" also returns objects in the package environment, if
the package does not have a namespace. This is a very welcome addition.
Additional wish:
If a package has a namespace, but does not place all symbols in that namespace,
lookup will still fail. For example in package boot (version 1.2-26):
library (boot)
exists ("motor", envir=as.environment ("package:boot")) # TRUE
getAnywhere ("motor") # found in
package:boot
boot::motor # error not in
namespace
This is as documented, but I think it would be convenient, if boot::motor would
also return the object in this case.
This might be achieved by adding an additional tryCatch in "::": If the package
has a namespace, try getExportedValue (), if that fails, try to get from package
environment instead. E.g.:
"::" <- function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
if (is.null(ns)) {
pos <- match(paste("package", pkg, sep = ":"), search(),
0)
if (pos == 0)
stop(gettextf(paste("package '%s' has no name space and",
"is not on the search path"), pkg), domain = NA)
get(name, pos = pos, inherits = FALSE)
}
else tryCatch(getExportedValue(pkg, name), error=function (e) {
pos <- match(paste("package", pkg, sep=":"), search(),
0)
get(name, pos, inherits=FALSE)
})
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operator :: and symbols not in the namespace of a package with a namespace (PR#9279)
On 10/6/2006 9:05 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Thomas Friedrichsmeier
> Version: 2.4.0
> OS: GNU/Linux
> Submission from: (NULL) (84.61.116.51)
>
>
> Since R 2.4.0, operator "::" also returns objects in the package environment,
> if
> the package does not have a namespace. This is a very welcome addition.
>
> Additional wish:
> If a package has a namespace, but does not place all symbols in that
> namespace,
> lookup will still fail. For example in package boot (version 1.2-26):
>
> library (boot)
> exists ("motor", envir=as.environment ("package:boot")) # TRUE
> getAnywhere ("motor") # found in
> package:boot
> boot::motor # error not in
> namespace
>
> This is as documented, but I think it would be convenient, if boot::motor
> would
> also return the object in this case.
At first I was ready to disagree with you, telling you to use the ":::"
operator for something that is not exported: but in fact motor is a
dataset, so it is exported from the package by being loaded into the
package environment when the package is loaded. I agree that the "::"
operator should find it.
I think the rule should be: the "::" operator looks at the symbols that
are publicly available from the package, i.e. boot::motor should
effectively be an abbreviation for
get("motor", pos="package:boot", inherits=FALSE)
after making sure boot is loaded. I think getExportedValue() is a much
more rarely needed function, so users should need to use it explicitly.
Duncan Murdoch
>
> This might be achieved by adding an additional tryCatch in "::": If the
> package
> has a namespace, try getExportedValue (), if that fails, try to get from
> package
> environment instead. E.g.:
>
> "::" <- function (pkg, name)
> {
> pkg <- as.character(substitute(pkg))
> name <- as.character(substitute(name))
> ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
> if (is.null(ns)) {
> pos <- match(paste("package", pkg, sep = ":"), search(),
> 0)
> if (pos == 0)
> stop(gettextf(paste("package '%s' has no name space and",
> "is not on the search path"), pkg), domain = NA)
> get(name, pos = pos, inherits = FALSE)
> }
> else tryCatch(getExportedValue(pkg, name), error=function (e) {
>pos <- match(paste("package", pkg, sep=":"), search(),
> 0)
>get(name, pos, inherits=FALSE)
> })
> }
>
> __
> 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] class unions?
The problem is a combination of a class union definition that includes a
basic type as a member, and is not in a package.
Class "numeric" is sealed, so at present setClassUnion() doesn't cache
the new superclass in the definition of "numeric". In 2.4.0 that
happens when a package is attached (before, it didn't happen at all).
It's _probably_ true that the caching should take place in
setClassUnion(), but that needs a little consideration.
Meanwhile the workaround is to call cacheMetaData(1) to cache the
information in the global environment--that's what happens when a
corresponding package is attached.
> setClassUnion("index", c("numeric", "character", "logical"))
[1] "index"
> cacheMetaData(1)
> extends("numeric")
[1] "numeric" "vector""index"
Parlamis Franklin wrote:
> the code below has me confused:
>
> setClassUnion("index", c("numeric", "character", "logical"))
> extends("numeric") # i don't see the class union
> library(Matrix)
> extends("numeric") # now i see the class union
>
> i am aware that the "Matrix" package separately defines the "index"
> class union.
> is it the case that class definitions need to occur in packages?
>
> i am also having trouble dispatching on class unions defined in the
> global environment,
> which may just be the same problem.
Yes. You need to cacheMetaData(1) before calling foo(2).
> see code below:
>
> setClassUnion("numORchar", c("numeric", "character"))
> foo <- function(x) "Default"
> setMethod("foo", signature(x = "numORchar"),
> function(x) "numORchar")
> foo(2) # gives the default method
>
> franklin
>
> > version
> _
> platform powerpc-apple-darwin8.7.0
> arch powerpc
> os darwin8.7.0
> system powerpc, darwin8.7.0
> status
> major 2
> minor 4.0
> year 2006
> month 10
> day03
> svn rev39566
> language R
> version.string R version 2.4.0 (2006-10-03)
>
> __
> 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] Default argument value for "["
Should now be fixed in r-devel and 2.4 patched.
Iago Mosqueira wrote:
> El mié, 04-10-2006 a las 09:52 -0400, John Chambers escribió:
>
>> I think the problem in your case comes from the mechanism used to handle
>> non-standard argument lists; notice that you have added 3 new
>> arguments.
>>
>
> Yes, our object is always 5 dimensional. We could use (...) but it
> looked overly complex.
>
>
>> If you look at the body of the resulting method you will see
>> that the mechanism used to handle this (defining a function .local)
>> fails to copy the default value from the method, as in the simpler
>> example below:
>>
>> > setMethod("[", c("mm"), function(x, i, j, k..., drop=FALSE)browser())
>> [1] "["
>> > selectMethod("[", "mm")
>> Method Definition:
>>
>> function (x, i, j, ..., drop = TRUE)
>> {
>> .local <- function (x, i, j, k..., drop = FALSE)
>> browser()
>> .local(x, i, j, ..., drop = drop)
>> }
>>
>>
>> We can probably fix this. Meanwhile, the workaround is to use the same
>> mechanism yourself, but get the default value right. Define your
>> method as a function (like the .local you see when printing the current
>> method) and then define a method with the formally correct arguments
>> (function(x, i, j, ..., drop=FALSE)) and call your function from that
>> method.
>>
>
> OK, many thanks.
>
>
>> Beware there is _another_ related "bug": if you use callNextMethod(),
>> it does not seem to copy the default value of drop= either. (It's a bit
>> more debatable what callNextMethod() with no arguments should do in this
>> case, so the problem here may be an "undesired feature" rather than a
>> bug.) You didn't show your real method, so this may not apply in your
>> example.
>>
>
> I am adding the whole method below, but I do not thing this applies as
> it is currently written.
>
>
>> By the way, I would be a little surprised if this had anything to do
>> with changes in 2.4.0, at least those I'm aware of.
>>
>
> This maybe the case, but it was working fine in 2.3.1.
>
> Cheers,
>
>
> Iago
>
> setMethod("[", signature(x="FLQuant"),
> function(x, i="missing", j="missing", k="missing", l="missing",
> m="missing",
> ..., drop=FALSE) {
>
> if (missing(i))
> #i <- dimnames([EMAIL PROTECTED])[1][[1]]
> i <- seq(1, length(dimnames([EMAIL
> PROTECTED])[1][[1]]))
> if (missing(j))
> j <- dimnames([EMAIL PROTECTED])[2][[1]]
> if (missing(k))
> k <- dimnames([EMAIL PROTECTED])[3][[1]]
> if (missing(l))
> l <- dimnames([EMAIL PROTECTED])[4][[1]]
> if (missing(m))
> m <- dimnames([EMAIL PROTECTED])[5][[1]]
>
> if (!drop) {
> flq <- FLQuant([EMAIL PROTECTED], j, k, l, m,
> drop=FALSE])
> units(flq) <- units(x)
> quant(flq) <- quant(x)
> }
> else if(drop)
> flq <- [EMAIL PROTECTED], j, k, l, m, ..., drop=TRUE]
>
> return(flq)
> }
> )
>
>
>
>> Iago Mosqueira wrote:
>>
>>> Dear all,
>>>
>>> After installing R 2.4.0, a definition of "[" for an S4 class has
>>> stopped working as the default for drop in the generic, TRUE, appears to
>>> override the default in the method
>>>
>>> The method is defined for demonstration purposes as
>>>
>>> setMethod("[", signature(x="FLQuant"),
>>> function(x, i="missing", j="missing", k="missing", l="missing",
>>> m="missing", ..., drop=FALSE) {
>>>
>>> print(drop)
>>> }
>>> )
>>>
>>> When called as
>>>
>>> new('FLQuant')[1,]
>>>
>>> drop is TRUE, instead of FALSE. Am I missing something? Has there been a
>>> change in R 2.4.0 of relevance here? I could not find it in the NEWS
>>> file.
>>>
>>> Many thanks,
>>>
>>>
>>> Iago Mosqueira
>>>
>>> __
>>> 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
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operator :: and symbols not in the namespace of a package with a namespace (PR#9279)
On Fri, 6 Oct 2006, Duncan Murdoch wrote:
> On 10/6/2006 9:05 AM, [EMAIL PROTECTED] wrote:
>> Full_Name: Thomas Friedrichsmeier
>> Version: 2.4.0
>> OS: GNU/Linux
>> Submission from: (NULL) (84.61.116.51)
>>
>>
>> Since R 2.4.0, operator "::" also returns objects in the package
>> environment, if
>> the package does not have a namespace. This is a very welcome addition.
>>
>> Additional wish:
>> If a package has a namespace, but does not place all symbols in that
>> namespace,
>> lookup will still fail. For example in package boot (version 1.2-26):
>>
>> library (boot)
>> exists ("motor", envir=as.environment ("package:boot")) # TRUE
>> getAnywhere ("motor") # found in
>> package:boot
>> boot::motor # error not in
>> namespace
>>
>> This is as documented, but I think it would be convenient, if boot::motor
>> would
>> also return the object in this case.
>
> At first I was ready to disagree with you, telling you to use the ":::"
> operator for something that is not exported: but in fact motor is a
> dataset, so it is exported from the package by being loaded into the
> package environment when the package is loaded. I agree that the "::"
> operator should find it.
It might be a good idea to rethink the decision to have data be
handled specially instead of having data sets be treated as ordinary
exported variables. There may be a good reason for doing what we do
now but I don't know what it is. If there really is a good reason to
continue this then maybe we should think about this addition. It
doesn't feel like the right thing to do but may be harmless.
> I think the rule should be: the "::" operator looks at the symbols that
> are publicly available from the package, i.e. boot::motor should
> effectively be an abbreviation for
>
> get("motor", pos="package:boot", inherits=FALSE)
>
> after making sure boot is loaded. I think getExportedValue() is a much
> more rarely needed function, so users should need to use it explicitly.
No. :: exists precisely to allow code to access exported variables
without attaching the namespace. It is the only way I use this feature
and the reason the feature exists.
Best,
luke
>
> Duncan Murdoch
>
>>
>> This might be achieved by adding an additional tryCatch in "::": If the
>> package
>> has a namespace, try getExportedValue (), if that fails, try to get from
>> package
>> environment instead. E.g.:
>>
>> "::" <- function (pkg, name)
>> {
>> pkg <- as.character(substitute(pkg))
>> name <- as.character(substitute(name))
>> ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
>> if (is.null(ns)) {
>> pos <- match(paste("package", pkg, sep = ":"), search(),
>> 0)
>> if (pos == 0)
>> stop(gettextf(paste("package '%s' has no name space and",
>> "is not on the search path"), pkg), domain = NA)
>> get(name, pos = pos, inherits = FALSE)
>> }
>> else tryCatch(getExportedValue(pkg, name), error=function (e) {
>>pos <- match(paste("package", pkg, sep=":"), search(),
>> 0)
>>get(name, pos, inherits=FALSE)
>> })
>> }
>>
>> __
>> 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
>
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: [EMAIL PROTECTED]
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] operator :: and symbols not in the namespace of a package with a namespace (PR#9279)
On 10/6/2006 10:44 AM, Luke Tierney wrote:
> On Fri, 6 Oct 2006, Duncan Murdoch wrote:
>
>> On 10/6/2006 9:05 AM, [EMAIL PROTECTED] wrote:
>>> Full_Name: Thomas Friedrichsmeier
>>> Version: 2.4.0
>>> OS: GNU/Linux
>>> Submission from: (NULL) (84.61.116.51)
>>>
>>>
>>> Since R 2.4.0, operator "::" also returns objects in the package
>>> environment, if
>>> the package does not have a namespace. This is a very welcome addition.
>>>
>>> Additional wish:
>>> If a package has a namespace, but does not place all symbols in that
>>> namespace,
>>> lookup will still fail. For example in package boot (version 1.2-26):
>>>
>>> library (boot)
>>> exists ("motor", envir=as.environment ("package:boot")) # TRUE
>>> getAnywhere ("motor") # found in
>>> package:boot
>>> boot::motor # error not in
>>> namespace
>>>
>>> This is as documented, but I think it would be convenient, if boot::motor
>>> would
>>> also return the object in this case.
>>
>> At first I was ready to disagree with you, telling you to use the ":::"
>> operator for something that is not exported: but in fact motor is a
>> dataset, so it is exported from the package by being loaded into the
>> package environment when the package is loaded. I agree that the "::"
>> operator should find it.
>
> It might be a good idea to rethink the decision to have data be
> handled specially instead of having data sets be treated as ordinary
> exported variables. There may be a good reason for doing what we do
> now but I don't know what it is. If there really is a good reason to
> continue this then maybe we should think about this addition. It
> doesn't feel like the right thing to do but may be harmless.
I think there would be a good reason if it was expensive to load
datasets, but now it's cheap, so I don't think there's a good reason any
more.
>
>> I think the rule should be: the "::" operator looks at the symbols that
>> are publicly available from the package, i.e. boot::motor should
>> effectively be an abbreviation for
>>
>> get("motor", pos="package:boot", inherits=FALSE)
>>
>> after making sure boot is loaded. I think getExportedValue() is a much
>> more rarely needed function, so users should need to use it explicitly.
>
> No. :: exists precisely to allow code to access exported variables
> without attaching the namespace. It is the only way I use this feature
> and the reason the feature exists.
Right, the description I gave above is wrong, but I think the current
behaviour is wrong too. A reasonable alternative use for "::" is to
specify where to go to look for a variable whose name may clash with
another. Avoiding the side effect of changing the search list is a very
nice feature of it.
Is there a simple way to do a load of a package as if it was being
attached, but without putting it into the search list? If so, that's
what I meant above :-), with the search taking place in the public
environment of the package.
Duncan Murdoch
>
> Best,
>
> luke
>
>
>
>>
>> Duncan Murdoch
>>
>>>
>>> This might be achieved by adding an additional tryCatch in "::": If the
>>> package
>>> has a namespace, try getExportedValue (), if that fails, try to get from
>>> package
>>> environment instead. E.g.:
>>>
>>> "::" <- function (pkg, name)
>>> {
>>> pkg <- as.character(substitute(pkg))
>>> name <- as.character(substitute(name))
>>> ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
>>> if (is.null(ns)) {
>>> pos <- match(paste("package", pkg, sep = ":"), search(),
>>> 0)
>>> if (pos == 0)
>>> stop(gettextf(paste("package '%s' has no name space and",
>>> "is not on the search path"), pkg), domain = NA)
>>> get(name, pos = pos, inherits = FALSE)
>>> }
>>> else tryCatch(getExportedValue(pkg, name), error=function (e) {
>>>pos <- match(paste("package", pkg, sep=":"),
>>> search(),
>>> 0)
>>>get(name, pos, inherits=FALSE)
>>> })
>>> }
>>>
>>> __
>>> 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] Bug in 2.4.0 Windows menu setup (PR#9277)
Duncan Murdoch wrote: > On 2006-10-5 8:06, Ei-ji Nakama wrote: >> I do not understand Chinese, but recognize kanji. >> RGui-zh_CN.po is written in utf-8, but charset=CP936 wrote. >> >> perl -p -i -e 's#charset=CP936#charset=utf-8#' RGui-zh_CN.po >> msgfmt -o RGui.mo RGui-zh_CN.po > > Thanks!! That does fix the error, at least on my system. I'll commit > the change to R-devel and R-patched. Hmm, I do understand Chinese, and I can confirm that the content of RGui-zh_CN.po in R 2.4 is in utf-8 rather than CP936. I can also confirm that CP950(big5) for RGui-zh_TW.po is correct, and CP932(shift-JIS) for RGui-ja.po is also correct. (so you'll need to find some korean to verify CP949 for RGui-ko.po). However, the fix is slightly "asymmetric". Out of ru, zh_CN, zh_TW, ja, ko, only ru in R-2.4.0/po/*.po is in localised encoding, (the others 4 in UTF-8), whereas RGui-*.po, after the fix, all are in localised encoding except RGui-zh_CN.po . I would propose correcting the encoding of the *content*, rather than the charset tag, so that Rgui-* all uses localised ones (CP932, CP936, CP949, CP950). That should be better for older windows... Just my two cents/pennies... Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in 2.4.0 Windows menu setup (PR#9277)
On 10/6/2006 1:35 PM, Hin-Tak Leung wrote: > Duncan Murdoch wrote: >> On 2006-10-5 8:06, Ei-ji Nakama wrote: >>> I do not understand Chinese, but recognize kanji. >>> RGui-zh_CN.po is written in utf-8, but charset=CP936 wrote. >>> >>> perl -p -i -e 's#charset=CP936#charset=utf-8#' RGui-zh_CN.po >>> msgfmt -o RGui.mo RGui-zh_CN.po >> >> Thanks!! That does fix the error, at least on my system. I'll commit >> the change to R-devel and R-patched. > > Hmm, I do understand Chinese, and I can confirm that the content > of RGui-zh_CN.po in R 2.4 is in utf-8 rather than CP936. > > I can also confirm that CP950(big5) for RGui-zh_TW.po is correct, and > CP932(shift-JIS) for RGui-ja.po is also correct. (so you'll need to > find some korean to verify CP949 for RGui-ko.po). > > However, the fix is slightly "asymmetric". Out of ru, zh_CN, zh_TW, > ja, ko, only ru in R-2.4.0/po/*.po is in localised encoding, > (the others 4 in UTF-8), whereas RGui-*.po, after the fix, all > are in localised encoding except RGui-zh_CN.po . > > I would propose correcting the encoding of the *content*, rather > than the charset tag, so that Rgui-* all uses localised ones (CP932, > CP936, CP949, CP950). That should be better for older windows... I did try that, but iconv didn't want to convert the file from UTF-8 to CP936. I've no idea why not. In any case, those files only need to be readable by the translation teams, not by end-users, so I don't think the asymmetry matters: if a translator finds it easy to work in UTF-8 that's fine for R, as long as it is correctly recorded. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Extreme slowdown with named vectors. A bug?
Tried the following with R --vanilla on the Rv2.4.0 release (see
details at the end). I think the script and its comments speaks for
itself, but the outcome is certainly not wanted.
for (n in 58950:58970) {
cat("n=", n, "\n", sep="");
# Clean up first
rm(names, x, y); gc();
# Create a named vector of length n
# Try with format "%5d" and it works
names <- sprintf("%05d", 1:n);
x <- seq(along=names);
names(x) <- names;
# Extract the first k elements
k <- 36422;
t0 <- system.time({
y <- x[names[1:k]];
})
str(y);
# But with one more it takes
# for ever when n >= 58960
k <- k + 1;
t1 <- system.time({
y <- x[names[1:k]];
})
# ...then t1/t0 ~= 300-500 and growing!
print(t1/t0);
str(y);
}
The interesting this is that if you replace
y <- x[names[1:k]];
with
idxs <- match(names[1:k], names(x));
y <- x[idxs];
everything is fine.
(For those working with the Affy 100K SNP chips, the freaky thing is
that the problem occurs at n = 58960 which is exactly the number of
SNPs on the Xba array; that's how I found out about the bug/feature it
the first place).
Tried this on two different systems:
> sessionInfo()
R version 2.4.0 (2006-10-03)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
> sessionInfo()
R version 2.4.0 (2006-10-03)
x86_64-unknown-linux-gnu
locale:
C
attached base packages:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
Cheers
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extreme slowdown with named vectors. A bug?
Another example: > avec <- 1:55000 > names(avec) <- as.character(avec) > system.time(avec[names(avec)[1:39045]]) [1] 0.06 0.00 0.07 NA NA > system.time(avec[names(avec)[1:39046]]) [1] 23.89 0.00 23.94NANA > version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor 4.0 year 2006 month 10 day03 svn rev39566 language R version.string R version 2.4.0 (2006-10-03) FWIW, this example shows similar behavior on R-2.2.0 Linux. On Fri, 6 Oct 2006, Henrik Bengtsson wrote: > Tried the following with R --vanilla on the Rv2.4.0 release (see > details at the end). I think the script and its comments speaks for > itself, but the outcome is certainly not wanted. > [snip] Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:[EMAIL PROTECTED] UC San Diego http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extreme slowdown with named vectors. A bug? (PR#9280)
On 10/6/2006 6:20 PM, Henrik Bengtsson wrote:
> Tried the following with R --vanilla on the Rv2.4.0 release (see
> details at the end). I think the script and its comments speaks for
> itself, but the outcome is certainly not wanted.
I see a similar effect to what you're describing. I also see it in
2.3.1, so it's not a new bug.
I tracked it down to an overflow occurring in the stringSubscript
function in src/main/subscript.c: at the beginning there's a test
ns * nx > 1000
When ns and nx are both large, the product overflows and becomes
negative. I'll see if I can fix it.
Duncan Murdoch
>
> for (n in 58950:58970) {
> cat("n=", n, "\n", sep="");
>
> # Clean up first
> rm(names, x, y); gc();
>
> # Create a named vector of length n
> # Try with format "%5d" and it works
> names <- sprintf("%05d", 1:n);
> x <- seq(along=names);
> names(x) <- names;
>
> # Extract the first k elements
> k <- 36422;
> t0 <- system.time({
> y <- x[names[1:k]];
> })
> str(y);
>
> # But with one more it takes
> # for ever when n >= 58960
> k <- k + 1;
> t1 <- system.time({
> y <- x[names[1:k]];
> })
> # ...then t1/t0 ~= 300-500 and growing!
> print(t1/t0);
> str(y);
> }
>
>
> The interesting this is that if you replace
>
> y <- x[names[1:k]];
>
> with
>
> idxs <- match(names[1:k], names(x));
> y <- x[idxs];
>
> everything is fine.
>
> (For those working with the Affy 100K SNP chips, the freaky thing is
> that the problem occurs at n = 58960 which is exactly the number of
> SNPs on the Xba array; that's how I found out about the bug/feature it
> the first place).
>
> Tried this on two different systems:
>
>> sessionInfo()
> R version 2.4.0 (2006-10-03)
> i386-pc-mingw32
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
>> sessionInfo()
> R version 2.4.0 (2006-10-03)
> x86_64-unknown-linux-gnu
> locale:
> C
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> Cheers
>
> /Henrik
>
> __
> 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] Extreme slowdown with named vectors. A bug?
On 10/6/2006 6:20 PM, Henrik Bengtsson wrote:
> Tried the following with R --vanilla on the Rv2.4.0 release (see
> details at the end). I think the script and its comments speaks for
> itself, but the outcome is certainly not wanted.
I think this is fixed now in R-devel and R-patched. Thanks for the
report, and the detailed script to reproduce the bug.
Duncan Murdoch
>
> for (n in 58950:58970) {
> cat("n=", n, "\n", sep="");
>
> # Clean up first
> rm(names, x, y); gc();
>
> # Create a named vector of length n
> # Try with format "%5d" and it works
> names <- sprintf("%05d", 1:n);
> x <- seq(along=names);
> names(x) <- names;
>
> # Extract the first k elements
> k <- 36422;
> t0 <- system.time({
> y <- x[names[1:k]];
> })
> str(y);
>
> # But with one more it takes
> # for ever when n >= 58960
> k <- k + 1;
> t1 <- system.time({
> y <- x[names[1:k]];
> })
> # ...then t1/t0 ~= 300-500 and growing!
> print(t1/t0);
> str(y);
> }
>
>
> The interesting this is that if you replace
>
> y <- x[names[1:k]];
>
> with
>
> idxs <- match(names[1:k], names(x));
> y <- x[idxs];
>
> everything is fine.
>
> (For those working with the Affy 100K SNP chips, the freaky thing is
> that the problem occurs at n = 58960 which is exactly the number of
> SNPs on the Xba array; that's how I found out about the bug/feature it
> the first place).
>
> Tried this on two different systems:
>
>> sessionInfo()
> R version 2.4.0 (2006-10-03)
> i386-pc-mingw32
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
>> sessionInfo()
> R version 2.4.0 (2006-10-03)
> x86_64-unknown-linux-gnu
> locale:
> C
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> Cheers
>
> /Henrik
>
> __
> 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] Bug in 2.4.0 Windows menu setup (PR#9277)
iconv -f utf-8 -t cp936 RGui-zh_CN.po > RGui-zh_CN.po.cp936 iconv: illegal input sequence at position 19303 iconv -c -f utf-8 -t cp936 RGui-zh_CN.po > RGui-zh_CN.po.cp936 ^^ iconv -f cp936 -t utf-8 RGui-zh_CN.po.cp936 > RGui-zh_CN.po.cp936utf8 diff -uN RGui-zh_CN.po RGui-zh_CN.po.cp936utf8 @@ -852,7 +852,7 @@ #: rui.c:1283 rui.c:1404 msgid "menu + item is limited to 1000 bytes" -msgstr "xxx" +msgstr "xxx" grep -C1 "menu + item is limited to 1000 bytes" RGui-zh_CN.po This should ask a translator for text of a part for a difference. BTW, there is not a problem in GB18030. 2006/10/7, Duncan Murdoch <[EMAIL PROTECTED]>: > On 10/6/2006 1:35 PM, Hin-Tak Leung wrote: > > Duncan Murdoch wrote: > >> On 2006-10-5 8:06, Ei-ji Nakama wrote: > >>> I do not understand Chinese, but recognize kanji. > >>> RGui-zh_CN.po is written in utf-8, but charset=CP936 wrote. > >>> > >>> perl -p -i -e 's#charset=CP936#charset=utf-8#' RGui-zh_CN.po > >>> msgfmt -o RGui.mo RGui-zh_CN.po > >> > >> Thanks!! That does fix the error, at least on my system. I'll commit > >> the change to R-devel and R-patched. > > > > Hmm, I do understand Chinese, and I can confirm that the content > > of RGui-zh_CN.po in R 2.4 is in utf-8 rather than CP936. > > > > I can also confirm that CP950(big5) for RGui-zh_TW.po is correct, and > > CP932(shift-JIS) for RGui-ja.po is also correct. (so you'll need to > > find some korean to verify CP949 for RGui-ko.po). > > > > However, the fix is slightly "asymmetric". Out of ru, zh_CN, zh_TW, > > ja, ko, only ru in R-2.4.0/po/*.po is in localised encoding, > > (the others 4 in UTF-8), whereas RGui-*.po, after the fix, all > > are in localised encoding except RGui-zh_CN.po . > > > > I would propose correcting the encoding of the *content*, rather > > than the charset tag, so that Rgui-* all uses localised ones (CP932, > > CP936, CP949, CP950). That should be better for older windows... > > I did try that, but iconv didn't want to convert the file from UTF-8 to > CP936. I've no idea why not. > > In any case, those files only need to be readable by the translation > teams, not by end-users, so I don't think the asymmetry matters: if a > translator finds it easy to work in UTF-8 that's fine for R, as long as > it is correctly recorded. > > Duncan Murdoch > > > -- EI-JI Nakama <[EMAIL PROTECTED]> "\u4e2d\u9593\u6804\u6cbb" <[EMAIL PROTECTED]> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extreme slowdown with named vectors. A bug?
Thank *you* for identifying the source of the problem and fixing. :) /Henrik
On 10/6/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 10/6/2006 6:20 PM, Henrik Bengtsson wrote:
> > Tried the following with R --vanilla on the Rv2.4.0 release (see
> > details at the end). I think the script and its comments speaks for
> > itself, but the outcome is certainly not wanted.
>
> I think this is fixed now in R-devel and R-patched. Thanks for the
> report, and the detailed script to reproduce the bug.
>
> Duncan Murdoch
>
> >
> > for (n in 58950:58970) {
> > cat("n=", n, "\n", sep="");
> >
> > # Clean up first
> > rm(names, x, y); gc();
> >
> > # Create a named vector of length n
> > # Try with format "%5d" and it works
> > names <- sprintf("%05d", 1:n);
> > x <- seq(along=names);
> > names(x) <- names;
> >
> > # Extract the first k elements
> > k <- 36422;
> > t0 <- system.time({
> > y <- x[names[1:k]];
> > })
> > str(y);
> >
> > # But with one more it takes
> > # for ever when n >= 58960
> > k <- k + 1;
> > t1 <- system.time({
> > y <- x[names[1:k]];
> > })
> > # ...then t1/t0 ~= 300-500 and growing!
> > print(t1/t0);
> > str(y);
> > }
> >
> >
> > The interesting this is that if you replace
> >
> > y <- x[names[1:k]];
> >
> > with
> >
> > idxs <- match(names[1:k], names(x));
> > y <- x[idxs];
> >
> > everything is fine.
> >
> > (For those working with the Affy 100K SNP chips, the freaky thing is
> > that the problem occurs at n = 58960 which is exactly the number of
> > SNPs on the Xba array; that's how I found out about the bug/feature it
> > the first place).
> >
> > Tried this on two different systems:
> >
> >> sessionInfo()
> > R version 2.4.0 (2006-10-03)
> > i386-pc-mingw32
> > locale:
> > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> > States.1252;LC_MONETARY=English_United
> > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> > attached base packages:
> > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> > [7] "base"
> >
> >> sessionInfo()
> > R version 2.4.0 (2006-10-03)
> > x86_64-unknown-linux-gnu
> > locale:
> > C
> > attached base packages:
> > [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> > [7] "base"
> >
> > Cheers
> >
> > /Henrik
> >
> > __
> > 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
