Add the EIF_cond_alpha_isfa_ista PyNN neuron type
DanielZim opened this issue · comments
Add the support for the exponential integrate and fire neuron with spike triggered and sub-threshold adaptation currents (isfa, ista reps.) Please, find more information in the PyNN documenation here: http://neuralensemble.org/docs/PyNN/reference/neuronmodels.html#pyNN.standardmodels.cells.EIF_cond_alpha_isfa_ista
The general consensus among the team on this at the moment is that the lack of floating-point in hardware on SpiNNaker is an issue here, particularly when the exponential term increases, due to inaccuracies in the fixed-point implementation. If you have a particular use case for particular parameters of this model then we may be able to investigate using lookup tables etc., but this is a difficult model to correctly implement using fixed-point and as such we may not look at it properly until SpiNNaker-2 comes along.
@dr-david-lester and @hopper333 may have some more thoughts on this so I'm tagging them here in case they want to say anything.
Just to confirm what @andrewgait has already said above, both the fixed-point arithmetic that we currently use and an appropriately accurate/efficient ODE solver algorithm are challenges at the moment for EIF if we want to get anywhere near real time. It is on the radar though and both issues are being considered. It is likely that an EIF implementation with some parameters hard-coded would allow faster progress.
just to ask what could be a stupid question. but why are we not just considering using the software floating point? robert proved that it can be used to great effect and work from myself and @Christian-B have shown it to be debuggable these days with his flogger. so ....... why cant we just plonk a software floating point version and see how far it goes? it doesnt need to be real time limited.
variable timestep - is the main challenge................. remind me for my own stupidity. this variable timestep isnt the request for cores with different time steps within a pynn sim? coz if it is, ive got code that allows you to do that these days. its about to be cherry picked out of my version of roberts code for a speciifc pr...... so would that help this?
could timer 2 be used for this?
sounds like something where im out of my depth to understand without being face to face. as my mental image of the solver with time steps would be to use the timer to eventify the solving. so switching time step scope would mean just resetting the timer to a smaller period.... but it seems that's not what you mean. so im at a loss to understand the problem properly.
maybe some psuedo code with ** THIS BIT IS NOT EASY** would help. but then, it might just confuse me more. so maybe we leave this till we're face to face and if it ever becomes inportant to actually do this.
Our general requirement to move forward with this at all is for someone to exhibit (source for) a SpiNNaker binary that implements the model. Getting that model to fit onto a SpiNNaker core will be the first challenge (even if it only supports particular synapse types and so on), ensuring that the model is sufficiently numerically accurate will be the second challenge, and making that model run within our time guarantees will be the third challenge; those are definitely the order to tackle them too.
Until such a model implementation exists, there's no way that the software team will move on integrating it to make it usable! (OK, the easy bits of it can be done with what already exists for custom models. The hard integration parts would be figuring out what is missing from our tools to make this easier going forward, but we can't do that in a vacuum.)
This issue may be reopened once such a prototype model exists.