[Rd] There is pmin and pmax each taking na.rm, how about psum?

[Justin Talbot]

>
> Then the case for psum is more for convenience and speed -vs-
> colSums(rbind(x,y), na.rm=TRUE)), since rbind will copy x and y into a new
> matrix. The case for pprod is similar, plus colProds doesn't exist.
>

Right, and consistency; for what that's worth.

>> Thus, + should have the signature: `+`(..., na.rm=FALSE), which would
>> allow you to do things like:
>>
>> `+`(c(1,2),c(1,2),c(1,2),NA, na.rm=TRUE) = c(3,6)
>>
>> If you don't like typing `+`, you could always alias psum to `+`.
>
> But there would be a cost, wouldn't there? `+` is a dyadic .Primitive.
> Changing that to take `...` and `na.rm` could slow it down (iiuc), and any
> changes to the existing language are risky.  For example :
>     `+`(1,2,3)
> is currently an error. Changing that to do something might have
> implications for some of the 4,000 packages (some might rely on that being
> an error), with a possible speed cost too.
>

There would be a very slight performance cost for the current
interpreter. For the new bytecode compiler though there would be no
performance cost since the common binary form can be detected at
compile time and an optimized bytecode can be emitted for it.

Taking what's currently an error and making it legal is a pretty safe
change; unless someone is currently relying on `+`(1,2,3) to return an
error, which I doubt. I think the bigger question on making this
change work would be on the S3 dispatch logic. I don't understand the
intricacies of S3 well enough to know if this change is plausible or
not.

> In contrast, adding two functions that didn't exist before: psum and pprod,
> seems to be a safer and simpler proposition.

Definitely easier. Leaves the language a bit more complicated, but
that might be the right trade off. I would strongly suggest adding
pany and pall as well. I find myself wishing for them all the time.
prange would be nice as well.

Justin