mstimberg
commented
8 years ago At the moment, we have the situation that the exact linear integration method can output wrong results (see #626). In that case, it will output all nans so you know there is a problem. Is there a possibility that it can output finite values that are wrong? If so, that's a situation we need to fairly urgently address.
I don't think it can give finite values that are wrong. The equation it produces are correct, the only problem is that it involves complex algebra (e.g. square roots of negative numbers) which will not work.
One option would be to reduce the scope of exact integration rather than using sympy's solver. This will mean some equations which have exact solutions wouldn't get found, but it would remove the possibility of a catastrophic failure. I think this would be worth it. We could also have a new method choice (in addition to 'linear' which would use the more conservative/safe strategy) which forces the use of sympy's solver (e.g. method='sympy').
Even if it does not give us incorrect results, I do agree to some extent that replacing the general solver by something more restricted might be a good idea. I've come across equations where it takes literally hours to compute the solution, and given that we always try it if the user does not specify the integration method manually, this can be a problem. I don't know what a good restriction would be that is itself straightforward to check, but I could for example imagine to by default only use it for equations with a single variable. This would still cover simple integrate and fire models, on the other hand it would not work anymore for anything involving synaptic currents...
We could have completely separate state updaters (something like linear and linear_full, or sympy has you suggested -- even though I would probably rather not use the name of the library, we are using it in any case. Maybe something like analytic), or handle this via an extra argument for the integrator (#481). Somewhat related, some problematic cases will be simpler if we freeze constants, which would also be specified by such an option.
thesamovar
At the moment, we have the situation that the exact linear integration method can output wrong results (see #626). In that case, it will output all nans so you know there is a problem. Is there a possibility that it can output finite values that are wrong? If so, that's a situation we need to fairly urgently address.
One option would be to reduce the scope of exact integration rather than using sympy's solver. This will mean some equations which have exact solutions wouldn't get found, but it would remove the possibility of a catastrophic failure. I think this would be worth it. We could also have a new method choice (in addition to 'linear' which would use the more conservative/safe strategy) which forces the use of sympy's solver (e.g.
method='sympy').A related idea which may or may not be feasible, would be to get the assumptions necessary to make the exact formula work. For example, in #626 that would be that the discriminant expression is positive (because we square root it). Is there any way to get sympy to tell us this? Or to infer it safely? If not using sympy, perhaps we could do this in our own routine? With that in place, we could check at runtime if the conditions hold. That would be straightforward for shared constants, but trickier if the conditions involved variables that can change during runtime or for individual neurons (i.e. parameters).
I think the assumptions idea isn't necessary if we can be sure that our choice of integrator won't give incorrect finite values, only nans, because if it always gives nans when there is a problem then #554 will tell the user there is a problem.