Re: [Rd] Can't install.packages() from local repo in 2.15.2

Your subject line isn't truthful. At the very least you are talking about binary packages on Windows using a file:// repository ('local' does not usually mean that, and is specified by NULL). I think you have not understood the NEWS item: most likely you do not have a parallel source reposito

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

> > 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 signatur

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

On Sun, Nov 4, 2012 at 6:35 AM, Justin Talbot 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 consistenc

[Rd] parallel::mclapply list coercion limits opportunities for code re-use?

The attached diff address the following issues in mclapply mclapply coerces non-lists or objects (S3 or S4) to lists, but a list may not be an efficient representation and is not required if the object implements length, [, and [[ methods (lapply must also work on the object, either through coe

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

> On Sun, Nov 4, 2012 at 6:35 AM, Justin Talbot > 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,