[R] The end of Matlab
Duncan Murdoch
murdoch at stats.uwo.ca
Fri Dec 12 19:36:19 CET 2008
On 12/12/2008 1:06 PM, hadley wickham wrote:
>>> Oh yes, that's a good point. But wouldn't the following do the job?
>>>
>>> "&.selector" <- function(a, b) {
>>> function(n) a(n) & b(n)
>>> }
>>>
>>> or
>>>
>>> "&.selector" <- function(a, b) {
>>> function(n) intersect(a(n), b(n))
>>> }
>>>
>>> depending on whether selectors return logical or numeric vectors.
>>> Writing functions for | and ! would be similarly easy. Or am I
>>> missing something?
>>
>> No, I think those definitions would be fine, but I'd be concerned about
>> speed issues if we start messing with primitives.
>
> Speed or expressiveness: pick one? ;) People could always use the
> regular subsetting mechanisms if they want the best speed - any
> changes to support selectors wouldn't affect the speed of the other
> methods of subsetting, would they?
>
>> While we're at it, we might as well do the same sort of thing for :, and
>> define a selector named end, and then 3:end would give a selector from 3 to
>> the end, which brings us back to the original question. So it's not nearly
>> as intrusive as I thought it would be.
>
> 3:end() do you mean? Or do you mean extending seq so that it uses
> unevaluted input?
My end would be the output of your end(). If there are no args and no
local context, I don't see the need for it to be a function call. It
would just be defined as something like
end <- structure( function(n) c(rep(FALSE, n-1), TRUE), class="selector")
I'm not sure what the definition of : should be if one of the args is a
selector.
Duncan
More information about the R-help
mailing list