Repository navigation
MaxNLocator changes the scientific notation exponent with different number of tick labels #12072
Description
Bug report
Bug summary
MaxNLocator changes the scientific notation with different number of tick labels.
Code for reproduction
I encountered this unexpected behavior when I changed the y-ticklabel size. Going from size 13 to 14 changes the scientific notation from 1e9 to 1e10, and adds an decimal offset to all the ticklabels.
import matplotlib.pyplot as plt
sci_nums = [10**9, 8*10**9]
plt.rcParams['ytick.labelsize'] = 13
fig, ax = plt.subplots()
ax.scatter(range(len(sci_nums)), sci_nums)
plt.rcParams['ytick.labelsize'] = 14
fig, ax = plt.subplots()
ax.scatter(range(len(sci_nums)), sci_nums)
This is related to that the larger font size reduces the number of tickslabels. MaxNLocator apparently adjusts the scientific notation depending on the number of ticklabels.
plt.rcParams['ytick.labelsize'] = 13
fig, ax = plt.subplots()
ax.scatter(range(len(sci_nums)), sci_nums)
import matplotlib.ticker as ticker
ax.yaxis.set_major_locator(ticker.MaxNLocator(4))
I dont' quite understand the rule that MaxNLocator uses. Setting 1, 2, 4 or 5 ticklabels results in 1e10. Setting 3, 6, 7, 8, or 9 ticklabels results in 1e9.
Expected outcome
I would expect that changing the number of ticklabels (either directly or via another parameter such as the font size) would not result in a change in the formatting of the scientific notation. In this case, I would expect it to remain 1e9 for all the examples above.
Matplotlib version
- Operating system:
Linux - Matplotlib version:
2.2.2 - Matplotlib backend (
print(matplotlib.get_backend())):module://ipykernel.pylab.backend_inline - Python version:
3.6.6(conda-forge) - Jupyter version (if applicable):
jupyterlab=0.34.3, jupyter_core=4.4.0 - Other libraries:
Activity
dabana commentedon Sep 10, 2018
The integer keyword in MaxNlocator should do what you want. Have you tried it?
I tried it, for my part it does not seem to work in the example you provided (Matplotlib version: 3.0.0rc1.post186+g5e01393)
Start fixing handling of the *integer* kword in **ticker.MaxNLocator*…
jklymak commentedon Sep 10, 2018
The issue is actually in ScalarFormatter and its interaction with the extra ticks made by MaxNLocator. MaxNLocator(4) actually makes six ticks that are used for the orderOfMagnitude calculation, and the order of magnitiude of that larger span changes when you use 4 ticks instead of 6.
I don't actually think there is any reason to not just set the order of magnitude by visible ticks. Fix on its way...
jklymak commentedon Sep 10, 2018
Cross ref #11004
fix the filtering of non-integer ticks in maxNlocator with *integer =…
dabana commentedon Sep 11, 2018
I am a little concerned by the handling of the integer keyword.
How can we be sure that only integer ticks are displayed if the formatter method axis.major.formatter does not know about the integer keyword provided to the tick locator, in that case maxNLocator?
jklymak commentedon Sep 11, 2018
@dabana the ticks being chosen by the locator are integers in both cases. It’s the formatting of those integers that needs fixing.
dabana commentedon Sep 11, 2018
I guess I am confused with what the integer keyword is supposed to do. I thought all the tick labels would end-up greater than 1 without decimals (like 1, 2, 3 ... or 3, 6, 9, etc...).
By reading the code, I understand than only the tick labels greater than 1 will be integer.
If this is the correct behavior it might be worth rewording the doc_string to make this clear. For exemple:
jklymak commentedon Sep 11, 2018
Integer on the locator will simply make sure the tick locations are integers. You are conflating the scientific notation of the formatter with the job of the locator.
joelostblom commentedon Sep 14, 2018
Thank you for fixing this @jklymak !!