Open bthe opened 1 month ago
The theory is that g3_init_val
makes it reasonably hard to set optimise = TRUE without upper / lower, and thus parscale.
We could set it to 1 by default, but I'm assuming this isn't very useful, and making what's originally a simple omission (setting bounds) an odd bug.
g3_iterative
could stop if any of the parameters it's likely to off/on have an NA parscale? I guess ideally we want some function to validate parameters, check initial values are within bounds, etc.
Another way of doing this could be a dry-run at the optimisation with only 1 iteration, which would potentially flush out other bugs too? You'd still have to wait for the compilation / tape for this though.
As we discussed last week, the main problem here is we default to optimise = TRUE, and NULL bounds, which is nonsense. Switching over will take a while, all the tests will be broken, but seems like a sensible choice.
Minor paper cut that I ran into yesterday.
g3_iterative
stopped because of NA's in parscale. So in order to prevent that from happening, would it be worthwhile to either set a default value for parscale for all parameters or figure out a way to warn the user earlier in the process ?