Add structure for aggregated data AggregatedBinnedAlignedSpikes
#16
Conversation
|
I think the aggregated events should be in temporal order, so the timestamps would be in order. Another approach would be to put them in order by condition first and by time second. That ordering would in theory allow you to write code that selects trials of a specific type more efficiently, but in practice such code would be over-engineered anyway and would probably only save milliseconds in practice. |
|
OK, so if we with the first approach we can do two things:
I am leaning to 1 but if you have other consideration that might be escaping me I am all ears. |
| milliseconds_from_event_to_first_bin=milliseconds_from_event_to_first_bin, | ||
| data=data, # Shape (number_of_units, aggregated_events_counts, number_of_bins) | ||
| timestamps=timestamps, # As many timestamps as the second dimension of data | ||
| event_indices=event_indices, # An index indicating which event each of the counts corresponds to |
There was a problem hiding this comment.
Maybe stimulus_id would be better
|
|
||
| The `aggregated_events_counts` represents the total number of repetitions for all the events being aggregated. For example, if data is being aggregated from two stimuli where the first stimulus appeared twice and the second appeared three times, the aggregated_events_counts would be 5. | ||
|
|
||
| The `event_indices` is an indicator vector that should be constructed so that `data[:, event_indices == event_index, :]` corresponds to the binned spike counts around the event with the specified event_index. You can retrieve the same data using the convenience method `aggregated_binned_aligned_spikes.get_data_for_event(event_index)`. |
There was a problem hiding this comment.
Try not to confuse the terms "event" and "stimulus". You have a stimulus index, not an event index.
There was a problem hiding this comment.
Are you thinking that this structure is only for aggregating stimulus? I think that would simplify the language but the other structure in the extension is not only for stimulus but for events, trials, etc.
|
OK. So we discussed in the last meeting that we will focus this on the dicarlo case for binning spikes over multiple stimulus. We will dispose of the need for the two structures. I will merge this and do another PR with the requested changes. |
First draft/ proof of concept of an structure to get aggregated data for many events (i.e. different stimuli or events). This is an idea proposed by @bendichter and I am calling it here
AggregatedBinnedAlignedSpikesI added some tests for the basic constructor and a method for getting data corresponding to a specific event
aggregated_binnned_align_spikes.get_data_for_stimuli(event_index=0)One point that I am still not sure about is how to manage timestamps.
BinnedAlignedSpikeshas a timestamps that stores the times at which the single event for which the data is obtained ocurred.We could use the same index approach that we use for the data here that we use for the timestamps but then either we would have the tiemestamps to be non-monotric or we would need to re-order the data once the user passess it to us. Thinking on how to handle this, so far the structure does not have timestamps.
TO-DO