[Rd] S4 setClass with prototypes " issues" (PR#8053)
To R-Developers:
I wish to report what I believe are inconsistencies between Green Book
descriptions and R methods behaviors. I **realize** that R does not
guarantee total consistency with the Green Book; therefore I leave it to you
to decide whether any of this is a bug, design choice, or a need for
additional documentation -- or whether I have simply misread or overlooked
existing explanations. If the latter, I apologize for the error, but it was
not for a want of effort.
The issues all revolve around the setClass('xxx',prototype=...) without any
slots construction. All references are to the Green Book. R 2.1.1 (on
Windows)
1. Classes so defined (with protype, no slots) are not instantiated as
described on the bottom of p.289. In particular, the following example from
the book fails:
> setClass('sequence',prototype=numeric(3))
[1] "sequence"
> new('sequence',c(1,51,10))
Error in initialize(value, ...) : cannot use object of class "numeric" in
new(): class "sequence" does not extend that class
2. I have been unable to find any Help documentation about the proper method
to instantiate classes defined by prototypes without slots. Experimentation
showed that only one of the two approaches on the bottom of p.289 worked:
> setClass('foo',prototype=numeric())
[1] "foo"
> z<-new('foo')
## new() works as it should
> z
An object of class "foo"
numeric(0)
## But now try this ...
> z<-1:3
> is(z,'numeric')
[1] TRUE
## Hence, if R followed the book's statement that "For this to work,
'object' must either be suitable as a prototype for 'myClass or belong to a
class that can be coerced to 'myClass.'" (Note, I interpret this to mean
that either of these conditions are sufficient for either of the approaches
shown).
> as(z,'foo')
Error in as(z, "foo") : no method or default for coercing "integer" to "foo"
## But
> class(z)<-'foo'
> z
An object of class "foo"
[1] 1 2 3
I was unable to find documentation for this behavior in R, assuming that
this is not a bug. If it's a bug, it should be fixed, of course; if not, I
think the behavior should be documented, perhaps in setClass.
3. Finally, and most disconcertingly, The Green Book says (p.288):
"... We do NOT want a 'sequence' object to be interpreted as a numeric
vector ... Doing arbitrary arithmetic on the object, for example would be
disastrous...
The use of prototypes without representations allows the class designer to
limit the legal computations on objects made up of numeric data..."
As I read this, this should mean that the following should fail, but it
doesn't (continuing the above example):
> z+1
An object of class "foo"
[1] 2 3 4
Again, if this is not a bug, I think that this lack of adherence to the
Green book should be documented in R. May I say, however, that I wish R had
implemented the book's prescription.
-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA
"The business of the statistician is to catalyze the scientific learning
process." - George E. P. Box
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error in apply help file? (PR#8118)
Gents: (alas, I think no ladies need to be included in the salutation) The apply() Help file says "... If the calls to FUN return vectors of different lengths, apply returns a list of length dim(X)[MARGIN]. " Shouldn't that be: "If the calls to FUN return vectors of different lengths, apply returns a list of length prod(dim(X)[MARGIN]). " Also, might you wish to add: "This list has a dim attribute of MARGIN. That is, if VALUE is the returned list, dim(VALUE) = MARGIN and the values in VALUE can be accessed by the usual array subscripting operations." Further, it might also be useful to add the following to your Examples code: ## Example with different lengths for each call z <- array(1:24,dim=2:4) zseq <- apply(z,1:2,function(x)seq(length=max(x))) zseq ## displayed as a 2 x 3 matrix typeof(zseq) ## list dim(zseq) ## 2 3 zseq[1,] Feel free to ignore these suggestions, of course. Cheers, -- Bert Gunter Genentech Non-Clinical Statistics South San Francisco, CA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in rep.unit method for grid arithmetic ? (PR#14170)
The following code should suffice to document the problem. Things work properly in the following: > x <- unit.c(unit(5,"mm"),unit(3,"npc")) > x [1] 5mm 3npc > rep(x,2) [1] 5mm 3npc 5mm 3npc > rep(x, e=2) [1] 5mm 5npc 3mm 3npc > rep(x,c(2,2)) [1] 5mm 5npc 3mm 3npc However, not so for: > x <- x - unit(1,"mm") > x [1] 5mm-1mm 3npc-1mm > rep(x,2) [1] 5mm-1mm 3npc-1mm 5mm-1mm 3npc-1mm > rep(x, e=2) [1] 5mm-1mm 3npc-1mm ##ERROR > rep(x,c(2,2)) Error in rep(unclass(x), ...) : invalid 'times' argument > sessionInfo() R version 2.10.0 (2009-10-26) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] datasets splines grid tcltk stats graphics grDevices utils methods base other attached packages: [1] TinnR_1.0.3 R2HTML_1.59-1 Hmisc_3.7-0 survival_2.35-7 svSocket_0.9-48 lattice_0.17-26 MASS_7.3-3 loaded via a namespace (and not attached): [1] cluster_1.12.1 svMisc_0.9-56 tools_2.10.0 Best regards and Happy New Year to All, Bert Gunter Genentech Nonclinical Biostatistics __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid unit bug? (PR#14220)
The following seems to me to be at least a perverse trap, if not an =
outright
bug:
> is.numeric(unit(1,"npc"))
[1] TRUE
> is.numeric(1*unit(1,"npc"))
[1] FALSE
> is.numeric(unit(0,"npc") +unit(1,"npc"))
[1] FALSE
...etc.
i.e. is.numeric() appears to be TRUE for class "unit" but false for =
class
("unit.arithmetic" "unit" ). Seems to me it ought to b the same for =
both.
Bert Gunter
Genentech Nonclinical Biostatistics
(FWIW, I think grid graphics is brilliant!)
This was R version 2.11.0dev for Windows btw (not that it makes a
difference):
sessionInfo()
R version 2.11.0 Under development (unstable) (2010-02-15 r51142)=20
i386-pc-mingw32=20
locale:
[1] LC_COLLATE=3DEnglish_United States.1252=20
[2] LC_CTYPE=3DEnglish_United States.1252 =20
[3] LC_MONETARY=3DEnglish_United States.1252
[4] LC_NUMERIC=3DC =20
[5] LC_TIME=3DEnglish_United States.1252 =20
attached base packages:
[1] datasets splines grid tcltk stats graphics =
grDevices
[8] utils methods base=20
other attached packages:
[1] TinnR_1.0.3 R2HTML_1.59-1 Hmisc_3.7-0 survival_2.35-8
[5] svSocket_0.9-48 lattice_0.18-3 MASS_7.3-5=20
loaded via a namespace (and not attached):
[1] cluster_1.12.1 svMisc_0.9-56
=A0
=A0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] grid unit bug? (PR#14220)
Paul:
I figured that would be the problem.
I encountered the issue when I tries to check arguments in a validDetails
method for a grob.
Could one substitute the following function in the grid namespace?
is.numeric <- function(x)if(is.unit(x))TRUE else is.numeric(x)
(or make the first clause FALSE)
Obviously, messing around like this might be dangerous -- or at least would
compromise execution speed.
Cheers,
Bert
Bert Gunter
Genentech Nonclinical Biostatistics
-Original Message-
From: paul murrell [mailto:r-b...@r-project.org]
Sent: Wednesday, February 24, 2010 4:22 PM
To: gunter.ber...@gene.com
Subject: Re: grid unit bug? (PR#14220)
> The following seems to me to be at least a perverse trap, if not an =
> outright
> bug:
>
>> is.numeric(unit(1,"npc"))
> [1] TRUE
>> is.numeric(1*unit(1,"npc"))
> [1] FALSE
>> is.numeric(unit(0,"npc") +unit(1,"npc"))
> [1] FALSE
>
> ...etc.
> i.e. is.numeric() appears to be TRUE for class "unit" but false for =
> class
> ("unit.arithmetic" "unit" ). Seems to me it ought to b the same for =
> both.
These results simply reflect the underlying data structures (simple "unit"s
are
just numeric vectors, but more complex "unit.arithmetic"s are lists). I
don't
see how I can "hide" the numeric-ness of simple units (just like there's no
way
to stop a "ts" object like 'Nile' from satisfying is.numeric()). I could
re-implement simple units as lists, but (apart from the work involved) that
would be (even) less efficient.
1. Is there a situation where this causes a problem?
2. Do you have a possible "fix" in mind?
Paul
>
> Bert Gunter
> Genentech Nonclinical Biostatistics
>
> (FWIW, I think grid graphics is brilliant!)
>
> This was R version 2.11.0dev for Windows btw (not that it makes a
> difference):
>
> sessionInfo()
>
> R version 2.11.0 Under development (unstable) (2010-02-15 r51142)=20
> i386-pc-mingw32=20
>
> locale:
> [1] LC_COLLATE=3DEnglish_United States.1252=20
> [2] LC_CTYPE=3DEnglish_United States.1252 =20
> [3] LC_MONETARY=3DEnglish_United States.1252
> [4] LC_NUMERIC=3DC =20
> [5] LC_TIME=3DEnglish_United States.1252 =20
>
> attached base packages:
> [1] datasets splines grid tcltk stats graphics =
> grDevices
> [8] utils methods base=20
>
> other attached packages:
> [1] TinnR_1.0.3 R2HTML_1.59-1 Hmisc_3.7-0 survival_2.35-8
> [5] svSocket_0.9-48 lattice_0.18-3 MASS_7.3-5=20
>
> loaded via a namespace (and not attached):
> [1] cluster_1.12.1 svMisc_0.9-56
>
>
>
> =A0
> =A0
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] match.arg bug or documentation error (PR#9859)
There is either a bug or undocumented feature (afaics) in match.arg that
requires the length of the arg argument to be no longer than the length of
the choices argument even when several.ok is TRUE. Here is a reproducible
example:
first:
> sessionInfo()
R version 2.5.0 Patched (2007-04-26 r41320)
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] "stats" "graphics" "grid" "grDevices" "tcltk" "utils"
"methods" "base"
## Now the example:
> x<- letters[1:3]
> y <- c('aa','bb')
> match.arg(x,y) ## error because several.ok = FALSE, but note warning
message.
Error in match.arg(x, y) : 'arg' should be one of aa, bb
In addition: Warning message:
longer object length
is not a multiple of shorter object length in: arg == choices
## So set several.ok=TRUE ... but there is still an error
> match.arg(x,y, several.ok = TRUE)
Error in match.arg(x, y, several.ok = TRUE) :
'arg' should be one of aa, bb
## However, if x is of length 2, all is OK.
> x <- letters[1:2]
> match.arg(x,y, several.ok = TRUE)
[1] "aa" "bb"
Bert Gunter
Genentech Nonclinical Statistics
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Losing attributes in data.frame() (PR#10873)
Folks: Problem: [<-.data,frame() is losing attributes under certain curcumstances shown below. I think this is a bug, at least in documentation, as I was unable to find explicit documentation of the behavior. Indeed, the only documentation I found told me attributes are preserved. Here is a detailed description: > df <- data.frame(a=1:3, b=letters[1:3]) > attr(df,"foo") <- 10 > df a b 1 1 a 2 2 b 3 3 c > attributes(df) $names [1] "a" "b" $row.names [1] 1 2 3 $class [1] "data.frame" $foo [1] 10 ## But now we add a new column using matrix-type indexing > df[,"c"] <- 10:12 > df a b c 1 1 a 10 2 2 b 11 3 3 c 12 > attributes(df) $names [1] "a" "b" "c" $row.names [1] 1 2 3 $class [1] "data.frame" > ## Note that "foo" attribute is lost; however... > df <- data.frame(a=1:3, b=letters[1:3]) > attr(df,"foo") <- 10 > df[["c"]] <- 10:12 > attributes(df) $names [1] "a" "b" "c" $row.names [1] 1 2 3 $foo [1] 10 $class [1] "data.frame" ## The foo attribute has been kept this time. ## Details: > sessionInfo() R version 2.6.2 (2008-02-08) 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] graphics grDevices datasets grid tcltk stats utils methods base other attached packages: [1] svSocket_0.9-5svIO_0.9-5svIDE_0.9-5 R2HTML_1.58 svMisc_0.9-5 lme4_0.99875-9 [7] Matrix_0.999375-4 lattice_0.17-6 > Cheers, Bert Gunter Genentech Nonclinical Statistics __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
