[Rd] slots of type "double"

[Martin Maechler]

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

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.

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;
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).

Of course I may have overlooked other reasonings;
as mentioned, I'm quite a bit time limited at the moment.
Martin

  [....]

    >> I'd like to give the Matrix authors a chance to look into
    >> this before making the change.  

Thanks, indeed!

    >> Loking at the packages has reinforced my impression that
    >> having "double" as an S4 class is only adding confusion,
    >> so the change is desirable.

well or maybe it's just the lack of comprehensive documentation
of S4 classes as in 'methods' in R -- where I think JMC did want
to do a few things slightly differently than they are in S-PLUS..


    MM> I think (without having had time to check all
    MM> implications) that I agree quite a bit.  I don't think
    MM> that I was not partly confused about things, either as
    MM> they were in Matrix when I "entered the project" or as
    MM> they turned out to work or fail, when we started to use
    MM> those class definitions quite a few R versions back,
    MM> when also "methods" / "base" may have behaved a bit
    MM> differently than now.  I must admit that I did not
    MM> program according to documented behavior, but rather to
    MM> work behavior :-) ;-)

    MM> I'm very busy the rest of this week, in out'of'town
    MM> meetings, so won't be able to comment much more.  Martin