More precision needed?

[Jim Baldwin]

Many of the questions to this forum concern lack of convergence issues.  While some of these issues can be addressed with better starting values or reformulating models, I wonder if there is a need for a parallel set of routines that use multiple precision arithmetic routines (such as those available in the Rmpfr package).

I'm assuming that the current routines use various techniques to squeeze out as much precision as possible with double precision arithmetic.

And, yes, using multiple precision arithmetic would certainly be much, much slower to execute than the current routines.  But, again, might those reduce the number of issues with a lack of convergence?

Any thoughts?

Jim

[Ken Kellner]

Hi Jim,

I don't know enough about this to have an informed opinion. If you have some example code, I'd be interested to see it.

My intuition is that most of the 'convergence' type issues (and similar things like large SEs, hessian issues, etc) we see on the forums are probably not fixable with improved math or code. Rather they are just symptoms of underlying data limitations or design issues.

Ken

On Sun, May 25, 2025 at 11:35:32AM -0700, Jim Baldwin wrote:
> Many of the questions to this forum concern lack of convergence issues.
> While some of these issues can be addressed with better starting values or
> reformulating models, I wonder if there is a need for a parallel set of
> routines that use multiple precision arithmetic routines (such as those

> available in the Rmpfr package)*.*

>
> I'm assuming that the current routines use various techniques to squeeze
> out as much precision as possible with double precision arithmetic.
>
> And, yes, using multiple precision arithmetic would certainly be much, much
> slower to execute than the current routines. But, again, might those
> reduce the number of issues with a lack of convergence?
>
> Any thoughts?
>
> Jim
>

> --
> *** Three hierarchical modeling email lists ***
> (1) unmarked (this list): for questions specific to the R package unmarked
> (2) SCR: for design and Bayesian or non-bayesian analysis of spatial capture-recapture
> (3) HMecology: for everything else, especially material covered in the books by Royle & Dorazio (2008), Kéry & Schaub (2012), Kéry & Royle (2016, 2021) and Schaub & Kéry (2022)
> ---
> You received this message because you are subscribed to the Google Groups "unmarked" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to unmarked+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/unmarked/CAJCKiwyab65iqoD1Dmrx%3D9kgzi0WfDmw8C3hSDmW9jLh7hMJyw%40mail.gmail.com.