Re: [Rd] slots of type "double"

From: Martin Mächler <>
Date: Wed, 14 Nov 2007 14:23:12 +0100 (CET)

On Wed, November 14, 2007 09:09, Prof Brian Ripley 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.
> 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.

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

I'm very busy the rest of this week, in out'of'town meetings, so won't be able to comment much more.
Martin mailing list Received on Wed 14 Nov 2007 - 13:27:40 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 Wed 14 Nov 2007 - 22:30:18 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.