-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
"xbins" on Histogram not working Correctly #1978
Comments
Thanks for the detailed report @flyingBurman Problem 1 does look like a bug - it seems to also be related to the uniform data in 2017M06, and I can confirm it in pure javascript. Note that what I would consider the "correct" behavior here is for all zeros to be trimmed from the edges, so the automatic x axis range would be
Problem 2 is a bit trickier. For other modes we recently fixed this issue (#1944) but when you use So with that in mind, what do we do when we see a distribution with no width at all? There's nothing to base our bin width estimate on (which is also why |
Consider these 3 data series, where each of which I want to plot.
"2017M06" : 0.041601, 0.041601, 0.041601, 0.041601
"2017M07" : 0.032993, 0.037393, -0.00078 , 0.0289
"2017M08" : 0.035036, 0.00589 , 0.021899, 0.047374
Please see the following Python code.
This is the result.

For whatever reason, the starting value "-0.2 " is not respected while the ending value "0.1" is respected. So, that is problem 1.
We have another interesting issue issue when I commented out "xbins" parameter.
This is the result.

This is clearly very misleading. The default xbins is messed up where there is no variation in the data. In this particular example, the xbins for "2017M06" is literally 20 times more than the other two series. It can easily be misinterpreted as any value between 0 and 1 is equally likely for 2017M06. This is problem #2.
I attempted to fix it using 'nbinsx" parameter. That does not work as well.
The text was updated successfully, but these errors were encountered: