[Rd] Re: tail(<matrix>) column numbers

[Patrick Burns]

I give it my vote as well.

Pat


Warnes, Gregory R wrote:

>I also vote for the 'helpful' addition on row numbers based on the original
>matrix when no row names are present, with an optional argument to prevent
>this behaviour.
>
>-G
>
>  
>
>>-----Original Message-----
>>From: Duncan Murdoch [mailto:dmurdoch at pair.com]
>>Sent: Monday, July 12, 2004 8:06 AM
>>To: Patrick Burns
>>Cc: Martin Maechler; Warnes, Gregory R; Prof Brian Ripley; 
>>Kevin Wright;
>>r-devel at stat.math.ethz.ch; Peter Dalgaard
>>Subject: Re: tail(<matrix>) column numbers
>>
>>
>>On Sun, 11 Jul 2004 12:06:44 +0100, Patrick Burns
>><pburns at pburns.seanet.com> wrote :
>>
>>    
>>
>>>I disagree with Martin's assertion that "tail" is not useful
>>>for programming.  It has a few features relative to the
>>>do-it-yourself approach:
>>>      
>>>
>>Me too actually.  I think tail() has two uses, interactive and
>>programmatic.  I think it would be better for interactive use if 
>>the row names were added, and only slightly worse for programmatic use
>>if an option were given to turn them off.
>>
>>In interactive use, I find it unhelpful to be told that something is
>>in row 3 when it's really in row 47.
>>
>>Duncan Murdoch
>>
>>    
>>
>>>*)  It compactly makes the intention clear.
>>>*)  It automatically handles cases where there may be
>>>either a vector or a matrix.
>>>*)  It handles cases where there is less data than is being
>>>sought (which may or may not be a good thing).
>>>
>>>"tail" of functions is what is definitely intended for interactive
>>>use.
>>>
>>>Pat
>>>
>>>Martin Maechler wrote:
>>>
>>>      
>>>
>>>>>>>>>"PatBurns" == Patrick Burns <pburns at pburns.seanet.com>
>>>>>>>>>   on Tue, 27 Jan 2004 14:20:30 +0000 writes:
>>>>>>>>>           
>>>>>>>>>
>>>>>>>>>                  
>>>>>>>>>
>>>>[more than half a year ago]
>>>>
>>>>   PatBurns> Duncan Murdoch wrote:
>>>>
>>>>  .............
>>>>
>>>>   DM> One other one I'll look at:
>>>>   DM> 
>>>>   DM> If a matrix doesn't have row names, I might add names
>>>>   DM> like '[nn,]' to it, so I get results like
>>>>
>>>>     R> x <- matrix(1:100,ncol=2)
>>>>     R> tail(x)
>>>>  Rout>       [,1] [,2]
>>>>  Rout> [45,]   45   95
>>>>  Rout> [46,]   46   96
>>>>  Rout> [47,]   47   97
>>>>  Rout> [48,]   48   98
>>>>  Rout> [49,]   49   99
>>>>  Rout> [50,]   50  100
>>>>  Rout> 
>>>>   DM> instead of the current
>>>>
>>>>     R> tail(x)
>>>>  Rout>      [,1] [,2]
>>>>  Rout> [1,]   45   95
>>>>  Rout> [2,]   46   96
>>>>  Rout> [3,]   47   97
>>>>  Rout> [4,]   48   98
>>>>  Rout> [5,]   49   99
>>>>  Rout> [6,]   50  100
>>>>
>>>>   DM> I just want to be careful that this doesn't mess up
>>>>   DM> something else.
>>>>   DM> 
>>>>   DM> Duncan Murdoch
>>>>
>>>>
>>>>   PatBurns> I think this could be being too "helpful".  Using
>>>>   PatBurns> tail on a matrix may often be done in a program so
>>>>   PatBurns> I think leaving things as they come is the best
>>>>   PatBurns> policy.
>>>>
>>>>I tend to disagree, and would like to have us think about it
>>>>again:
>>>>
>>>>1)  Duncan's proposal was to only add row names *when* 
>>>>        
>>>>
>>there are none.
>>    
>>
>>>>2)  Pat is write that tail() for matrices maybe used not 
>>>>        
>>>>
>>only interactively
>>    
>>
>>>>   and help(tail)'s "Value:" section encourages this to 
>>>>        
>>>>
>>some extent.
>>    
>>
>>>>   However, how can adding column names to such a 
>>>>        
>>>>
>>matrix-tail be harmful?
>>    
>>
>>>>   Well, only in the case where the tail is quite large, the
>>>>   added dimnames add unneeded memory and other overhead when
>>>>   dealing with that matrix.
>>>>
>>>>But I think, programmers/users caring about efficient code
>>>>wouldn't use tail(<matrix>) in their function code, would they?
>>>>
>>>>In conclusion, I'd still argue for following Duncan's proposal,
>>>>maybe adding a \note{.} to head.Rd stating that these functions
>>>>were meant for interactive use, and for "programming", we'd
>>>>rather recommend the direct  (n-k+1):n indexing.
>>>>
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>    
>>
>
>
>LEGAL NOTICE
>Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
>
>
>  
>