Re: [Rd] slots of type "double"

From: Prof Brian Ripley <ripley_at_stats.ox.ac.uk>
Date: Thu, 15 Nov 2007 13:27:03 +0000 (GMT)

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

______________________________________________ R-devel_at_r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Received on Thu 15 Nov 2007 - 13:30:29 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 15 Nov 2007 - 16:30:18 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.