[Rd] sapply improvements
Martin Maechler
maechler at stat.math.ethz.ch
Thu Nov 5 10:05:16 CET 2009
>>>>> "PD" == Peter Dalgaard <p.dalgaard at biostat.ku.dk>
>>>>> on Thu, 05 Nov 2009 00:28:51 +0100 writes:
PD> William Dunlap wrote: ...
>>>
>>> if (x <= 0) NA else log(x)
>>>
>>> variety otherwise.
>>
>> Would you only want it to coerce upwards to FUN.VALUES's
>> type? E.g., allow sapply(z, length,
>> FUN.VALUE=numeric(1)) to return a numeric vector but die
>> on sapply(z, function(zi)as.complex(zi[1]),
>> FUN.VALUE=numeric(1)) If the latter doesn't die should it
>> return a complex or a numeric vector? (I'd say it needs
>> to be numeric, but I'd prefer that it died.)
PD> I'd say that it should probably die on downwards
PD> coercion. Getting a double when an integer is expected,
PD> or complex instead of double as you indicate, is a
PD> likely user error. If not, then the user can always
PD> coerce explicitly inside FUN.
I agree with Peter: Do allow coercion downwards
PD> Another issue is whether one would want to go beyond the
PD> base classes of S (logical, integer, double, complex,
PD> character). For other classes, there may be no notion of
PD> "up" and "down" in coercion. Then again, sapply was
PD> always limited to what unlist() will handle, so e.g.
>> sapply(1:10,FUN=function(i)Sys.Date())
PD> [1] 14553 14553 14553 14553 14553 14553 14553 14553
PD> 14553 14553
PD> as opposed to
>> structure(rep(14553,10), class="Date")
PD> [1] "2009-11-05" "2009-11-05" "2009-11-05"
PD> "2009-11-05" "2009-11-05" [6] "2009-11-05" "2009-11-05"
PD> "2009-11-05" "2009-11-05" "2009-11-05"
Well, using
as(<prelim_result>, class(<prototype>) )
would be really nice here....
but alas, we are still not allowed to use as(.,.) in base
code which I'd tend to call a "design bug" nowadays..
Martin
More information about the R-devel
mailing list