Thanks to visit codestin.com
Credit goes to github.com

Skip to content

inconsistent colorbar tick labels for LogNorm #12488

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

Closed
anntzer opened this issue Oct 11, 2018 · 5 comments
Closed

inconsistent colorbar tick labels for LogNorm #12488

anntzer opened this issue Oct 11, 2018 · 5 comments
Assignees
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Milestone

Comments

@anntzer
Copy link
Contributor

anntzer commented Oct 11, 2018

Bug report

Bug summary

Code for reproduction

from pylab import *
rcdefaults()
imshow([[10000, 20000]], norm=matplotlib.colors.LogNorm())
colorbar()

Actual outcome

test

Expected outcome

Either both tick labels use a superscript exponent (preferable), or neither does.
Noted while investigating #12473 (comment).

Matplotlib version

  • Matplotlib version: master, present as far back as 2.0.0.
@ImportanceOfBeingErnest
Copy link
Member

I just tested this exact code with

  • mpl 2.0.2 -> issue is not present
  • mpl 2.2.2 -> issue is not present
  • mpl 2.2.3 -> issue is not present
  • mpl 3.0.0 -> issue appears
  • current master (fetched 2 days ago) -> issue appears

@anntzer anntzer added this to the v3.0.x milestone Oct 12, 2018
@anntzer anntzer added the Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. label Oct 12, 2018
@anntzer
Copy link
Contributor Author

anntzer commented Oct 12, 2018

let's mark this as a regression, then...
bisects to #9903 @jklymak :)

@jklymak
Copy link
Member

jklymak commented Oct 12, 2018

Before #9903 colorbar ticks were drawn by hand. After #9903 they should just behave like normal y-axes ticks. So unless we want to revert #9903 and go back to drawing by hand, the error is likely deeper in the code.

@anntzer
Copy link
Contributor Author

anntzer commented Oct 12, 2018

It may well be that #9903 just exposed a bug deeper in the stack, I wouldn't be surprised at all by that :)
No strong opinion as to the best course of action.

@jklymak
Copy link
Member

jklymak commented Oct 12, 2018

Nope, it was a bug in colorbar. My bad.

That code is still somewhat messy. But for 3.0.1 lets just get the bugfix in...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.
Projects
None yet
Development

No branches or pull requests

3 participants