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

Warnes, Gregory R gregory_r_warnes at groton.pfizer.com
Mon Jul 12 17:28:29 CEST 2004


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 messag...{{dropped}}



More information about the R-devel mailing list