# Scientific Notation in Object Names

9 posts / 0 new
Offline
Joined: 07/31/2009 - 15:12
Scientific Notation in Object Names

I got a rather funny error message from a simulation I was running, and would like to share to prompt a bug fix, discussion and laughter.

Error in checkForRemoteErrors(val):
one node produced an error: The name 'untitled1e+05' is illegal because it contains the '+' character in mxMatrix("Full", values = value, name = localName)

I found the cause of the error: I used 2, 0.5 and pi in an mxAlgebra statement in my simulation, which apparently created three untitled matrices in my simulation (likely untitled1, untitled2 and untitled3 at the first iteration). As the simulation ran, the matrices were repopulated over and over until the names reached 10000, at which point running total of untitled matrices spilled over into scientific notation.

Bug fix: can we turn off scientific notation in the autopopulation of matrix/algebra/model names?

Discussion: is there a better way to handle naming conventions for autogenerated matrices? I'd like to avoid explicitly making matrices for each constant I want to use, and these matrices don't show up anywhere but model output, so I can't override the names. Seems silly to create 3,333 matrices that contain only pi, even if I overwrite them at every simulation iteration.

Laugher: HAHAHAHAHA!

Offline
Joined: 07/31/2009 - 15:24
Oops. My bad. I checked in

Oops. My bad. I checked in a patch to stop omxUntitledName() from returning scientific notations. With regards to eliminating the redundant anonymous matrices, it's possible to do it by placing these matrices somewhere secret in the global environment. Of course, that would be not entirely thread-safe. But then again, no other part of the R interpreter is thread-safe so that's not a big deal.

Offline
Joined: 07/31/2009 - 15:24
One workaround would be to

One workaround would be to explicitly create 3 1x1 MxMatrix objects in the model named "two", "onehalf", and "pi", and then place the numeric values in these MxMatrix objects. And then update the algebras to use these objects. This would also be a good basis for testing the performance penalty of creating the anonymous MxMatrix objects.

Offline
Joined: 07/31/2009 - 15:12

I thought about that, and will run that test, but that is just plain a pain for users. We added this scalar value functionality to specifically avoid having to do just that.

One could argue that these autogenerated matrices are qualitatively different from other uses of the omxUntitledName call, specifically:
-these matrices are not treated as model objects, as they're not placed in the matrices slot either before or after optimization. they're only referenced as matrices in the output slot of an optimized model.
-they have a very specific form (knowing the constant tells me everything about the matrix)

An alternative is to add a second 'untitled' type prefix for these matrices (i.e. 'constant', 'value', 'untitledconstant', etc). The suffix for this model name would be the constant value. The issues I see with this involve an extra reserved prefix, overhead for detecting this type and how do deal with decimal places ('untitledconstant3m14'?). However, every instance of a constant '2' will just overwrite the previous 'untitledconstant2' object.

Offline
Joined: 10/08/2009 - 22:37
I also had the same error

I also had the same error when I was conducting a simulation study with OpenMx 1.0.5:
Error: The name 'untitled1e+05' is illegal because it contains the '+' character in mxMatrix("Full", values = value, labels = paramName, free = TRUE, name = localName)

I intentionally created and named all the matrices (please refer to the attached function). It seems that OpenMx still creates "untitled" matrices.

I would appreciate for any suggestions. Thanks.

Regards,
Mike

indirect.lb <- function(y,m,x,conf=0.95) {
ind.model <- mxModel("indirect", type="RAM",
mxData(observed=cbind(y,m,x), type="raw"),
mxMatrix("Full", nrow=3, ncol=3, byrow=TRUE, name="A",
values=c(0,0.1,0.1,
0,0,0.1,
0,0,0),
free=c(F,T,T,
F,F,T,
F,F,F),
labels=c(NA,"b","c",
NA,NA,"a",
NA,NA,NA)),
mxMatrix("Diag", nrow=3, ncol=3, name="S",
values=c(0.5,0.5,0.5),
free=c(T,T,T),
labels=c("Var_e_y","Var_e_m","Var_x")),
mxMatrix("Iden", ncol=3, nrow=3, name="F",
dimnames=list(c("y","m","x"),c("y","m","x"))),
mxMatrix("Full", nrow=1, ncol=3, name="M",
values=c(0,0,0),
free=c(T,T,T),
labels=c("int_y", "int_m", "mean_x")),
mxAlgebra(a*b, name="IndEff"),
mxRAMObjective("A","S","F","M"),
mxCI(c("IndEff"), interval=conf))
fit <- mxRun(ind.model, intervals=TRUE, silent=TRUE)
fit.summary <- summary(fit)
c(lbound=fit.summary$CI[1], ubound=fit.summary$CI[3])
}

Offline
Joined: 07/31/2009 - 15:12

Your algebra is the culprit. You referred to free parameters "a" and "b" in your mxAlgebra, which are elements of your A matrix. As those parameters aren't matrices, OpenMx created 1x1 matrices to contain them and make them conformable to matrix operations. The quick solution would be either to put "a" and "b" in 1x1 matrices and use those in the algebra, or redefine your algebra in some way as to use the matrices you have. Michael's patch should have fixed the scientific notation bit, but untitled names are likely to hang around in some form. Any suggestions you have are welcome.

Offline
Joined: 10/08/2009 - 22:37
Thanks Ryne for the prompt

Thanks Ryne for the prompt solution!

Offline
Joined: 07/31/2009 - 15:24
Oops. Go ahead and rerun the

Oops. Go ahead and rerun the installer for OpenMx 1.0.6. I believe I just fixed it as of 11:59 PM EST 3/10/2011, and correctly this time.

Offline
Joined: 10/08/2009 - 22:37
Thanks. It works like a

Thanks. It works like a charm.