Motivated by http://openmx.psyc.virginia.edu/thread/996 , Tim (Brick) and I have been talking about how mxPath behaves when arrows=2 and all=TRUE. The current behavior creates all possible paths, save for when excludeself is set to TRUE, in which case the paths from a variable to itself are created then ignored as best as I can figure (I wasn't there/don't remember the meeting for this spec).
There are some good reasons for this, specifically that the 'all' argument doesn't behave any differently regardless of what is put in the 'arrows' argument. However, this is somewhat inconsistent with how we treat full and symmetric matrix objects. Consider 3x3 versions of these two matrix types. Full matrices must be supplied with any number of labels provided they are an even divisor of the total number of elements: in our case, 1, 3, or 9. Symmetric matrices may only be provided with (a) a single label, (b) the number of unique elements (6, in our case) or (c) a full-rank set of elements (9), with appropriate equality constraints. This behavior should be doable in a path statement, both for internal consistency across matrix and pathic versions of a model and to make 'all=TRUE' more useable.
There is at least one major problem with having the behavior of the 'all' argument vary with the value of the arrows argument: the arrows argument accepts vectors. The code below includes a vector of values for the arrows argument, and has very puzzling behavior.
alice <- mxModel("DownTheRabbitHole", type="RAM", manifestVars=letters[1:2], mxPath(from=c("a", "b"), arrows=1:2, all=TRUE))
This code creates:
-a one-headed arrow from a to a
-a two-headed arrow from a to b
-a one-headed arrow from b to a
-a two-headed arrow from b to b
The only reason I can see to support multiple arrows values in an mxPath statement is for automatic model generation, such that you make a list of all 'from' variables in your model, a list of all 'to' variables, etc, and write an entire model in a single mxPath call. Even if you wanted to have two mxPath calls, the obvious split is with one and two headed arrows, making this feature of the arrows argument uncessary. Changing this would affect backwards compatability, so that should be discussed as well.