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() 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel