views:

80

answers:

2

Consider this output from browser() that is located inside calcDistance:

Called from: calcDistance(object = rst, xy = xy[[i]][j, ], effect.distance = effect.distance)
Browse[1]> ls.str()
effect.distance :  num 236
object : Formal class 'RasterLayer' [package "raster"] with 12 slots
xy :  Named num [1:2] -101.8 35.5

Browse[1]> 
debugging in: xyValues(object = object, xy = xy, buffer = effect.distance)
debug: standardGeneric("xyValues")

Browse[2]> ls.str()
object : Formal class 'RasterLayer' [package "raster"] with 12 slots
xy :  Named num [1:2] -101.8 35.5

Functions are as follows: simulationRun > createDistRaster > calcDistance > raster::xyValues. In the above output, you only see the last two. xyValues is from raster package.

First paragraph of code shows that three objects are present: effect.distance, object, xy. In second paragraph, we descend into xyValues by calling debug(xyValues). In third paragraph we can see that effect.distance is missing.

My question is: Even though object and xy seem to be copied to the xyValues environment just fine, effect.distance is not. How could this be explained?

My sessionInfo()

R version 2.11.1 (2010-05-31) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=Slovenian_Slovenia.1250  LC_CTYPE=Slovenian_Slovenia.1250   
[3] LC_MONETARY=Slovenian_Slovenia.1250 LC_NUMERIC=C                       
[5] LC_TIME=Slovenian_Slovenia.1250    

attached base packages:
[1] splines   stats     graphics  grDevices utils     datasets  methods  
[8] base     

other attached packages:
 [1] raster_1.3-11   foreach_1.3.0   codetools_0.2-2 iterators_1.0.3
 [5] Hmisc_3.8-2     survival_2.35-8 spam_0.22-0     splancs_2.01-27
 [9] sp_0.9-66       spatstat_1.20-2 deldir_0.0-12   mgcv_1.6-2     

loaded via a namespace (and not attached):
[1] cluster_1.12.3     grid_2.11.1        lattice_0.18-8     Matrix_0.999375-39
[5] nlme_3.1-96        tools_2.11.1 
+2  A: 

UPDATE : This problem is also discussed on the R mailing list, and it turned out to be a bug/inconsistency in the resolving of passed arguments in specific cases. This is reported to R. The discussion can be found at : Nabble


Quite an interesting problem. When you check

showMethods("xyValues",incl=T)

There are two important chunks of code. The one with signature vector for xy, and one for xy as a matrix. As your object is a "RasterLayer" object, you need to make sure origin.point is a matrix. This is pretty counterintuitive actually if we look at the code

object="Raster", xy="vector"
function (object, xy, ...) 
{
    if (length(xy) == 2) {
        callGeneric(object, matrix(xy, ncol = 2), ...)
    }
    else {
        stop("xy coordinates should be a two-column matrix or data.frame, or a vector of two numbers.")
    }
}

So this actually only transforms the xy argument to a matrix, and passes all other arguments to the next generic. The next one has to be this one then :

object="RasterLayer", xy="matrix"
function (object, xy, ...) 
{
    .local <- function (object, xy, method = "simple", buffer = NULL, 
        fun = NULL, na.rm = TRUE) 
    {
        if (dim(xy)[2] != 2) {
            stop("xy has wrong dimensions; it should have 2 columns")
        }
        if (!is.null(buffer)) {
            return(.xyvBuf(object, xy, buffer, fun, na.rm = na.rm))
        }
        if (method == "bilinear") {
            return(.bilinearValue(object, xy))
        }
        else if (method == "simple") {
            cells <- cellFromXY(object, xy)
            return(.readCells(object, cells))
        }
        else {
            stop("invalid method argument. Should be simple or bilinear.")
        }
    }
    .local(object, xy, ...)
}

This one takes the argument "buffer". Why the value for the argument can't be found in the parse tree, I have no clue, but you could try to avoid the method cascade by giving a matrix as input instead of a vector.

Joris Meys
Author of the function has already fixed the problem by adding explicitly arguments buffer and fun to all methods. As Joris pointed out, passing buffer argument as a matrix did the trick. Storing the buffer variable in global environment does the trick as well. Not that it matters, because it's already fixed in the original function. :)
Roman Luštrik
+1  A: 

buffer argument is passed through ... argument. Type str(list(...)) under debug mode.

Marek
Indeed, the argument itself is passed, I worded it wrong. The value for the argument is not, it disappears from the parse tree and cannot be found back. Hence the error. Thanks for the correction.
Joris Meys