Add spike-train based lazy SortingGenerator #2227
Conversation
| refractory_period_ms: float | np.ndarray = 4.0, # in ms | ||
| seed: Optional[int] = None, | ||
| ): | ||
| unit_ids = np.arange(num_units) |
There was a problem hiding this comment.
Will we have a docstring for this? For example you have durations as a list of 2 floats for 2 segments, so for future users it might be beneficial for them to know that the len(durations)==n_segments. And what are the implications of giving one firing rate vs an array of firing rates if I as a user try something like this?
There was a problem hiding this comment.
Yeah, we should. The duration thing is a very pervasive in a bunch of functions we should document it. Less pevasive but not exclusive to this one is the firing rates as an array or float.
There was a problem hiding this comment.
@h-mayorquin can you add a docstring here? Maybe explaining the difference with the generate_sorting
There was a problem hiding this comment.
I also corrected a typo of refactory to refractory
alejoe91
changed the title
|
Hey guys @alejoe91 @samuelgarcia . I want to do some performance testing and I would like to compare dictionary vs the numpy approach. What do we need to move this forward? |
|
@h-mayorquin this is ok to merge for me!! It would be great for perfomrmance testing :) |
|
Thank you Ramon, every thing is perfect except a very small detail. |
Co-authored-by: Garcia Samuel <[email protected]>
While discussing in #2175 and #2209 and the other PR that is now I realized that we don't have a way of tesing lazy recorders performance.
Currently,
generate_sortingalredy pre-loads the data as a numpy array which means that we can't test how performancer or other IO operations would behave in different scenarios.This PR aims to fix that by introduces a new sorter that generates spikes on the fly in a reproducible way. Plus, it behaves consistency across calls and by slicing across spikes.
The max memory it should use is the complete size of its longest spike train.