You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using matplotlib version 1.5.1 on Scientific Linux 6 (RHEL clone). I am using the matplotlib provided in the anaconda install.
I would like to propose that histograms are drawn by default with histtype='step'. I've been using matplotlib for a long time, and it is very common (at least in high energy physics) to plot histograms with a large number of bins, which using the default drawing behavior leads to very unresponsive plots. For example:
produces a histogram which takes ~15 seconds to draw and takes somewhere between 5-10 seconds to redraw after panning or zooming. In contrast, plotting with histtype='step':
I agree that 'step' or 'stepfilled' makes good sense for a histogram. Are there any of our gallery examples or common use cases for which 'step' would work badly? It looks like 'step' is much better as a default than 'stepfilled' because the latter works badly when there is more than one series in the histogram.
Even if the default is not changed, the hist docstring could note the superior speed of 'step'.
mwaskom/seaborn#704 / #4065 is an issue about the default appearance of step histograms when using the seaborn styles, although it could be argued this is not a problem of matplotlib itself.
I'd vote for it to be included in the demo, but against it being the default since the current default is what's shown in just about every basic stats/research methods book and so I think deviating from that would be massively confusing to a lot of people.
@tlatorre-uchicago, please proceed with a PR to add a 'step' hist example ASAP, and consider including a line somewhere in the hist docstring pointing out the superior speed of step when the number of bins is large. At this point in our development cycle, these changes are helpful and safe; changing this particular default now would evidently be controversial and perhaps undesirable to a major fraction of the user community.
Ah, yeah that looks good. I'm not sure what the best course of action is then. I guess there are a couple of options:
just add a note to the docstring (should it be in the Notes section at the bottom or in the main paragraph at the top?)
add a note to one of the existing examples (histogram_demo_features or histogram_demo_histtypes?)
add a new example for "histogramming large datasets" or something
add a warning if bins > 1000 and histtype='bar'
The last option seems a bit hacky from a purist standpoint, but pragmatically that would have alerted me to the problem the quickest.
I'm happy to do any/all of these. I guess the main objective should be to make sure whatever is changed that it's obvious to anyone in the future that plotting histograms in matplotlib is not slow if you use the histtype='step' argument.
I'm having some trouble building the HTML documentation.
I have to run python make.py --allowsphinxerrors because there are a lot of sphinx errors. Is this expected?
After building for a while I get the exception 'ascii' codec can't encode character u'\U0001f603' in position 16: ordinal not in range(128)
The exception comes from line 699 in plot_directive.py: code = textwrap.dedent("\n".join(map(str, content))). I can send the whole traceback if you want.
I believe I have all of the prerequisites. I've followed the instructions in doc/README.txt. Anything else I should know?
I suspect changing the default will not happen (other than with some kind of large backcompat-maintaining PR similar how #25427 does it for contour(), which is definitely doable, just a fair bit of work), and we should just try to add references towards stairs(*histogram()) (which is arguably better, though it certainly doesn't replace all use cases) throughout the docs.
Activity
efiring commentedon Sep 15, 2016
I agree that 'step' or 'stepfilled' makes good sense for a histogram. Are there any of our gallery examples or common use cases for which 'step' would work badly? It looks like 'step' is much better as a default than 'stepfilled' because the latter works badly when there is more than one series in the histogram.
Even if the default is not changed, the hist docstring could note the superior speed of 'step'.
anntzer commentedon Sep 16, 2016
mwaskom/seaborn#704 / #4065 is an issue about the default appearance of step histograms when using the seaborn styles, although it could be argued this is not a problem of matplotlib itself.
story645 commentedon Sep 16, 2016
I'd vote for it to be included in the demo, but against it being the default since the current default is what's shown in just about every basic stats/research methods book and so I think deviating from that would be massively confusing to a lot of people.
efiring commentedon Sep 19, 2016
@tlatorre-uchicago, please proceed with a PR to add a 'step' hist example ASAP, and consider including a line somewhere in the hist docstring pointing out the superior speed of
stepwhen the number of bins is large. At this point in our development cycle, these changes are helpful and safe; changing this particular default now would evidently be controversial and perhaps undesirable to a major fraction of the user community.tlatorre-uchicago commentedon Sep 19, 2016
Sure, can you recommend which histogram example I should edit? The example that pops up on Google when I search for "matplotlib histogram" is http://matplotlib.org/1.2.1/examples/pylab_examples/histogram_demo.html, but that doesn't appear to be in the documentation anymore.
efiring commentedon Sep 19, 2016
The docs are in a state of flux, with a trend toward moving things from the pylab section to more specific sections. The latest version actually includes a step-filled example: http://matplotlib.org/devdocs/examples/statistics/histogram_demo_histtypes.html. Source code: https://github.com/matplotlib/matplotlib/blob/master/examples/statistics/histogram_demo_histtypes.py. Maybe we don't need more than that? Or do you want to add a plain step example?
tacaswell commentedon Sep 19, 2016
@tlatorre-uchicago You might also be interested in http://matplotlib.org/devdocs/examples/api/filled_step.html You will have to call
np.histogramand step/fill_between, but you will get more control +Line2Dobjects.tlatorre-uchicago commentedon Sep 19, 2016
Ah, yeah that looks good. I'm not sure what the best course of action is then. I guess there are a couple of options:
The last option seems a bit hacky from a purist standpoint, but pragmatically that would have alerted me to the problem the quickest.
I'm happy to do any/all of these. I guess the main objective should be to make sure whatever is changed that it's obvious to anyone in the future that plotting histograms in matplotlib is not slow if you use the
histtype='step'argument.tacaswell commentedon Sep 19, 2016
Adding a note to
Notesand extending the histogram_demo_histtypes are probably the best two options.👎 on adding a warning, it assumes too much about user intent.
As a side note, what group are you with at uchicago? I graduated from there a few years ago.
story645 commentedon Sep 20, 2016
I think you can use #7096 as a model.
tlatorre-uchicago commentedon Sep 20, 2016
OK, I'll add a note and update the histtypes demo. I'm in Dr. Blucher's group working on SNO+.
tlatorre-uchicago commentedon Sep 25, 2016
I'm having some trouble building the HTML documentation.
python make.py --allowsphinxerrorsbecause there are a lot of sphinx errors. Is this expected?'ascii' codec can't encode character u'\U0001f603' in position 16: ordinal not in range(128)The exception comes from line 699 in plot_directive.py:
code = textwrap.dedent("\n".join(map(str, content))). I can send the whole traceback if you want.I believe I have all of the prerequisites. I've followed the instructions in doc/README.txt. Anything else I should know?
tacaswell commentedon Sep 25, 2016
Try building the docs with python 3.
There should be no sphinx warnings (which we test for on travis).
9 remaining items
anntzer commentedon May 23, 2023
I suspect changing the default will not happen (other than with some kind of large backcompat-maintaining PR similar how #25427 does it for contour(), which is definitely doable, just a fair bit of work), and we should just try to add references towards
stairs(*histogram())(which is arguably better, though it certainly doesn't replace all use cases) throughout the docs.timhoffm commentedon May 23, 2023
The documentation is updated. I close this (=change the default) as "not planned".