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 <[EMAIL PROTECTED]>
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([EMAIL PROTECTED], 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, [EMAIL PROTECTED]
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
