[Rd] slots of type "double"

[Prof Brian Ripley]

In-line omments near the end:

On Wed, 14 Nov 2007, Martin Maechler wrote:

> still found a bit time for more remarks.
>
>>>>>> "MM" == Martin Mächler <maechler at stat.math.ethz.ch>
>>>>>>     on Wed, 14 Nov 2007 14:23:12 +0100 (CET) writes:
>
>    MM> On Wed, November 14, 2007 09:09, Prof Brian Ripley
>    MM> wrote:
>    >> On Tue, 13 Nov 2007, Prof Brian Ripley wrote:
>    >>
>    >>> On Tue, 13 Nov 2007, John Chambers wrote:
>    >>>
>    >>>> What's the proposal here?  To eliminate "double" as a
>    >>>> class?  No objection
>    >>>
>    >>> Eliminate "double" and "single".
>    >>>
>    >>>> from this corner.  As I remember, it was put in early
>    >>>> in the implementation of methods, when I was confused
>    >>>> about what R intended in this area (well, I'm not
>    >>>> totally unconfused even now).
>    >>>>
>    >>>> If this is the proposal, we could implement it in
>    >>>> r-devel and see if there are complaints.
>    >>>
>    >>> I was going to propose so after running some tests over
>    >>> CRAN/BioC (which will take a few hours).
>    >>
>    >> Which showed up problems in packages Matrix and matlab.
>
>
>    >> Matrix clearly has a different view of these classes:
>    >>
>    >> ## "atomic vectors" (-> ?is.atomic ) -- ##
>    >> --------------- those that we want to convert from
>    >> old-style "matrix" setClassUnion("atomicVector", ##
>    >> numeric = {integer, double} but all 3 should *directly*
>    >> be atomic members = c("logical", "integer", "double",
>    >> "numeric", "complex", "raw", "character"))
>    >>
>    >> If I remove "double" there, I get an error in an example:
>    >>
>    >>> stopifnot(is(scm, "sparseVector"),
>    >> + identical(cm, as.numeric(scm))) Error in as(x at x, mode)
>    >> : no method or default for coercing "numeric" to "double"
>    >>
>    >> and looking at the code suggests that "double" is used as
>    >> the class name in several places.
>
> yes.
> As you mention and I had in the comment above,
> I've worked from the premise of something like a class union of
>
> numeric = {integer, double}
>
> -- which corresponds to S3's    is.numeric()  which we all know
>   differs from the semantic of as.numeric()

(It predates S3 classes, being in the Blue Book.  And what as.numeric does 
in R differs from the Blue Book description, although for a long time the 
R help gave the BB version.  But S also differs, at least in recent 
years.)

> and now know why I had done so {empty lines deleted}:
>
>  > showClass("numeric")
>  No Slots, prototype of class "numeric"
>  Extends: "vector"
>  Known Subclasses: "double", "integer"
>
>  > showClass("double")
>  No Slots, prototype of class "numeric"
>  Extends: "vector", "numeric"
>
>  > showClass("integer")
>  No Slots, prototype of class "integer"
>  Extends: "vector", "numeric"
>
> which you partially also mentioned in your initial posting.

(I posted output from getClass, as showClass is not in the Green Book, 
although I actually used showClass first.)

> As a 2nd thought I wonder if we should not keep this current
> scheme and fix its behavior where needed (the problem the OP had):
> The notion of   numeric := union(double, integer)
> does now appeal to me again;

I don't believe we can get from here to there without massive upheaval. 
"numeric" is not a virtual class, and making "double" the basic class and 
"numeric" a virtual one would break tons of code (and writeups).

> in particular since eliminating "double"  in the S4 world  will
> not eliminate it from other places, and the basic problem of
> is.numeric / as.numeric  inconsistency is - I think - not
> something we'd want to eliminate, just because it would break too
> much existing code (and books on S and R).

(I do wonder if any of those books do get to that level of detail, and if 
they do what system they describe, given the divergence from the Blue 
Book.  I checked that the VR ones do not. I tend to agree with the BB 
comment that the storage type only matters in external interfaces, 
although that perhaps undervalues +/-Inf which may not have been 
available back then.)

I may be wrong, but I believe class "double" does not exist in the (strict 
sense) S4 world: it was certainly not in S-PLUS 6.2.

With a clean-sheet design we might well do things differently, and I think 
it would be possible for Matrix to make use of a class union of "numeric" 
and "integer".  But the name "numeric" is already taken and we are going 
to have to live with three names [*] for the same concept, and setting S3 
methods on as.double and S4 ones on as.numeric (because it would be too 
painful to change either).

Brian

[*] numeric, double, real.  My proposal to remove 'real' met with 
objections.

-- 
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