ds produces unexpected check.mono warnings

[lenthomas]

Using Distance 2.0.0 and mrds 3.0.0.

The following code uses these duiker data: DaytimeDistances.txt

DuikerCameraTraps <- read.csv(file="DaytimeDistances.txt", header=TRUE, sep="\t")
DuikerCameraTraps$Area <- DuikerCameraTraps$Area / (1000*1000)
DuikerCameraTraps$object <- NA
DuikerCameraTraps$object[!is.na(DuikerCameraTraps$distance)] <- 1:sum(!is.na(DuikerCameraTraps$distance))

library(Distance)
trunc.list <- list(left = 2, right = 15)
mybreaks <- c(seq(2, 8, 1), 10, 12, 15)
conversion <- convert_units("meter", NULL, "square kilometer")
hn2 <- ds(DuikerCameraTraps, transect = "point", key = "hn", adjustment = "cos",
          nadj=2, convert_units = conversion,
          cutpoints = mybreaks, truncation = trunc.list)
plot(hn2)

This produces the following output:

Fitting half-normal key function with cosine(2,3) adjustments
Warning in check.mono(result, n.pts = control$mono.points) :
  Detection function is greater than 1 at some distances
Warning in check.mono(result, n.pts = control$mono.points) :
  Detection function is greater than 1 at some distances
AIC= 44031.553
Warning in mrds::check.mono(model, n.pts = 10) :
  Detection function is greater than 1 at some distances

However, the fitted detection function looks fine:

It's possible perhaps that the issue is to do with left truncation, and that the detection function goes marginally above 1 at distances less than the left truncation distance

plot(hn2, xlim = c(0, 16))

Here is a check of that

> x <- seq(0, 1, by = 0.1)
> x
 [1] 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
> detfct(x, hn2$ddf$ds$aux$ddfobj, width = 15, index = 1)
 [1] 1.0000000 1.0000006 1.0000021 1.0000035 1.0000030 0.9999982 0.9999862 0.9999631
 [9] 0.9999246 0.9998658 0.9997812

Yes, that seems to be it. I'll post as an issue and perhaps we can discuss how this arises -- perhaps the bounds within the optimizer are not the same as those in check.mono, perhaps just for left truncated data?

[lenthomas]

I have tagged @fpetersma for your comments, Felix.

[erex]

Amazing that the duiker dataset just keeps on throwing up challenges. Do the rest of the candidate model set with adjustments also misbehave?

[lenthomas]

No, just this one. I suspect it's pointing up a wider problem with the constraint-checking locations (distances) when there is left truncation being different in the optimizer vs the after-fitting checker -- but I could easily be wrong about that.

[fpetersma]

There it is: the first bug. The day we all knew would come. I will try to find some time soon to look into it and see if I can figure out, but like you said, it seems like it has to do with how check.mono and the fitting select points. If that turns out to be the cause, then I do have a follow up question: what is the right way to treat the detection function part on the left side of the left truncation? Is it a problem if it does something odd, like be larger than one, for distances that are not used anyway? It seems to me that we don't really care what happens to the detection function to the right of the width, or at least, we don't include point past the width for monotonicity checks -- does that apply to the left side as well?