hnn-core icon indicating copy to clipboard operation
hnn-core copied to clipboard

plot instantaneous firing rate instead of histogram counts?

Open jasmainak opened this issue 3 years ago • 6 comments

If we divide the histogram counts by the bin width, we can get instantaneous firing rate:

https://jonescompneurolab.github.io/hnn-core/stable/generated/hnn_core.viz.plot_spikes_hist.html#hnn_core.viz.plot_spikes_hist

To me it seems that would be more interpretable, e.g., if there is pathological firing etc. Wdyt @ntolley @rythorpe @cjayb ?

jasmainak avatar Oct 21 '21 10:10 jasmainak

This sounds great to me. In general I think the plotting functions could do with some improvement with respect to interfacing with matplotlib.

What would be great to add is an optional kwargs** that are passed directly to the plot call. It may be tricky in terms of maintaining the look of certain plots, but I think this address issues in the past with respect to colors and axis limits.

ntolley avatar Oct 21 '21 10:10 ntolley

kwargs are a bit hard to document is the general consensus

but let's see what the use cases are. Remember our plotting functions return fig object. Then from that you can get axis handle and from that you can do ax.set_xlim. Stuff like color we can expose explicitly. Very often people want this because they want to create publication quality figures. Maybe we can point them to this MNE tutorial:

https://mne.tools/stable/auto_examples/visualization/publication_figure.html

jasmainak avatar Oct 21 '21 18:10 jasmainak

kwargs are a bit hard to document is the general consensus

but let's see what the use cases are. Remember our plotting functions return fig object. Then from that you can get axis handle and from that you can do ax.set_xlim. Stuff like color we can expose explicitly. Very often people want this because they want to create publication quality figures. Maybe we can point them to this MNE tutorial:

https://mne.tools/stable/auto_examples/visualization/publication_figure.html

Why would we need to document all of the kwargs? Can't we just point to the matplotlib documentation? I'm in favor of establishing access to more plot features at plot instantiation since modifying properties like spectrogram colormap limits, color or line width for specific curves in a plot, or the histogram histtype from the fig object can get very complicated, especially for publication quality figures. Either that or maybe I just need to plan on spending a lot more time sifting through the more advanced components of the matplotlib API and/or stackoverflow :cry:

rythorpe avatar Oct 21 '21 19:10 rythorpe

If we divide the histogram counts by the bin width, we can get instantaneous firing rate:

https://jonescompneurolab.github.io/hnn-core/stable/generated/hnn_core.viz.plot_spikes_hist.html#hnn_core.viz.plot_spikes_hist

I agree with this, however, we'll need to be thoughtful about how we calculate spike rates for drive cells, as the spike rate for an evoked all-to-all drive cell that targets all 270 real cells could either be calculated as 270 spikes/time_bin or 1 spikes/time_bin/target_cell. Conversely, the spike rate for a non-synchronous, cell-specific drive cell that connects 1-to1 with a single real cell can only be calculated as 1 spike/time_bin = 1 spike/time_bin/target_cell.

rythorpe avatar Oct 21 '21 19:10 rythorpe

let's move this discussion to a separate issue as that's tangential to the original issue: plotting histograms in physical units rather than counts.

If you guys can come up with a consistent interface for kwargs that's the same across all plotting functions, I won't object. Please do make sure to research this thoroughly first though. I know this has come up many times in MNE but only a few select places, they are used. Plagiarism is encouraged more than creativity in software engineering ;-)

jasmainak avatar Oct 21 '21 19:10 jasmainak

I agree with this, however, we'll need to be thoughtful about how we calculate spike rates for drive cells, as the spike rate for an evoked all-to-all drive cell that targets all 270 real cells could either be calculated as 270 spikes/time_bin or 1 spikes/time_bin/target_cell. Conversely, the spike rate for a non-synchronous, cell-specific drive cell that connects 1-to1 with a single real cell can only be calculated as 1 spike/time_bin = 1 spike/time_bin/target_cell.

Isn't the firing rate independent of the cells it's connected to? So if we're talking about drive cells it would be 270 spikes / time bin / n_drive_cells. Now if it's non-synchronous, you'd have n_drive_cells = 270 and if it's all-to-all, then you'd have n_drive_cells = 1

jasmainak avatar Oct 21 '21 20:10 jasmainak