You are here

Can a model contain a free parameter and a fixed parameter with the same name?

12 posts / 0 new
Last post
Steve's picture
Offline
Joined: 07/30/2009 - 14:03
Can a model contain a free parameter and a fixed parameter with the same name?
  1. Suppose a model has two free parameters.

  2. You equate the two parameters by giving them the same name.

  3. Now, you fix one of the parameters.

What should happen? One parameter is free and the other is fixed and they both are equated.

Currently OpenMx throws an error. Is there a more sensible thing to do?

neale's picture
Offline
Joined: 07/31/2009 - 15:14
In my opinion, fixing one of

In my opinion, fixing one of the parameters should fix all parameters with that same name. Two scenarios seem both to support this behavior:

  1. Suppose you have a complex model with the same parameter in 100 different locations. Do you want to have to issue 100 fix commands to get that one parameter fixed everywhere? I think not.

  2. Suppose you just want to fix only one of the 100 different locations of this parameter. The easy way to do this would be to change the name of the parameter in that one location, and to fix it.

The only way around 1 might be to program a fixallinstances(parametername="") function that would hunt down every parameter, but this would seem to be an unnecessary additional command if the default behavior of fixing includes all instances is adequate. That is, fix would not be overloaded by changing default behavior to fixing all instances of that name.

Steve's picture
Offline
Joined: 07/30/2009 - 14:03
Suppose you fix two of the

Suppose you fix two of the hundred and the "any are fixed then all are fixed" rule is in effect.

Later you find and free one of them and there is apparently no effect. Frustrating.

Another rule might be "all parameters named the same take on the state of the last free/fix change"

But then, what happens if you add a new parameter with the same name as the old parameters. Do the old parameters all get changed to match the free/fixed state of the new?

This isn't as easy as it might seem at first glance.

neale's picture
Offline
Joined: 07/31/2009 - 15:14
Agreed, it's not that easy,

Agreed, it's not that easy, but I think there is still an intuitive path through the maze. If the parameter has explicit free=T or free=F argument, then all parameters of that name should inherit that status. If other matrix elements are found whose status is being automatically changed (and we could check to see if any have been changed rather than just whether they exist) then we issue a warning notification to that effect. If the fix/specification call does not have an explicit free= argument, then the parameter should inherit the same status as all other parameters of that same label in the model.

Alternatively, a warning could be thrown that says "I'm going to ignore what you said about making that parameter free or fixed, because there are other parameters with the same label and their state is 'fixed' (or 'free'). This would have the advantage of stopping accidental fixing or freeing of parameters, but would force the user to issue a second command, explicitly freeing/fixing a matrix element that already has a label. This seems like a less desirable option to me, as the users are forced to use two commands instead of one. Less ergonomic for little additional caution.

I am thinking that a "Note, the matrix element you have just assigned a label to appears elsewhere in the model, it is fixed/free and this element is accordingly fixed/free" might be useful in any case. It would reduce accidental equality constraints, which are a common bugbear of modeling.

It seems to me crucial that all parameters with the same label should be equated in both value and parameter specification. This should not be compromised, ever.

Steve's picture
Offline
Joined: 07/30/2009 - 14:03
I agree with this statement

I agree with this statement 100%: "It seems to me crucial that all parameters with the same label should be equated in both value and parameter specification. This should not be compromised, ever."

What I'm having trouble with is what should we do "behind the curtain". Because it isn't obvious to me that everyone will agree with what should be done. If we "automagically" do something, it should be something that is so intuitively obvious that if we didn't do it, almost everyone would be surprised.

For a while, we tossed around the idea of having a parameter name, say, "myBeta" be required to be unique within a model. Then if you wanted to perform equality constraints, you would put "=myBeta" in the parameter name. This has the advantage of making the equality constraints into a tree. If you want to free/fix the tree, you know where the root is. Of course, if you delete the parameter "myBeta" then you need to go clean up everything that depends on it.

The interesting thing here is that if you allow a label such as "myGamma=myBeta", then you could create a multibranch dependency tree of constraints. And you could then point the root of that tree at something else, e.g., "myBeta=myMatrixAlgebra". Of course, we would need to exclude variables in a dependency tree that depended on an algebra from being elements in the algebra itself!

One of the other core developers may be able to recall why we decided against the "=myBeta" approach, if indeed a decision was reached rather than just being deferred.

tbates's picture
Offline
Joined: 07/31/2009 - 14:25
True Names 1. Suppose a model

True Names
1. Suppose a model had two free parameters.
2. But you equated the two by giving them the same name, so now you have one, just in different places.
3. Now, you fix one of the parameters: so of course the other one is fixed as well.
...

