[Rd] slots of type "double"

[Martin Mächler]

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