Page 1 of 1

Announcing secr 4.0.2

PostPosted: Wed Nov 13, 2019 1:34 am
by murray.efford
The new, fast release of secr is now on CRAN. Details at secr-version4.pdf.

Re: Announcing secr 4.0.2

PostPosted: Thu Nov 14, 2019 1:05 pm
by mirjamb
Good morning

I switched to secr 4.0.2. from 3.2.1 after a computer crash yesterday and think there may be a bug. The log likelihood for the null model for a comparison of models i'm running is now MUCH larger than any of the models with density or det. probability covariates, with accordingly low AIC values. In addition, the summed probability density plots for the null models are off, too - just a uniform probability with a spike in the middle of the mask (but not for any of the models with covariates - those haven't changed from reflecting the data).

I just went back to 4.0.0. - same problem.
Then re-installed 3.2.1. and the problem disappears.
Any idea what's going on? Thank you!

Re: Announcing secr 4.0.2

PostPosted: Thu Nov 14, 2019 2:59 pm
by murray.efford
Er, no, but thanks for reporting this. Can you provide an example (preferable using one of the builtin datasets) or send the data and statements that cause the error? It's good to be reminded that people persist in using what you call "probability density plots".
Murray

Re: Announcing secr 4.0.2

PostPosted: Thu Nov 14, 2019 3:16 pm
by mirjamb
I'll send it to you by email.
The probability surface plot was asked for by a reviewer, and while I agree with you about its usefulness or lack thereof, in this case I'm glad I plotted it as it made me aware that something may be amiss.

Re: Announcing secr 4.0.2

PostPosted: Thu Nov 14, 2019 3:29 pm
by murray.efford
Thanks. Perhaps we should name and shame the journal that uses such reviewers.

Re: Announcing secr 4.0.2

PostPosted: Sat Nov 16, 2019 2:39 am
by murray.efford
I think there are two issues here, both resulting from the fast option for 'proximity' and 'count' data that is the default in secr 4.0.2 (details = list(fastproximity = TRUE); see secr-version4.pdf).

The first is that the fastproximity option causes sampling occasions to be collapsed, and as a result these models are not comparable by AIC to those with fastproximity = FALSE. The catch is that while fastproximity is the default, certain models (~b, ~bk, ~t etc.) silently override that default. The user can take control by setting details = list(fastproximity = FALSE) for all models to be compared. I'm sorry to have laid this trap for users - will see what can be done to warn or correct this.

The second issue is that the fx functions fail with models in which the details component has fastproximity=TRUE. This bug will be fixed in the next release, but meantime there is a simple workaround
Code: Select all
fit$details$fastproximity = FALSE
fx.total(fit) # etc.


The model fit is fine in itself, it's re-application of fastproximity that is the problem. Although the fx functions tested fine with multicatch data, they had not been tested recently against proximity data. Thanks again for reporting this.

Murray