[R] The end of Matlab

[Duncan Murdoch]

On 12/12/2008 3:41 AM, Wacek Kusnierczyk wrote:
> Duncan Murdoch wrote:
>> On 11/12/2008 9:45 PM, Mike Rowe wrote:
>>> Greetings!
>>>
>>> I come to R by way of Matlab.  One feature in Matlab I miss is its
>>> "end" keyword.  When you put "end" inside an indexing expression, it
>>> is interpreted as the length of the variable along the dimension being
>>> indexed.  For example, if the same feature were implemented in R:
>>>
>>> my.vector[5:end]
>>>
>>> would be equivalent to:
>>>
>>> my.vector[5:length(my.vector)]
>> And if my.vector is of length less than 5?
>>> or:
>>>
>>> this.matrix[3:end,end]
>>>
>>> would be equivalent to:
>>>
>>> this.matrix[3:nrow(this.matrix),ncol(this.matrix)]   # or
>>> this.matrix[3:dim(this.matrix)[1],dim(this.matrix)[2]]
>>>
>>> As you can see, the R version requires more typing, and I am a lousy
>>> typist.
>> It doesn't save typing, but a more readable version would be
>>
>> rows <- nrow(this.matrix)
>> cols <- ncol(this.matrix)
>> this.matrix[3:rows, cols]
>>
> 
> and if nrow(this.matrix) is less than 3?
> 
> 
>>> With this in mind, I wanted to try to implement something like this in
>>> R.  It seems like that in order to be able to do this, I would have to
>>> be able to access the parse tree of the expression currently being
>>> evaluated by the interpreter from within my End function-- is this
>>> possible?  Since the "[" and "[[" operators are primitive I can't see
>>> their arguments via the call stack functions...
>>>
>>> Anyone got a workaround?  Would anybody else like to see this feature
>>> added to R?
>> I like the general rule that subexpressions have values that can be
>> evaluated independent of context, so I don't think this is a good idea.
> 
> 
> but this 'general rule' is not really adhered to in r!  one example
> already discussed here at length is subset:
> 
> subset(data.frame(...), select=a)
> 
> what will be selected?  column named "a", or columns named by the
> components of the vector a?  this is an example of how you can't say
> what an expression means in a context-independent manner.  

 From which you might conclude that I don't like the design of subset, 
and you'd be right.  However, I don't think this is a counterexample to 
my general rule.  In the subset function, the select argument is treated 
as an unevaluated expression, and then there are rules about what to do 
with it.  (I.e. try to look up name `a` in the data frame, if that 
fails, ...)

For the requested behaviour to similarly fall within the general rule, 
we'd have to treat all indices to all kinds of things (vectors, 
matrices, dataframes, etc.) as unevaluated expressions, with special 
handling for the particular symbol `end`.  But Mike wanted an End 
function, so presumably he wanted the old behaviour of indexing, but to 
have a function whose value depended on where it was called from.  We do 
have those (e.g. the functions for examining the stack that Mike wanted 
to make use of), and they're needed for debugging and a few special 
cases, but as a general rule they should be avoided.

 > and this is
> an ubiquitous problem in r.

I don't think so.

Duncan Murdoch