search

mariomulansky / PySpike

Python implementation of spike distance metrics
http://mariomulansky.github.io/PySpike
Other
71 stars 30 forks source link

Where should `t_start` and `t_end` come from when using `merge_spike_trains`? #41

Closed jonathanjouty closed 1 year ago

jonathanjouty commented 5 years ago

I encountered an issue today when using generate_poisson_spikes to create a series of SpikeTrains across distinct intervals, and then merging them using merge_spike_trains.

Currently both t_start and t_end come from the first SpikeTrain supplied to merge_spike_trains:

    return SpikeTrain(merged_spikes, [spike_trains[0].t_start,
                                      spike_trains[0].t_end])

For my present situation t_start should be the minimum t_start from the list of merged SpikeTrains, and similarly t_end the maximum.

Question is, what should the behavior be? Does the minimum/maximum make sense for all use-cases?

EdmundButler commented 1 year ago

The library generally assumes that any collection of Spike objects have the same t_start and t_end. For example the .._distance() functions assert on edge inequality. Edge equality is assured by load_spike_trains_from_text() and generate_poisson_input which have the edges as a required input. There are ways around this. The issue reported is that merge_spike_trains() just assumes that the edges come from the first train to be merged. Even worse, import_spike_trains_from_time_series() generates t_end separately for each train based on the last spike in the train, pretty much assuring that the edges will NOT be the same for every train. Proposed fix: A new function called reconcile_spike_trains() filters a list of Spike objects. On output, t_start and t_end are the same for each Spike, created by min/max of the spike times and input t_start/t_end. In addition, reconcile_spike_trains() can assure the times are sorted and that duplicate spike times are removed.