Patch for /gbm/R/gbmCrossVal.R

[GoogleCodeExporter]

removed X= on the X=1:cv.folds in the parLapply function call.  Here is the 
function call for parLappy:
parLapply <- function(cl, x, fun, ...)
    docall(c, clusterApply(cl, splitList(x, length(cl)), lapply, fun, ...))

I think there was confusion between "X" and 'x', since we already pass 'x' 
through to gbm.fit, I felt it was best to delete 'X' assignment and let it use 
the position of the variable to assign it to the 'x' in the parLapply.

Original issue reported on code.google.com by schneide...@gmail.com on 29 May 2013 at 6:45

Attachments:

• gbmCrossVal.R.patch

[GoogleCodeExporter]

This was in response to Issue 19

Original comment by schneide...@gmail.com on 29 May 2013 at 6:46

[GoogleCodeExporter]

Hello.

I don't understand what the  patch achieves.

> args(parLapply)
function (cl = NULL, X, fun, ...)

So the patch just avoids explicitly naming the argument, but presumably leaves 
the behaviour unchanged. What am I missing?

Thanks,
Harry

Original comment by harry.southworth on 31 May 2013 at 7:24

[GoogleCodeExporter]

Alright, so I trace the problem deeper.

> args(parLapply)
function (cl, x, fun, ...) 

I was confused why I have 'x' instead of 'X'.  This is the difference between 
parLapply being defined by the base 'parallel' package verses the 'snow' 
package.  This explains the erratic behavior, it is whether snow is loaded or 
not.  

So by removing the explicitly named argument, the function call will work with 
both versions of parLapply. 

Original comment by schneide...@gmail.com on 31 May 2013 at 3:44

[GoogleCodeExporter]

In version 2.1-0.1 (which can be downloaded from this site), the call to 
parLapply is made explicitly to parallel::parLapply

Is the problem fixed in 2.1-0.1

Thanks,
Harry

Original comment by harry.southworth on 5 Jun 2013 at 12:55