> On Sun, Nov 4, 2012 at 6:35 AM, Justin Talbot <jtal...@stanford.edu> > wrote: >>> >>> 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.
Interesting. Sounds more possible than I thought. >> >>> 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. > > Have a look at the matrixStats package; it might bring what you're looking > for: > > http://cran.r-project.org/web/packages/matrixStats > > /Henrik Nice package and very handy. It has colProds, too. But its functions take a matrix. ' 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. ' Matthew ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
