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

From: Martin Maechler <maechler_at_stat.math.ethz.ch>
Date: Mon 12 Jul 2004 - 23:39:39 EST

>>>>> "Duncan" == Duncan Murdoch <dmurdoch@pair.com> >>>>> on Mon, 12 Jul 2004 08:05:58 -0400 writes:

    Duncan> On Sun, 11 Jul 2004 12:06:44 +0100, Patrick Burns     Duncan> <pburns@pburns.seanet.com> wrote :

>> I disagree with Martin's assertion that "tail" is not
>> useful for programming.

I really didn't assert that.... to the contrary I said you were *right* (where I used 'write' -- probably my worst typing lapsus ever) but never mind

>> useful for programming. It has a few features relative
>> to the do-it-yourself approach:

    Duncan> Me too actually.  I think tail() has two uses,
    Duncan> interactive and programmatic.  I think it would be
    Duncan> better for interactive use if the row names were
    Duncan> added, and only slightly worse for programmatic use
    Duncan> if an option were given to turn them off.

yes, so a programmer would use

       tail(obj, barebones=TRUE)
or     tail(obj, addnames=FALSE)

or such an option -- where we'd want the interactive use not to have to specify the option.

Note that this would still be a non-backward compatibaly behavior -- which I think however is acceptable in this special case.

    Duncan> In interactive use, I find it unhelpful to be told
    Duncan> that something is in row 3 when it's really in row
    Duncan> 47.

indeed.

    Duncan> 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@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) tail(x)
    Rout> [,1] [,2] [45,] 45 95 [46,] 46 96 [47,] 47 97 [48,] 48
    Rout> 98 [49,] 49 99 [50,] 50 100
    Rout> 

    DM> instead of the current
    >>>
    R> tail(x)
    Rout> [,1] [,2] [1,] 45 95 [2,] 46 96 [3,] 47 97 [4,] 48 98     Rout> [5,] 49 99 [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.
    >>> 
    >>> 
    >>> 
    >>> 
    >>

    Duncan> ______________________________________________
    Duncan> R-devel@stat.math.ethz.ch mailing list     Duncan> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

R-devel@stat.math.ethz.ch mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel Received on Mon Jul 12 23:44:44 2004

This archive was generated by hypermail 2.1.8 : Wed 03 Nov 2004 - 22:45:02 EST