>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>>>> on Mon, 12 Jul 2004 08:05:58 -0400 writes:
Duncan> On Sun, 11 Jul 2004 12:06:44 +0100, Patrick Burns
Duncan> <[EMAIL PROTECTED]> 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
>>>>>>>> <[EMAIL PROTECTED]> 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> [EMAIL PROTECTED] mailing list
Duncan> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
