New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for issue #841 #1331
Fix for issue #841 #1331
Conversation
@@ -8127,7 +8127,7 @@ def hist(self, x, bins=10, range=None, normed=False, weights=None, | |||
|
|||
x[0::2], x[1::2] = bins, bins | |||
|
|||
minimum = min(bins) | |||
minimum = min( min(m) for m in n ) # Issue #841 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just np.min(n)
?
Also, you don't need to refer to the issue it fixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just np.min(n)?
This would work as well, but for a small number of bins (default is 10), the min of mins is faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With such a small loop, performance isn't really a big concern, and readability becomes the leading decision aid. For me the numpy.min
approach provides a certain amount of clarity as to what is being done, where the min( min(m) for m in n )
needs to be read twice to be sure you haven't missed anything.
As minor as it sounds, IMHO numpy.min
would be preferable.
Cheers,
Thanks for putting together a pull request for this. The time you've put in is much appreciated. Cheers. This fixes a pretty annoying bug. Ideally, you should branch off of the v1.2.x branch instead of master. Also, it would be nice to have a test for this. |
Also, with your patch I get different results with Edit: Comparing with v1.2.x |
import pylab as P
P.hist([3000,3010,3012], histtype='step')
assert gca().get_ylim()==(0,1)
import pylab as P
P.hist(P.random_integers(3000,3010, 100), histtype='step', log=True)
P.show() |
Don't worry to much about basing off of |
@mdboom It's a bug fix with a very simple/elegant solution. I'd be happy to see this in 1.2, but if others feel differently then I'm happy to back down. There needs to be a test first, though, I think. @ycopin The test should produce a plot that is incorrect before your fix is applied, but is correct after your fix is applied. This is to demonstrate that: a) your patch works; and b) if something breaks autoscaling for step-type histograms in the future your test will fail and a bug will be easier to find. The Also, take a look at the |
As you said, this PR is really just a very simple bug correction, not a new feature or anything fancy: the original line |
@ycopin A test certainly can't hurt. |
@ycopin Think of it this way. If we had a test that exercised that code, we would have detected this earlier. The test sample you gave above should be sufficient to catch this sort of mistake ever happening again (called a "regression"). Matplotlib has had a very poor test coverage over the years, and we are now trying to turn that around. |
It's time to get this in. The test can wait. I am closing this in favor of an identical change based on v1.2.x. |
Thanks. I'll try to do better next time (not branching from master, include a test). |
@ycopin You can branch from v1.2.x by doing: $ git fetch upstream # get up to date
$ git checkout -b my_fix upstream/v1.2.x # create a new branch called 'my_fix' and make it the current branch |
As I mentioned in Issue #841, there's a bug in hist autoscaling when histtype.startswith('step). An easy test is: