Better handle subexpressions in state updates

[mstimberg]

Currently, subexpressions are handled quite elaborately handled in statements (re-calculation is avoided) but in state updates, they are simply replaced so they don't appear in the generated code. This makes the code quite complicated and hard to read (especially for typical HH-like equations). It would be nicer if state updater would treat them in a smarter way, but it is a non-trivial problem. The best solution I could think of:

• In the symbolic manipulations that we do with sympy, treat subexpressions as functions of the variables they depend on (complicated by the fact that they can refer to other subexpressions).
• For the generated code statements, enumerate all the different ways a subexpression is used (e.g. in an RK2 algorithm it might be called once as alpha(v) and once as alpha(v + k/2)) and generate the respective statements (for, say, alpha_1 and alpha_2) and replace the subexpression calls accordingly.

I think this can get quite complicated, but it should be doable. Not sure it is worth the effort, though.

[thesamovar]

Isn't the problem that the end result can be simplified in a way that the subexpressions don't appear any more? If so, maybe a more useful thing to do (but that won't help readability) would be to carry out common subexpression analysis on the final generated abstract code in a similar way to the LIO stuff?

[mstimberg]

We could try common subexpression analysis (at least in some simple way -- using sympy will take too long I think), but I'm a bit worried that we end up with a huge list of newly defined expressions that don't have much of a relation to the original equations (e.g. you don't find anything resembling alpha in it). On the other hand, maybe that's ok and we should think of the subexpressions as something that only helps with the readability of the equations but has nothing to do with the final code? Final question: does it actually buy us much, at least with -Ofast, gcc will most likely eliminate common subexpressions better than we do. Hmm, not sure whether it actually optimizes expressions including function calls (e.g. does it know that exp(x) will always return the same value?). Oh and couldn't our creation of temporary variables make the use of registers impossible in some cases?

Maybe we should do some clearer analysis of the potential benefits before starting such a fundamental change.

[thesamovar]

It's definitely not a high priority. Maybe a good student project at some point?

[mstimberg]

Maybe a good student project at some point?

Good idea, it might be nice for a computer science student since it doesn't need any background in computational neuroscience. I moved the milestone to a vague "2.0", but I don't think it's even essential for the 2.0 release.