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

[Martin Maechler]

>>>>> "Duncan" == Duncan Murdoch <dmurdoch at 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 at 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 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) 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 at stat.math.ethz.ch mailing list
    Duncan> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel