jonescompneurolab / hnn-core

Simulation and optimization of neural circuits for MEG/EEG source estimates
https://jonescompneurolab.github.io/hnn-core/
BSD 3-Clause "New" or "Revised" License
55 stars 52 forks source link

plot instantaneous firing rate instead of histogram counts? #448

Open jasmainak opened 3 years ago

jasmainak commented 3 years ago

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 ?

ntolley commented 3 years ago

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.

jasmainak commented 3 years ago

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

rythorpe commented 3 years ago

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 commented 3 years ago

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.

jasmainak commented 3 years ago

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 commented 3 years ago

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