search

brian-team / brian2tools

Tools to use with Brian 2, in particular for visualization
https://brian2tools.readthedocs.io
Other
14 stars 12 forks source link

[MRG] Add basic plotting tools #2

Closed mstimberg closed 8 years ago

mstimberg commented 8 years ago

This is not ready to merge yet, it lacks testing and documentation (and to run it you currently need brian2 from the morphology_revisited branch), but I'd be happy to get some feedback on the overall approach. The idea is that we have some basic plotting functions, e.g. plot_raster for a raster plot that is a tiny bit more convenient than doing the plot yourself (it adds axis labels, for example). We won't invest much more work into them, you can customize them yourself by adding additional arguments for plot, e.g. by doing

plot_raster(mon.t, mon.i, marker=',')

and/or by changing the returned Axes object:

ax = plot_raster(mon.t, mon.i)
ax.set_xlabel('time in milliseconds')

There are plotting functions for state variables and firing rates as well, even though they are equally trivial as plot_raster. More interesting are the plotting functions for morphologies, this is non-trivial to do and needs some knowledge of the internal structure. The current functions work but are still pretty basic, in the future we can add more features like showing variables such as the membrane potential in colour on the morphology.

A syntax idea that I find kind of neat (feedback welcome): I added a brian_plot function that takes a Brian object, e.g. a monitor, and plots it in a reasonable way (e.g. it will call plot_raster for a SpikeMonitor). This is not something that you'd do for a publication-quality plot, but it can be handy for simple scripts or interactive use (in the long run, it would be nice to integrate this with ipython, so that in a notebook you could just write the name of the monitor and it would display the plot, i.e. use the "rich representation" system).

Other kind of plots that we could add in the same framework are connectivity/weight matrices for synapses.

If everyone is happy with this approach in general, I'll clean it up and do the tests and documentation.

A minor detail: I used the Brian 1 convention and added newfigure and showplot keyword arguments -- shouldn't this rather be new_figure and show_plot? And are newfigure=False, showplot=True the best defaults?

thesamovar commented 8 years ago

I'd say let's make a break from Brian 1 in this case, as the plotting functions in that were not very well designed. In particular, the newfigure and showplot arguments I think are pretty pointless and we could happily get rid of them.

A lot of people are moving away from matplotlib to other plotting libraries (although personally from a quick look I don't think they're good enough for publication ready figures yet). Do we want to build in the possibility of changing the backend in the future? There are several options here. We could have a backend option like matplotlib does for the actual graphical output (nice for the user but a lot of work to maintain). Or, we could have plotting functions somehow include the name of the plotting library (e.g. mpl_plot_raster - I think this is the least nice option). Or, we could provide some intermediate functions that can be used to plot objects nicely but don't actually plot them (not sure how useful this would be). Or we can just ignore all that and do plotting only in matplotlib and reconsider in the future?

I love the idea of brian_plot! I think we should definitely do that, and having it generate nice rich representations for the notebook would be great.

mstimberg commented 8 years ago

In particular, the newfigure and showplot arguments I think are pretty pointless and we could happily get rid of them.

Ok, I'm fine with that. It is much less of a question in interactive use with ipython/ipython notebook anyway and for scripts, adding the extra figure() or show() does not change much.

Or we can just ignore all that and do plotting only in matplotlib and reconsider in the future?

I think matplotlib is good enough for now and it will not be that difficult to change in the future, I think. In the long run, there could be a global "backend" preference and/or a keyword argument for each plot_raster, etc. This would then delegate to, say, mpl_plot_raster or bokeh_plot_raster. I think this is all we need for most plotting functions, because there is basically no plotting-independent logic. It's a bit different for the morphology stuff, there some refactoring might be useful. Still, I think we are not constraining ourselves in any way with the current syntax.

I love the idea of brian_plot! I think we should definitely do that, and having it generate nice rich representations for the notebook would be great.

Ok, great, will do that then. The nice thing is that we can register the representations from brian2tools, so we don't need any weird "try import brian2tools" code in Brian 2 itself.

mstimberg commented 8 years ago

Ok, this is ready to merge from my side now. I did not yet bother with the rich representations for ipython, but I think this can go into a new PR. This PR is already quite big (mostly because of all the infrastructure changes that I had to do at the same time to get the documentation and the tests up and running).

It has some very basic tests (just testing that the plot functions do not throw an error), I don't think we want to do pixel-perfect reproduction of earlier plots so "proper" testing will be a bit complicated (it would involve mocking the actual plotting functions and so on). I think for now this is good enough, though.

I enable the documentation for this branch on readthedocs to check whether everything is working correctly. The reference documentation is not perfect (instead of the custom script we use in Brian 2, this is now all automatic using standard tools), but in general it looks good I think: http://brian2tools.readthedocs.org/en/basic_plotting_tools/

I think after merging this, adding the ipython support and some general work around the packaging (writing some package description, adding release scripts, etc.) should be enough to do a 0.1 release. What do you think?

romainbrette commented 8 years ago

I just had a very quick look at the docs, and it looks really cool!

Le 21/04/2016 19:03, Marcel Stimberg a écrit :

Ok, this is ready to merge from my side now. I did not yet bother with the rich representations for ipython, but I think this can go into a new PR. This PR is already quite big (mostly because of all the infrastructure changes that I had to do at the same time to get the documentation and the tests up and running).

It has some very basic tests (just testing that the plot functions do not throw an error), I don't think we want to do pixel-perfect reproduction of earlier plots so "proper" testing will be a bit complicated (it would involve mocking the actual plotting functions and so on). I think for now this is good enough, though.

I enable the documentation for this branch on readthedocs to check whether everything is working correctly. The reference documentation is not perfect (instead of the custom script we use in Brian 2, this is now all automatic using standard tools), but in general it looks good I think: http://brian2tools.readthedocs.org/en/basic_plotting_tools/

I think after merging this, adding the ipython support and some general work around the packaging (writing some package description, adding release scripts, etc.) should be enough to do a 0.1 release. What do you think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/brian-team/brian2tools/pull/2#issuecomment-213018076

Twitter: https://twitter.com/RomainBrette Blog: http://romainbrette.fr/category/blog/

New paper: Brette R (2015). Philosophy of the spike: rate-based vs. spike-based theories of the brain. Front. Syst. Neurosci. | doi: 10.3389/fnsys.2015.00151

thesamovar commented 8 years ago

Indeed - looks fantastic! I'll just go ahead and merge.