[Rd] (PR#8192) [ subscripting sometimes loses names

[Peter Dalgaard]

Duncan Murdoch wrote:
> On 31/01/2009 7:31 AM, Andrew Piskorski wrote:
>> This (tangential) discussion really should be a separate thread so I
>> changed the subject line above.
>>
>> On Fri, Jan 30, 2009 at 11:51:00AM -0500, Simon Urbanek wrote:
>>> Subject: Re: [Rd] (PR#13487) Segfault when mistakenly calling 
>>> [.data.frame
>>
>>>> My boss was debugging an issue in our R code.  We have our own "[...."
>>>> functions, because stock R drops names when subscripting.
>>> ... if you tell it to do so, yes. If you tell it to not do that, it  
>>> won't ... ever tried drop=FALSE ?
>>
>> Simon, no, the drop=FALSE argument has nothing to do with what
>> Christian was talking about.  The kind of thing he meant is PR# 8192,
>> "Subject: [ subscripting sometimes loses names":
>>
>>   http://bugs.r-project.org/cgi-bin/R/wishlist?id=8192
> 
> In that bug report you were asked to provide simple examples, and you 
> didn't.  I imagine that's why there was no action on it.  It is not that 
> easy for someone else to actually find the simple example that led you 
> to print
> 
>      $vec.1
> BAD  $vec.1[[1]]           $vec.1[[2]]
>         a    c <NA>         a  c no
>         1    3   NA         1  3 NA
> 
> I just tracked this one down, and can put together this simple example:
> 
>  > (1:3)["no"]
> [1] NA
> 
> where I think you would want the name "no" attached to the output.  (Or 
> maybe your more complicated example is wanted?  You don't explain.)  But 
> that looks like documented behaviour to me:  according to my reading of 
> "Indexing by vectors" in the R Language Definition manual, it should 
> give the same answer as (1:3)[4], and it does.  So it's not a bug, but a 
> wishlist item.
> 
> And the other two cases where you list "BAD" behaviour?  I didn't track 
> them down.

I did, and they boil down to variations of

 > data.frame(val=1:3,row.names=letters[1:3])[,1]
[1] 1 2 3

but it's not obvious that the result should be named using the row.names 
and (in particular) whether or why it should differ from .....[[1]] and 
....$val. Given that for most purposes, extracting the relevant names 
would just be unnecessary red tape, I'd say that we can do without it.



-- 
    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
  (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)              FAX: (+45) 35327907