Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add g3_param_project() for both random devates & projections #186

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

lentinj
Copy link
Collaborator

@lentinj lentinj commented Sep 24, 2024

Right, I think this is ready now. The final commit is the interesting one.

The most interesting bit to look at is the documentation, which shows how to use it

But essentially you fill a gap for a formula with g3_param_project() and you get per-step/per-year parameters, a likelihood component & projections based around the same parameters the likelhood component uses:

    g3a_naturalmortality(st, g3a_naturalmortality_exp(
        g3_param_project("Mdn", g3_param_project_dnorm(
          mean_f = g3_parameterized("Mdn_mean", value = 0.1, optimise = FALSE),
          stddev_f = g3_parameterized("Mdn_sd", value = 0.001, optimise = FALSE) )))),
    NULL )

The main thing that's irritating me is there's no by_stock option. I've not thought of a non-painful way of doing it, so not added it for now, but it's an obvious thing to want.

We should probably have parametrised defaults for mean/stddev as above. Naming these is also marginally tricky, but not the end of the world.

@bthe any thoughts?

Fixes #181

If you do, it's if (x) { if (y) yy else zz }

g3_to_tmb also needs to handle this when creating nested tertaries.
It doesn't make any sense, but is possible to create. Let it pass
through so the R parser can worry about it.
We know moo[[4]] will be scalar, so add this to value_is_scalar() for
is.nan, etc. to use.
Instead of using a global formula,

* Move the nll deriving to model shutdown
* Set nllstock__nll within the nll formula returned
* If formula doesn't define it, then make a stock instance for it

This is the same idea that will be used in param_project
Assume anything in a formula with a name generated by step_id() (i.e. starting
with "###:") is an ancillary step, keep passing it through
f_substitute(), and collate them separately at the end.

This allows any per-step setup to be performed, not just the limited
amount allowed by g3_global_formula().
Add g3_param_project() that combines g3_parameterized(by_year = TRUE),
g3l_random_dnorm() and projection abilities into one formula.

Use ancillary steps to smuggle likelihood / projection setting out so
we can do all this without needing a separate action to populate the
array.
@bthe
Copy link
Collaborator

bthe commented Sep 25, 2024

Yes, this sounds pretty good. There are two scenarios I don't see immediately how we can deal with though:

  • Should there be a generic g3_param_project_custom where the user could supply its own likelihood function?
  • How would you deal with correlated time-series? In this scenario we could consider $L_\infty$ and $\kappa$ in Von B to be timevarying but from a joint multi-variate normal distribution.

@lentinj
Copy link
Collaborator Author

lentinj commented Sep 25, 2024

Should there be a generic g3_param_project_custom where the user could supply its own likelihood function?

You could supply your own list with the pair of formulas, nll & project easily enough, or replace the formula returned by g3_param_project_dnorm. Depends on what your custom likelihood is hoping to do. It'd be a lot of boilerplate to just replace dnorm/rnorm with another pair of functions, but I think if that was the case it'd be easier to add all the variants to gadget3.

@lentinj
Copy link
Collaborator Author

lentinj commented Sep 26, 2024

How would you deal with correlated time-series?

We'd need a set of helpers corresponding to TMB's UNSTRUCTURED_CORR / VECSCALE for specifying the nature of the correlation matrix, but that's easy enough. Simulations could be wedged into another native function.

From an interface point of view, the more interesting question is we have a similar problem to M, we have an array of dimensions c(time, c('Linf', K)), but want to refer to the individual parts in different places. We also don't want to have to define this array twice. This is worth having a decent answer to before merging the above.

@lentinj lentinj mentioned this pull request Sep 27, 2024
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Combined g3_param_table / g3l_random_dnorm()
2 participants