Several testers here at KU found the errors produced in R rather uninformative. It is clear when something goes wrong, but it seems to be frequently unclear what can be done to correct the problem. The general suggestion was made that having very informative error information, more like the old Mx, would be preferable. I'll leave it open to discussion --- but that was the feedback from several testers in the middle of the country.
Agreed.
However, there is only so much we can do. If the error is generated by R itself, we can only pass the buck to the R developers.
If the error is one where we have control (an SEM error of some kind) we are very open to suggestions from the community about what would be useful as an error message.
Hi,
Specific examples would be very helpful in determining what can be done by the OpenMx library developers.
I'd love to help with error message authoring, with a view to injecting more information and hopefully a little humor to salve users' frustration with the software.
I heartily agree that compiling a list of error messages and their usual causes would be extremely valuable in this regard. This might go some way towards being able to output:
"Oh, bad luck you got a vanilla R error!" Even if this is your favorite ice-cream, you may not find it to be a very helpful flavor of error message, but here it is anyway:
In our experience, this kind of error crops up when users try to ... or ... or even ...
A couple of us here at KU were discussing this very issue, and we agree that it would be very useful to compile some sort of repository of R errors for the frustrated user to reference in their time of crisis.
Maybe this list could be added to a section in the documentation as an easy reference for looking up a new or unfamiliar error message?
excellent :-)
We don't yet know what these errors are that people encounter, so compiling the list is what is needed:
Whenever you get an error that is confusing, just go here,
http://openmx.psyc.virginia.edu/wiki/errors
If the error is not already there (only one so far), just click "Edit" and add it to the page...
post a note here with some context code and soon the list will have answers.
Here's the pertinent excerpt of the code which lead to Vexing Error #1 on the wiki:
# factor loadings for a variables
mxPath(from="FA",
to=c("a1","a2","a3","a4","a5","a6","a7","a8","a9","a10"),
arrows=1,
free=c(TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE,TRUE),
values=c(.3,.3,.3,.3,.3,.3,.3,.3,.3,.3),
labels=c("l1","l2","l3","l4","l5","l6","l7","l8","l9","l10")
),
#Effects Coding
I introduced these 11 new matrices in an attempt to set the scale for factor A using the effects coding method, but I hit a wall of errors that I can't figure out.
You are trying to set the value of those matrices to a character label.
We try and convert the character to a numeric value, can't, return an NA... hence the error: NAs induced by coercion.
if you want matrix "la" to have its value equated to "l1", then make the label of matrix "la" be "l1"
that's also setting the bounds on a fixed value, which is not necessary?
Thanks a bunch! That did it, but I ended up having to free the elements of the 1X1 matrices to get them to equate with the lambdas. The code ended up looking like this:
Several lines are of the form:
The 'values' argument expects a numeric argument. Looks like I need to add some error checking. At the moment, this character is being converted into an NA, and then the NA is thrown away and 0 is used.
Type checking to arguments of the mxMatrix() function has been added in revision 786 of the repository.
need to check that all=(TRUE|FALSE)
currently it doesn't error on non-boolean's like "2"