Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Have added a fast method to re-compute correlograms when units are merged.
When two units are merged, their correlograms with other units become the sum of the previous correlograms. Let$C_{i,j}$ be the cross-correlogram of units $i$ and $j$ . If we merge units 2, 4 and 6 into a new unit 10, the cross-correlograms of unit 10 with unit 1 would be:
Similarly, the auto-correlogram of the new unit 10 is
You can implement this with two matrix operations (sum all merged-unit columns together, then sum all merged-unit rows together), which I've implemented.
The most annoying thing is tracking the
new_unit_index
, and there's more code which deals with this than the actual new algorithm. It's much easier to deal with thetake_first
new_id_strategy than theappend
one. Any advice here is welcome.If you don't believe my maths, I've added tests to show that the results are the same if you use the fast merging method or if we merge, then re-compute the correlograms. If you can think of more painful tests than I've written, let me know!
This is a big speedup for my kilosort'd NP2.0 sortings (on my laptop, 25s -> 0.2s for a single pairwise merge). And yup, I do have numba installed.
It only becomes a lot faster for generated recordings when the correlograms become a bit more full. This requires a high firing rate and small refractory period. Here's some benchmarking code:
and I get:
giving the following plot