mxNormalInterval() proposal
Posted on
mspiegel
Joined: 07/31/2009
Forums
Currently the svn repository has an implementation of likelihood-based confidence intervals. For the moment, the interface looks like the following:
model <- mxModel(model, mxNormalInterval(c('A', 'C[,]', 'E[1,1]'), 0.95, 0.95))
The first argument to mxNormalInterval() is a vector of strings. These could be either matrix/algebra names or free parameter names. The second argument is the lower confidence level, and the third argument is the upper confidence level.
Is this a reasonable interface? Is there a need for asymmetric confidence levels in this interface? Should the confidence levels be expressed in units of 0-100 instead of 0-1?
The full example is present here.
In reply to Maybe we should amend the by tbrick
It's a good idea to some
It's a good idea to some extent. However, there are cases in which boundary conditions will throw things off. So if a parameter x has an lbound of zero, and if the parameter at this value is say 2.5 units of -2lnL worse than where it started, the lower CI is indeed zero. The optimizer will, however, have strayed from the ML position (only 2.5 units worse) and actually degraded the fit further (by moving the other parameters away from what their MLE's would be if x was fixed at zero). So some flagging of when parameters are at bounds would be useful in conjunction with it.
I do see a lot of folks antsy about code Red. It is a poor diagnostic, much more often false positive than true positive in my experience. So hiding this a bit from the user might be beneficial, but at the same time it should be available for inspection.
Distance of the parameter from its MLE is only helpful in cases in which it got stuck at its MLE (and this value was not its lbound or ubound). We might make use of the asymptotic standard errors as a rough check, although these are provided only for free parameters, not for functions thereof. Some matrix calculus software would help with getting SE's of functions of parameters but that's at least version 2.0 down the road, I reckon. Note also that for computed elements we may not be able to "know" that it's effectively a boundary (x^2 would have lower bound of 9 if the lbound of x was 3, for example).
Log in or register to post comments
In reply to It's a good idea to some by neale
I agree it is probably better
I agree it is probably better not throw the optimiser warnings (code green or red) by default: just trains people to ignore them if they are mostly false.
Most people will run summary on the fit... Perhaps put a "health" parameter into the summary, which would have the model "color" in it. Then it can be seen, without being dumped into the console, and people can followup on it if necessary?
Log in or register to post comments