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 functionmxModel(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 inmyentities <- 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
Copyright © 2007-2024 The OpenMx Project