# Re: [Rd] sapply improvements

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: Thu, 05 Nov 2009 06:24:24 -0500

On 05/11/2009 4:05 AM, Martin Maechler wrote:

```>>>>>> "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

You missed "not", right? I.e. we would never coerce a double down to an integer or logical, but coercion in the other direction would be fine?

Duncan Murdoch

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

R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu 05 Nov 2009 - 11:28:19 GMT

This archive was generated by hypermail 2.2.0 : Thu 05 Nov 2009 - 16:50:31 GMT