I guess its just a matter of knowing that names really matter, and then the outcome is intuitive, and the kind of thing you'd expect a name to do behind the scenes.

Vernor Vinge

Steve's picture
Offline
Joined: 07/30/2009 - 14:03
But now you rename one of the

But now you rename one of the parameters. They are no longer the same thing. Does the one that had been automagically fixed go back to its free state, or does it remain fixed? This is where it gets sticky.

If I understand correctly, Mike Neale was arguing that it would be a pain to have to "unfix" parameters parameters by hand. I can see arguments going both ways.

Here's another use case. Suppose I have two parameters "a" and "b". "a" is fixed, and "b" is free. Now I change "a"'s label to be "b". Am I fixing "b" or freeing "b"? I see arguments in favor of both possibilities.

Either we need to deal with all of these cases or we need to throw an error. Currently we throw an error and are in effect saying, "Dear user, please supply me with consistent information."

The reason this is being discussed is that I'm hoping that there is a better way than just kicking it back to the user.

neale's picture
Offline
Joined: 07/31/2009 - 15:14
It is intuitive to me that

It is intuitive to me that whenever you simply relabel a matrix element to the same label as another parameter, it should inherit the properties of that pre-existing parameter (fixed or free as may be). The only possible (I am not convinced that this is the right thing to do) override of this behavior would be in the case when you explicitly declare the free-ing or fixing with a free= command. That is perhaps a shortcut for the users to stop them having to issue a second command which does no relabeling, but merely changes the status of a pre-existing label.

Some of my intuitions are based on Mx1 behavior. Here, if you change a matrix element specification (the equivalent of changing its label in OpenMx) to a parameter number that exists already, it gets a) freed and b) equated in value to that pre-existing parameter number. There is a risk of confusing the Mx1 userbase if we diverge too dramatically from this pattern.

However, there is new functionality in OpenMx, namely retaining matrix element labels when elements may be fixed, which is very valuable.

I am in favor of letting on to the user what is going on when anything automagic happens. This isn't discworld after all, at least afaik :).

Steve's picture
Offline
Joined: 07/30/2009 - 14:03
I am going to keep pressing

I am going to keep pressing this issue, because I think we need to think through the consequences.

If I understand Mike's suggestion, if I write

mxPath(from="x", to="y", label="beta")

the default behavior of the free= argument will depend on whether there exists another "beta" in the model.

If I write

mxPath(from="x", to="y", free=F, label="beta")

I change all the other paths named "beta" to free=F

If I now say, oops I meant the path from x to y to be called "gamma"

mxPath(from="x", to="y", free=F, label="gamma")

All of the other paths named beta will have been set to fixed without ever directly referencing them.

neale's picture
Offline
Joined: 07/31/2009 - 15:14
Definitely keep pressing! I

Definitely keep pressing! I would say that they were directly referred to by the use of the first mxPath statement. In fact, had the x to y path already been called beta, the same thing would have happened, this being the only way to change all the beta paths. The undo for this would be to pick another of the paths named beta and to free=T it. Or indeed

mxPath(from="x", to="y", free=T, label="beta")

would undo, but only if the previous state was T. Aha, so the undo is not always the same. This suggests to me that an

mxUndo("wtf_I_just_did")

could be extremely useful at times. It belongs in an interactive modeling environment, just as it does in editing or drawing software.

Jeff's picture
Offline
Joined: 07/31/2009 - 05:40
Ooh, an R undo stack feature

Ooh, an R undo stack feature would be very interesting. Perhaps we should add this to the "wishlist" for an enterprising student.

On the question at hand, perhaps we need to consider the workflow. Is there a way that we can encourage users to deal with equivalencies right before their model is run, perhaps using an object that would provide easy access to change things? Because I agree, Steve, that this becomes a complex problem with results that are not necessarily intuitive or desirable.

tbates's picture
Offline
Joined: 07/31/2009 - 14:25
Just to concur with Steve's

Just to concur with Steve's concern about paths being changed without ever directly referencing them.

If a user writes

mxPath(from="x", to="y", label="beta")

and something called beta already exists, then the unspecified arguments, like free, will copy the existing path's settings. But attempting to specify these settings (changing other unknown paths) should return an error "Path with this label already exists. Please use new label, or don't try and set anything other than from and to"

It is so easy be explicit here, just make the new path, then change "free" by label.

PS: It would be handy to have a function to tell the user where all the paths/ matrix cells are which share a given label

mxObjectsLabelled("A")

<

pre>
paths
"A", fixed to 1
E<->N
A<->N