Is your feature request related to a problem? Please describe.
The user will need to be able to specify priors for fixed effects, and include a Jacobian adjustment when using MCMC when a transformation is used.
Describe the solution you would like.
The user should be able to specify diverse priors from the R side, and let FIMS handle the rest internally. So for instance one might put a normal prior on natural mortality, or a gamma prior on a process error like sigmaR. In these cases the parameter is (probably) declared and optimized in log space (logM), but the prior is applied in natural space like M~N(.2,.1). An automatic Jacobian (nll+=logM) needs to be done only when doing MCMC so that the prior information is correctly incorporated. The same goes for logit parameters and other transformations, although these will be much less common.
So on the user it it would be like the following, assuming these are Parameter class objects.
logM.priortype='normal'
logM.priorpars=c(.2,.1)
We'd need internal checks that priorpars and priortype are compatible and to have a default of 'none' so priors are opt-in.
Describe alternatives you have considered
N\A
Statistical validity, if applicable
Parameter priors are a fundamental part of Bayesian assessments, but also serve as "penalties" in frequentist approaches. These are widely used, e.g., each SS3 parameter has a prior option.
Describe if this is needed for a management application
N\A
Additional context
This is related to Parameter bound issue #410
Is your feature request related to a problem? Please describe.
The user will need to be able to specify priors for fixed effects, and include a Jacobian adjustment when using MCMC when a transformation is used.
Describe the solution you would like.
The user should be able to specify diverse priors from the R side, and let FIMS handle the rest internally. So for instance one might put a normal prior on natural mortality, or a gamma prior on a process error like sigmaR. In these cases the parameter is (probably) declared and optimized in log space (logM), but the prior is applied in natural space like M~N(.2,.1). An automatic Jacobian (
nll+=logM) needs to be done only when doing MCMC so that the prior information is correctly incorporated. The same goes for logit parameters and other transformations, although these will be much less common.So on the user it it would be like the following, assuming these are Parameter class objects.
We'd need internal checks that priorpars and priortype are compatible and to have a default of 'none' so priors are opt-in.
Describe alternatives you have considered
N\A
Statistical validity, if applicable
Parameter priors are a fundamental part of Bayesian assessments, but also serve as "penalties" in frequentist approaches. These are widely used, e.g., each SS3 parameter has a prior option.
Describe if this is needed for a management application
N\A
Additional context
This is related to Parameter bound issue #410