[Rd] grid unit bug? (PR#14220)

[Bert Gunter]

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:ripley at stats.ox.ac.uk] 
Sent: Wednesday, February 24, 2010 11:13 PM
To: gunter.berton at gene.com; paul at stat.auckland.ac.nz
Cc: r-devel at stat.math.ethz.ch; R-bugs at 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.berton at 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-bugs at r-project.org]
> Sent: Wednesday, February 24, 2010 4:22 PM
> To: gunter.berton at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,                  ripley at 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