Skip to content

Conversation

@ecobost
Copy link
Contributor

@ecobost ecobost commented Jan 19, 2026

Fixes #4320.

Instead of receiving spike_retriever_kwargs (which was not used anyway), receive peak_sign (mirroring ComputeSpikeAmplitudes). Previous default behavior and capabilities will not change (as peak_sign was the only parameter actually used from spike_retriever_kwargs).

Code will change from

analyzer.compute('spike_locations', spike_retriver_kwargs={'peak_sign': 'both'}) # previous version
analyzer.compute('spike_locations', peak_sign='both') # new version

@ecobost
Copy link
Contributor Author

ecobost commented Jan 19, 2026

Forgot to change references to spike_retriever_kwargs in other code/docs/test.

I found there is only one place where it was used:

if not self.channel_from_template:
self.params["spike_retriver_kwargs"] = {"channel_from_template": False}
else:
## TODO

As said in #4320, this didn't actually have any effect (cause spike_retriever_kwargs was not passed to SpikeRetriever()), so I commented this code out.I think spike_locations.py is cleaner/easier-to-understand receiving only peak_sign as argument but if you think the use case in benchmark_peak_localization.py warrants the extra complexity, let me know and I'll revert the changes (and make sure spike_retriever_kwargs is forwarded to the SpikeRetriever).

@alejoe91 alejoe91 added the postprocessing Related to postprocessing module label Jan 20, 2026
Comment on lines -27 to -31
if not self.channel_from_template:
self.params["spike_retriver_kwargs"] = {"channel_from_template": False}
else:
## TODO
pass
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was very important for our benchmark. Lets keep it!
We need the peak channel to be estimated for each peak to take in account the variability.
@yger

@samuelgarcia
Copy link
Member

Thank you for this.

We need to be ver very carfull when changing parameters in extension because then when we reload an old analyzer from disck from previous version this will lead to bugs because the params are inconsistent.

In case we change parameters we need to ensure a backward compatibitility using th _handle_backward_compatibility_on_load() method. Also we try to change to often parameters in extension as less as we can for this reason.

In this particular I think we should keep the previous signature with no change and only ensure that this parameters is propagated correctly.

What do you think ?

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

Labels

postprocessing Related to postprocessing module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Argument spike_retriver_kwargs (sic) is not sent to the SpikeRetriever in ComputeSpikeLocations.

3 participants