On 06/07/2010 10:53, Martin Maechler wrote:
[ ... ]
Wouldn't it make more sense to call
arrayInd(which.min(mat), dim(mat))
instead of
which.min(mat, arr.ind = TRUE)
in the spirit of modularity, maintainability, ... ?
Honestly, in my first reply I had forgotten about my own
arrayInd() modularization....
Yes. Then I guess the suggested change is to
put 'arrayInd' in the See Also and Examples for
'which.min' for dunderheads like me that don't
think of it themselves.
>>> If the order of the if condition were reversed, then
>>> possibly the slight reduction in speed of 'which.min'
>>> and 'which.max' would be more than made up for in the
>>> slight increase in speed of 'which'.
thanks for the hint, but
"increase in speed of 'which'" -- really, can you measure that?
I doubt it.
(I'll reverse the order anyway)
If we are interested in speed increase, we should add an option
to *not* work with dimnames at all (*) and if we have programmer
time left, we could take it .Internal() and get a real
boost... not now though.
(*) I'm doing that for now, *and* I would like to change the
default behavior or arrayInd(), but of course *not* the
default behavior of which(),
to *not* attach dimnames to the result, by default.
I.e., I'm proposing to add 'useNames = FALSE' as argument to
arrayInd() but have which() call arrayInd(..., useNames=TRUE).
This is a back-compatibility change in arrayInd() -- which has
existed only since 2.11.0 anyway, so would seem ok, to me.
Opinions ?
I find it hard to believe that would cause
too much trauma.
Pat
--
Martin
--
Patrick Burns
pbu...@pburns.seanet.com
http://www.burns-stat.com
(home of 'Some hints for the R beginner'
and 'The R Inferno')
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
