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?

[fpetersma]

So, I had a look at check.mono(). Here getRefPoints() (which is stored in detfct.fit.mono.R) is used to get the reference points and takes a left and right bound as argument. However, the left bound is not used. In the comments in getRefPoints() the following is stated:

  # previous versions just used width and assumed that left truncation
  # was at zero, now using int.range to tell us the interval
  # going back to just using width to be consistent with Distance for Windows
  # see https://github.com/DistanceDevelopment/Distance/issues/135

That is interesting on itself. However, this does not explain the issue. Since all processes that have to do with monotonicty checks, either in the solver itself or in check.mono(), use getRefPoints so it seems that in all cases the left bound is ingored. The default tolerance of check.mono() is 1e-8 which is the same as the default (in)equality tolerance of nloptr(). So I'm a bit puzzled..

[fpetersma]

Okay, I just ran the code to confirm that I got the same error message, and my result actually passes the monotonicity check fine? Also no warnings during the fitting proces.

To make sure there are no mistakes, this is the code I ran:

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)

check.mono(hn2$ddf, n.pts=10) # gives TRUE

and I got output

Fitting half-normal key function with cosine(2,3) adjustments
AIC= 44031.584
[1] TRUE

I am not getting any monotonicty warnings, not during the fitting and not when performing a post check. I also reran your other code.

> x <- seq(0, 1, by = 0.1)
> detfct(x, hn2$ddf$ds$aux$ddfobj, width = 15, index = 1)
 [1] 1.0000000 1.0000004 1.0000013 1.0000017 0.9999998 0.9999932 0.9999790 0.9999534 0.9999120 0.9998500 0.9997617

which gives slightly different results. The reference poitns that getRefPoints() gives in this situation are

getRefPoints(10, c(2, 15))
 [1]  0.4743416  1.3416408  2.4647515  3.7947332  5.3033009  6.9713700  8.7849303 10.7331263 12.8072245 15.0000000

Even though there is a very small increase above one within the tolerance of 1e-8, at points 0.1, 0.2 and 0.3, this is not picked up in my case because the first reference point si 0.474, at whcih point the detection function is again below 1.

I wonder what could be the cause of the slight variation in results. @lenthomas can you double check/confirm that you used the latest versions of mrds and Distance?

[lenthomas]

Thanks for looking into this Felix.

I re-ran my example, and get the same results as you. I must have been using an out-of-date version previously. So, I concur there is no issue here now. Just to note that I had to add mrds::: to the call to getRefPoints, i.e., mrds:::getRefPoints to get your code to work -- the getRefPoints function is not exported.

I also see that the checking that is performed during optimization is now the same as the checking done after optimization, which is great. We therefore should not get this kind of warning when strict monotonicity is specified for the optimziation.

I did notice a few small things that I raise here, and will be happy to either fix or raise as separate issues:

• The help for check.mono incorrectly says that for the argument n.points the points are equally spaced. I suggest changing "number of equally-spaced points" to "number of points". If we wanted to give even more information about how these points are selected, I suggest exporting getRefPoints and adding help to it to explian how the ref points are calculated and point to this from check.mono (rather than doing the explanation in check.mono since then if we change getRefPoints we have to remember to change the check.mono documentation.

• I can't make sense of the plot that come from calling check.mono(hn2$ddf, plot = TRUE) in that I expect the pink bar at the top to show where one of the constraints is broken, but it looks pink everywhere. I suspect there is a bug in the chpply function, which is defined within check.mono but I have not looked into it. I can raise as a separate issue if that's helpful.

I'll leave this issue open for now while we agree what to do about the above two small things.