slots of type "double"

Any idea why S4 doesn't allow slots of type "double"?

setClass("A", representation(a="double"))

 Error in makePrototypeFromClassDef(properties, ClassDef, immediate,  
where) :
   in making the prototype for class "A" elements of the prototype  
failed to
match the corresponding slot class: a (class ?double? )

"numeric", "integer", "character", "complex", "raw", etc... they all  
work but "double" doesn't. Any reason for this strange exception?

On Nov 13, 2007, at 3:36 AM, hpages at fhcrc.org wrote:

Any idea why S4 doesn't allow slots of type "double"?

Type (as in storage type and "double" is a storage type) has nothing
to do with classes. You cannot create slots for types, only for classes.

getClass("double")

getClass("numeric")

a <- new("numeric", pi)
a

class(a)

x <- 1:3
is.numeric(x)

identical(x, as.numeric(x))

x <- pi
is.numeric(x)

identical(x, as.numeric(x))

setClass("A", representation(a="double"))

 Error in makePrototypeFromClassDef(properties, ClassDef, immediate,
where) :
   in making the prototype for class "A" elements of the prototype
failed to
match the corresponding slot class: a (class ?double? )

"numeric", "integer", "character", "complex", "raw", etc... they all
work but "double" doesn't. Any reason for this strange exception?

AFAICS there is no way to create an object of the class "double" (save
for 'faking' it by creating an informal S3 object), so such definition
is useless. And given this fact, even the internal code is unable to
create it, so it doesn't match the signature. Note:

a=new("double")
class(a)

[1] "numeric"

is(a,"double")

[1] FALSE

I think it comes from the fact that there is an S4 definition for the
class "double" which is not valid. That is probably a bug and the
class definition should be removed.

Cheers,
Simon

What's the proposal here?  To eliminate "double" as a class?  No objection

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.

Prof Brian Ripley wrote:

On Tue, 13 Nov 2007, Simon Urbanek wrote:

On Nov 13, 2007, at 3:36 AM, hpages at fhcrc.org wrote:

Any idea why S4 doesn't allow slots of type "double"?

Type (as in storage type and "double" is a storage type) has nothing
to do with classes. You cannot create slots for types, only for classes.

Unfortunately not in the world of the 'methods' package (which seems to 
differ here from the Green Book and S-PLUS).  There's a basic class 
"double" (and also "single") defined in BasicClasses.R.  It say:

getClass("double")

No Slots, prototype of class "numeric"

Extends: "vector", "numeric"

getClass("numeric")

No Slots, prototype of class "numeric"

Extends: "vector"

Known Subclasses: "double", "integer"

So it is an otherwise unspecified subclass of "numeric".

Now when you do

a <- new("numeric", pi)
a

[1] 3.141593

class(a)

[1] "numeric"

you are in fact calling class() on a REALSXP, and that is set up to report 
"numeric" (the implicit class comes from mode not type, except for 
"integer").

Anther area of confusion is that as.numeric, as.double and as.real are 
three names for the same thing, but is.numeric and is.double are not the 
same.  So we end up with

x <- 1:3
is.numeric(x)

[1] TRUE

identical(x, as.numeric(x))

[1] FALSE

x <- pi
is.numeric(x)

[1] TRUE

identical(x, as.numeric(x))

[1] TRUE

Basically I think class() is wrong (it should use "double"), but it was not 
my choice and it was presumably done to agree with the Green Book.

I agree that it would be best to remove the "double" and "single" S4 
classes.  At least in the version of S-PLUS I have left, "double" does not 
exist -- "single" does but is a distinct storage type.

setClass("A", representation(a="double"))

 Error in makePrototypeFromClassDef(properties, ClassDef, immediate,
where) :
   in making the prototype for class "A" elements of the prototype
failed to
match the corresponding slot class: a (class ?double? )

"numeric", "integer", "character", "complex", "raw", etc... they all
work but "double" doesn't. Any reason for this strange exception?

AFAICS there is no way to create an object of the class "double" (save
for 'faking' it by creating an informal S3 object), so such definition
is useless. And given this fact, even the internal code is unable to
create it, so it doesn't match the signature. Note:

a=new("double")
class(a)

[1] "numeric"

is(a,"double")

[1] FALSE

I think it comes from the fact that there is an S4 definition for the
class "double" which is not valid. That is probably a bug and the
class definition should be removed.

Cheers,
Simon

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

stopifnot(is(scm, "sparseVector"),

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.


Package matlab is simpler: test mkconstarray.R fails at

   > test.mkconstarray(list(class.type = "double", value = pi, size = 4),

rep(pi, 4))
   Error in as(value, match.arg(class.type)) :
     no method or default for coercing "numeric" to "double"

and needs the author to rectify his confusion between "class" and "type".

I'd like to give the Matrix authors a chance to look into this before
making the change.  Loking at the packages has reinforced my impression
that having "double" as an S4 class is only adding confusion, so the
change is desirable.

"MM" == Martin M?chler <maechler at stat.math.ethz.ch>
    on Wed, 14 Nov 2007 14:23:12 +0100 (CET) writes:

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