New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linear `event-driven` variables sometimes cannot be integrated #801

Closed
mstimberg opened this Issue Jan 19, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@mstimberg
Member

mstimberg commented Jan 19, 2017

As reported on the mailing list, exact integration for synaptic event-driven variables sometimes fails. We integrate such equations with the independent state updater which uses sympy's dsolve method which itself has a variety of methods available. In the reported case, sympy uses the solver called separate which rarely (subtle changes in the equations can make all the difference) returns an implicit solution which leads Brian to fail with an error message.

I also realized that our linear solver is much faster than independent (which uses sympy's general dsolve method). For the kind of equations that we use in synapses (e.g. the dApre/dt = -Apre/taupre of STDP) this actually makes a difference of ~25ms vs. ~140ms.

So my proposal is:

  • for event-driven equations, use linear instead of independent
  • if the former fails, re-try using independent

This should make things both more stable/predictive and faster in the majority of use cases. It slows things down ever so-slightly for event-driven variables that are non-linear but can still be solved analytically (say, 'dApre/dt = -Apre*sin(t) / tau). This slow-down should be really minor, though (figuring out that the equation is not linear is fairly quick) and I don't know of any real-world use-case for that, anyway...

I'll open a PR for that change soon.

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Jan 19, 2017

Member

Is there a case for just using linear and not trying independent?

Member

thesamovar commented Jan 19, 2017

Is there a case for just using linear and not trying independent?

@mstimberg

This comment has been minimized.

Show comment
Hide comment
@mstimberg

mstimberg Jan 19, 2017

Member

Is there a case for just using linear and not trying independent?

I considered it, but there is the faint possibility that this would break someone's code, with no straightforward way to do something about it (i.e. it is not just a matter of adding a keyword or something like that). I don't see much that we'd gain from it in this specific case, but in the long run we might consider throwing out the independent updater completely, just to remove code that is most likely never used (the independent updater is never chosen for the user automatically, so I doubt many users know that it exists...).

Member

mstimberg commented Jan 19, 2017

Is there a case for just using linear and not trying independent?

I considered it, but there is the faint possibility that this would break someone's code, with no straightforward way to do something about it (i.e. it is not just a matter of adding a keyword or something like that). I don't see much that we'd gain from it in this specific case, but in the long run we might consider throwing out the independent updater completely, just to remove code that is most likely never used (the independent updater is never chosen for the user automatically, so I doubt many users know that it exists...).

@thesamovar

This comment has been minimized.

Show comment
Hide comment
@thesamovar

thesamovar Jan 19, 2017

Member

Sounds reasonable to me.

Member

thesamovar commented Jan 19, 2017

Sounds reasonable to me.

@mstimberg mstimberg closed this in 7b75cac Jan 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment