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
Change LogFormatterExponent to consistently format negative exponents #2691
Change LogFormatterExponent to consistently format negative exponents #2691
Conversation
@@ -50,6 +50,32 @@ def test_LogLocator(): | |||
test_value = np.array([0.5, 1., 2., 4., 8., 16., 32., 64., 128., 256.]) | |||
assert_almost_equal(loc.tick_values(1, 100), test_value) | |||
|
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.
missing blank line here
Except for the pep8 issues, this looks good to me. |
return 1, 10 | ||
|
||
i = np.arange(-3, 4, dtype=float) | ||
expected_result = ['-3', '-2', '-1', '0', '1', '2', '3'] |
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.
It'd be nice to test small negative (and positive values) also.
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.
👍 from me |
@tacaswell & @pelson - Sorry for the delay! I fixed the PEP8 issues and added a few more tests. I also rebased the branch onto the current HEAD. If you'd like I can squash things back down to a single commit, as well. |
Change LogFormatterExponent to consistently format negative exponents
The travis failures are un-related. |
Currently, using
LogFormatterExponent
results in inconsistently formatted labels for values less than one. Integer values greater than one are displayed as integers, while values below one are displayed using scientific notation.For example, the following currently produces an unexpected result:
With this fix, values below one are consistently formatted:
This change does arguably break backwards compatibility, but I think (?) the current behavior is unintentional.