Bug in example speed parameterization

[camrinbraun]

From @fmasbervejillo here

In @paulgatti example code:

Line 320:
# pars sigma1 (resident), sigma2 (migrant), p11 switch from behavior 1 to 1 (remain resident), p22

Line 321 you define these initial parameters:
pars.init=c(2,.2,.6,.8)

My guess is that the first parameter is, following the logic of the former method, the migration speed (not the resident speed), and the second parameter is the fraction of that speed that is attributed to the resident speed (hence the .2?). Is this correct? otherwise, the resident speed would be 10 fold the migratory speed.

[camrinbraun]

from @paulgatti:
The idea here is to estimate the two movement parameters. I can’t recall if HMMoce forces sigma1=10*sigma2 or if it is a starting guess. In case, the intention is indeed to force that, only one (sigma1) should be estimated as the two are not independant. In fact, the code could be easily changed to estimate only 3 parameter (sigma1 and the transition probability) and thus likely save some computation time. Anyway, I am still wondering if it is better to estimate or fix swimming speed. In the case where it is possible to have an empirical estimate of swimming speed, I would likely use it (as @camrinbraun did with sharks equipped with spot tags) and avoid the tricky issue of parameter estimation which can be time consuming and I would rather test the sensitivity by altering a bit this value. Also, for my own case, I am now using a very common trick in parameter optimization, which consist in transforming the parameters within plus and minus infinity. This usually help to avoid being stuck in a local optimum (it is not a guarantee but it can help). I can provide you with that (if you are interested).