For this commit it is not a real problem, since I plan to use in a few weeks an automatic tool for reindenting all the C++ code of the project. But please pay attention to that for your subsequent commits.
I'm sorry, but I was not aware of the coding standards. Before I received this email, I had made some edits to the code using XCode (Mac dev tool). I have since switched to emacs and set it such that only spaces are used. Should I svn commit everything so that when you run the update it will take care of any tabs that may still remain in my local version? NB: though the code compiles, the Expectation operator is not complete.
you are right, there is a flaw in the specification: oo_ is not know to
function <fname>_dynamic.m There are two solutions:
- add steady_state to the list of arguments of this function. This is
probably more elegant. The drawback is that we increase the number of arguments of the function for a rarely used feature 2) call Matlab global variable oo_ from inside <fname>_dynamic.m. The preprocessor can add the code only for those models that actually use the STEADY_STATE operator. In this case, it will be slower than 1), but the code doesn't change for the majority of cases. What do you think, everybody?
I think I prefer solution 2): this operator is probably not used enough to warrant the slowdown which would probably be incurred with solution 1).
I have modified the DataTree class such that it contains a bool function containsSteadyStateOperator() and a protected bool steady_state_found, which is initialized to false and set to true in AddSteadyState(). Then, in DynamicModel.cc I write "global oo_;" only if containsSteadyStateOperator() returns true. Is this the solution you had in mind? Do you have any other suggestions?
Also, regarding eval_opcode for both the STEADY_STATE operator and the EXPECTATION operator, should it throw an EvalException?
Finally, should the derivative of the EXPECTATION operator just return the derivative of the expression (darg2)?
Thanks, Houtan