On Wed, Nov 07, 2007 at 08:15:17AM +0100, Peter Dalgaard wrote:
Andrew Robinson wrote:
These are important concerns. It seems to me that adding an argument
as suggested by Bill will allow the user to side-step the problem
identified by Brian.
Bill, under what kinds of circumstances would
These are important concerns. It seems to me that adding an argument
as suggested by Bill will allow the user to side-step the problem
identified by Brian.
Bill, under what kinds of circumstances would you anticipate a
significant time penalty? I would be happy to check those out with
some
Andrew Robinson wrote:
These are important concerns. It seems to me that adding an argument
as suggested by Bill will allow the user to side-step the problem
identified by Brian.
Bill, under what kinds of circumstances would you anticipate a
significant time penalty? I would be happy to
Dear R-developers,
when tapply() is invoked on factors that have empty levels, it returns
NA. This behaviour is in accord with the tapply documentation, and is
reasonable in many cases. However, when FUN is sum, it would also
seem reasonable to return 0 instead of NA, because the sum of an
Unfortunately I think it would break too much existing code. tapply()
is an old function and many people have gotten used to the way it works
now.
This is not to suggest there could not be another argument added at the
end to indicate that you want the new behaviour, though. e.g.
tapply -
On Tue, 6 Nov 2007, [EMAIL PROTECTED] wrote:
Unfortunately I think it would break too much existing code. tapply()
is an old function and many people have gotten used to the way it works
now.
It is also not necessarily desirable: FUN(numeric(0)) might be an error.
For example:
Z -
