R (spatstat): Built-In Functions Not Evaluating to Desired Limit

Question

So the problem I've run into is pretty basic, but I can't seem to solve it. I've been working with spatstat's F, G, J, K, and L functions, and I want to plot the F function for one point process on the same plot as the F function for a different point process. This has been easy, except that one of my point processes evaluates the function to r = 20 and the other to r = 15 ('r' is the independent variable on the x-axis). I want them to both be evaluated to the same r value, preferably 20. How would I do this? Essentially, this is the problem.

First I create the data frame containing the function's values:

mydata.Fest <- Fest(mydata)

Then, for some reason, this line of code:

plot(mydata.Fest)

Does not evaluate to the same 'r' (independent variable) value as this line of code:

plot(mydata.Fest, xlim=c(0,20), ylim=c(0,0.8))

Both plots go from xlim = c(0,20) and ylim = c(0,0.8), but for some reason the second one stops evaluating the function at x = 15. Considering that they are plotted from the same object, I haven't got a clue as to why they don't produce the same plot.

As a side note, I've been having another problem: when working with the F, J and K functions, I've found that adjusting the limits (particularly that of the independent variable) causes R to crash unexpectedly. If you've had this problem, or know of a solution, please let me know.

Thanks!

Answer 1

This is a FAQ. It is discussed on the spatstat.org FAQ page.

The summary functions in spatstat, such as Fest and Kest, have a 'recommended range' for the independent variable, which may be shorter than the range of values for which the function has been computed. The recommended range is the range where the function estimate is statistically reliable. By default, the function is plotted only to the recommended limits. (This is the standard practice in spatial statistics. If we didn't do this, then most plots would look weird because the function values blow up and the reliable information would be scaled down to occupy just a small part of the lower left of the plot.)

To inspect the available and recommended ranges of r, print the function object (just type its name) and look at the last few lines of output.

To control the plot limits, use xlim and ylim.

For more details, see the workshop notes www.csiro.au/resources/pf16h.html

Adrian Baddeley - package author

Answer 2

Hmm this is a bit strange. Sorry not an answer, but figured it would be best for others to investigate by leaving a reproducible example of the behavior you described.

What I have done in the past is to make a consistent vector of bins with which to evaluate the seperate point patterns.

library(spatstat)
data(lansing)

mydata1 <- lansing[lansing$marks == "blackoak",]
mydata2 <- lansing[lansing$marks == "hickory",]

my_r <- (0:40*.002)

mydata1.Fest2 <- Fest(mydata1, r = my_r)
mydata2.Fest2 <- Fest(mydata2, r = my_r)

plot(mydata1.Fest2)
plot(mydata2.Fest2, add = TRUE)

mydata1.Fest2$r
mydata2.Fest2$r

As one can see, the distance bins are the same, but the functions were not evaluated over the same set. I checked and this is perhaps behavior unique to Fest, I was able to get the expected solution when I used Kest. Example below.

mydata1.Kest <- Kest(mydata1)
my_k <- mydata1.Kest$r
mydata2.Kest <- Kest(mydata2, r = my_k)

plot(mydata1.Kest)
plot(mydata2.Kest, add = TRUE)

I assume this is not expected behavior for Fest, but I'm not that familiar with the technique and how it is different from Ripley's K, so I certainly could be mistaken and this is expected behavior for some reason unknown to me. I also had an unexpected crash similar to what you described when trying to set the axis limits on the output device, but I was unable to reproduce it. So maybe you are on to something or we are both crazy!

Answer 3

I contacted Dr. Adrian Baddeley (the creator of 'spatstat') regarding the issue, and he told me that this example demonstrates a bug in plot.fv when add=TRUE. This will be fixed in spatstat version 1.28-1.