You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rewrite the logic for subsampling log-scale ticks, so that
1) there's as many ticks as possible without going over numticks (don't
draw a single tick when two would fit);
2) the ticks are spaced as much as possible (when two ticks are drawn,
put them on the lowest and highest decade, not somewhere midway);
3) if possible, draw ticks on integer multiples of the stride (0, 3, 9
is better than 1, 4, 7).
See comments in implementation for details.
For the backcompat-oriented "classic-mode", remove the "stride >=
numdec" check (which is a much later addition).
Test changes:
- test_small_range_loglocator was likely previously wrong (the assert
did not cover the values of ticks, and all iterations of the loop
ended up testing the same condition). Rewrite it fully (in particular
to cover the new implementation).
- changes because tick_values() now returns exactly one major ticks
outside of the (vmin, vmax) range on both sides: TestLogLocator,
test_axes::test_auto_numticks_log, test_colorbar::test_colorbar_renorm.
- test_colorbar::test_colorbar_autotickslog's tested tick values didn't
match what actually got drawn, because rendering the colorbar (here
simulated via draw_without_rendering) would make the (first) colorbar
slightly smaller (via _ColorbarAxesLocator) and change the available
tick space. Furthermore, the second colorbar was wrongly drawn with
3 ticks at [-12, 0, +12] when there's only space for 2; this arose
because np.log(1e±12)/np.log(10) = ±11.999... which led to a wrong
stride calculation; the new code explicitly uses log10, which is more
accurate, when possible, and correctly yields ticks at [-12, 12].
- test_contour::test_contourf_log_extension: Log-normed contour
extension remains a bit iffy, because it is implemented by asking a
LogLocator for ticks within data range, and then including an extra
tick below and above (see also the comment regarding _autolev in
LogLocator.tick_values()). This is not really optimal, e.g. that
extra tick can be quite far below or above the actual data limits
(depending on the stride). Perhaps a better solution would be to
just extend the range to the nearest decade, or even just accept that
colorbar ticks (like axes ticks) don't necessarily reach the very
end of the data range but can stop slightly below. In the meantime,
I chose to simply force the contour levels so that the test results
matches the old output.
0 commit comments