More followup about "experienced R user" reaction

5 replies [Last post]
pjohnson's picture
Offline
Joined: 09/19/2009

I was bugging you about R usage last month.  I think some elements in your design are going to confuse experienced R users and from your Wiki I gather they befuddle the new users as well. Some things you can addressed by making your "tutorial go slower". But you could tighten up usage instead, and avoid the confustion in the start.

In mxModel, you have a big important "...".  Experienced R users don't expect "..." to be used for something vital, rather it is for nonessential options inherited from superclass or such. New users don't understand "..." at all.

I think this would be easy to fix. Redesign the function

mxModel(model=NA, entities=aList, )

aList = an R list of MX entities.

For an example of this style in R, see the "aggregate" function.

So it would be clear to the user that an arbitrary number of entities can be supplied to mxModel.  It seems to me this would make parsing user in put easier as well, since you could scan this list object to make sure all elements are valid MX entities.

There's another benefit, which I think is potentially important. I've been concerned that you allow R objects with names that are different than their mx "name" slots inside the objects.  I see only FUD following from that.  People commenting on your tutorial seem to be confused by it as well.  If you have people name the Mx entities in the list, then you could get away from the mx names inside. as in

myentities <- list("A"=mxMatrix( whatever), "B"=mxMatrix (whatever))

I still haven't quite figured out why you need to re-create the whole R matrix language within the mxAlgebra function, incidentally.

Are you going to put in a place where we can enter Questions for your FAQ?

PJ

Jeff's picture
Offline
Joined: 07/31/2009
While I'm here, I'll also

While I'm here, I'll also answer your question regarding re-creating the whole R matrix language: that functionality is being written in C in the back-end so as to not have to come back to R for evaluation during optimization as this would decrease performance.

neale's picture
Offline
Joined: 07/31/2009
There's another reason;

There's another reason; mxMatrix adds a series of properties that R matrices do not inherently possess.  Element labels, whether or not elements are free parameters, upper or lower boundaries on said parameters are not features of R matrices.  Matrices could also be declared as specific types - lower triangular for example, which speeds the coding of models tremendously (especially for the novice or those familiar with Mx 1.0).  In addition, Mx 1.0 had a set of matrix functions which were not entirely available in R.  Jeff is of course correct though - like BMW, it's a case of performance first...

Jeff's picture
Offline
Joined: 07/31/2009
Yes, that's a very good

Yes, that's a very good point.  I thought the question referred to the matrix operators in MxAlgebra, but this is the more general reason.  

These should probably go into the "Why did/didn't you..." part of the FAQ that we talked about a couple weeks ago.  

mspiegel's picture
Offline
Joined: 07/31/2009
Please take a look at the

Please take a look at the function "updateSubmodels" that is used as an example in the thread: http://openmx.psyc.virginia.edu/thread/186 to illustrate why a name slot is used in OpenMx objects that is distinct from the variable name.

There are some potential benefits of using a list parameter to the mxModel() function. One disadvantage is that entity names must be explicitly re-declared across multiple invocations of the mxModel function, such as:

A &lt;- mxMatrix(stuff)
model1 &lt;- mxModel(entities = list('A' = A, stuff))
model2 &lt;- mxModel(entities = list('A' = A, otherstuff))

WRT algebra expressions in OpenMx, the back-end numerical optimizer has been written in C. A subset of matrix algebra operators and functions are implemented in the backend. See ?mxAlgebra for a list of these operators and functions. To write an objective function that evaluates an arbitrary R expression at every iteration of the optimizer, see ?mxRObjective. There is a performance penalty associated with jumping to the R interpreter at each iteration.

Jeff's picture
Offline
Joined: 07/31/2009
Since I'm dealing with site

Since I'm dealing with site admin stuff at the moment, let me answer your FAQ question: we (and you and the rest of the community) will/can update the FAQ any time you see a question being frequently asked:

http://openmx.psyc.virginia.edu/wiki/faq-openmx