Deprecate <ConditionalDerivedVariable>, <Case>

[borismarin]

<ConditionalDerivedVariable> has been marked as a candidate for deprecation (#55). It is used in NeuroML2, though.

[borismarin]

(moved from #55)

@pgleeson pgleeson commented 2 days ago I'd prefer to keep ConditionalDerivedVariable & Case. There's no other clean way to put in a conditional expression for a variable.

Fixed and Link are just used in Robert's Kinetic Scheme based channel, and could be replaced with other elements, but this needs testing...

---

@robertcannon commented 2 days ago Is ConditionalDerivedVariable used anywhere other than for writing expressions of the form x / (1 - exp(x)), where they are used to separate out the x=0 from the x!=0 cases?

I think the correct treatment for these is to introduce a named function as part of the language for this >expression ( @borismarin do you know if this function has a standard name?). Then implementations >can do their own thing with it and you keep the possibility of doing symbolic algebra which gets much >nastier if you start having branched expressions.

I see two questions here:

• Piecewise defined functions (there are plenty of models which make use piecewise continuous functions for activation dynamics). Those can either be expressed via <Case>s or combinations of terms with Heaviside steps. The latter can lead to cumbersome, less transparent formulas, but on the other hand involves only one "expression" and no extra constructs.
• Surmounting numerical artifacts, e.g. the classical trick of expanding 1-exp(x) denominators around the removable singularity at x=0. I tend to think that, in this case, explicit is better than implicit: this kind of approximation ends up being "modeling" itself, just like selecting an integration stepsize, so if we want to capture the model as accurately as possible, the approximation needs to be explicitly stated (in the form of a piecewise defined expression like above). But in many cases modelers don't even check their expressions for this kind of behavior (I've seen negative concentrations in models more than once), so wouldn't it be more interesting to have a "guard" mechanism to catch this kind of inconsistencies? We could have a domain="[a,b]" attribute associated with dynamical variables, to catch negative conductances / activation variables outside [0,1] for example.