Thank you Brian: Maybe I should follow my own advice! I DID check methods(is.numeric) to see if that were the case, but concluded it was not as that yielded an error. But all I needed to do was read the docs! Registering the method indeed seems the right way to do it.
Best regards, Bert Gunter Genentech Nonclinical Biostatistics -----Original Message----- From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] Sent: Wednesday, February 24, 2010 11:13 PM To: gunter.ber...@gene.com; p...@stat.auckland.ac.nz Cc: r-de...@stat.math.ethz.ch; r-b...@r-project.org Subject: Re: [Rd] grid unit bug? (PR#14220) is.numeric() is generic. So grid could include is.numeric.unit <- function(x) FALSE and register it in its namespace. Or Bert could define it in his application. On Thu, 25 Feb 2010, gunter.ber...@gene.com wrote: > 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 > -- Brian D. Ripley, rip...@stats.ox.ac.uk 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, UK Fax: +44 1865 272595 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
