Ah, about the tests: Not all tests ran succesfully on my machine, but all the ones that fail also do so on main, so I'm confident this is not due to my changes.

Leaving this comment to ping you guys, as it's been more than a week since I opened this PR. :-)

Leaving another ping-comment, as it's been almost six weeks.

Sorry there hasn't been much discussion here. I've put this on the agenda for tomorrow's meeting.

Sorry I meant to comment last week after the meeting, but it seemed to have been left here without going through.

In general, we are in favour of this change. However, we would like to see that it be behind a flag of some sort, either a) an argument to the class init, or b) an rcParam, or c) both. Sometime in the future, it may make sense to flip that flag (which I would be in favour of), but it should be tested out a bit first.

• When computing stride (i.e. the number of decades between major ticks) a possible forced tick at 0 is not considered. This may lead to an off-by-one error regarding numticks (i.e. a stride value smaller by one would have been possible) but I feel like preventing this is not worth the complication of taking it into account. Do you agree?

I think I've seen an issue related to this somewhere and will try to find it.

• subs=None is equivalent to subs='auto' in LogLocator but to subs=(1.0,) in SymmetricalLogLocator. Is that on purpose? I left it like that.

It was probably an artifact of whoever implemented things, but then was refactored to share code and now it seems inconsistent. But now it can't easily change for backwards compatibility reasons.

• For some reason, base came after linthresh in SymmetricalLogLocator's signature, contrary to most other occurences. In adding linscale I reordered those. While this is strictly a backwards incompatible change (whereas I just appended linscale everywhere else), I don't expect it to have ever been used in an incompatible way: providing base only make sense when transform (the first argument) is not given, so it's most probably always been don by keyword argument, though it is in principle possible to say SymmetricalLogLocator(None, None, 2, 10) to get SymmetricalLogLocator(linthresh=2, base=10). Should I switch it back for backwards compatibility or do we care more about consistent argument order?

Unfortunately we do, so it will have to be reverted. In some cases, we might want to start making arguments keyword-only, but that does require going through a deprecation cycle.

• LogFormatter threw away the sign of any value, even though it is used for negative values with symlog axes. This was no problem because LogFormatterMathtext overwrites __call__ and preserves the sign, so it didn't actually show up on any axis (with the default configuration). I fixed this. Is it fine to just leave it in this PR or should it be a separate one?

It's probably fine here, but if you have some easy way to show that difference outside of the other changes, it might be quicker for review as a separate PR.

• In test_ticker.py the test TestSymmetricalLogLocator.test_extending() relies on rcParams['axes.autolimit_mode'] being set to round_numbers but this is not set up in the test itself. I assume that this configuration is left in place by some previous test, though I can't tell where. Is this by design or should an rc_context be used, like in some other tests?

This is set by the classic style, which is the default for all tests, though new tests should start using mpl20 and in that case you would need to set the rcParam yourself. There's not really a need for rc_context unless you are mixing more than one call in a test, as all rcParams are reset before each test.

• The checklist below tells me to note API changes (which the new linscale argument to the locator and the formatter as well as the changed default value of SymmetricalLogScale's subs argument qualify as, I think) with a directive and release note, but the linked section does not seem to exist. What do I need to do?

I think this might have moved here. @story645 I guess we need to update the pull request template for some of the recent refactors?

The checklist below tells me to note API changes (which the new linscale argument to the locator and the formatter as well as the changed default value of SymmetricalLogScale's subs argument qualify as, I think) with a directive and release note, but the linked section does not seem to exist. What do I need to do?

is something like this clearer?

if not or you have a suggestion, please let me know at #27641

Thanks for your comments! I think I have everything to make final adjustments now. I'm quite busy at the moment, but I will try and get that done soon.

Does this also close #10369?

Hi @schtandard , are you interested in finishing this up? If you need help, let us know. Cheers!

Hi @melissawm, thanks for the ping and sorry for the long delay; a stressfull period of my life dragged on longer than I had expected. It finally concluded last month, though, so I hope I'll now be able to wrap this up. In fact, I already took a quick look recently to see what's left to do. I'll have another crack and try to incorporate all the things mentioned above, hopefully without as much delay this time.

Alright, I gave it another go. The tick placement for log axes had changed since I first tackled this, so I basically re-wrote the symlog stuff to match. I re-named the old branch to symlog_ticks_old, in case you want to have a look, though I don't think it is of interest anymore. Some notes:

• As requested, I hid the new behavior behind a new rcParam axes.formatter.legacy_symlog_ticker. I was a bit unsure about the name and category. Let me know if I should rename it.
• SymmetricLogScale() now has the default value subs='auto'.
  • With the previous default subs=None there are no minor ticks, which is bad.
  • Note that SymmetricalLogLocator interprets subs=None as "no minor ticks" while LogLocator treats it as subs='auto'. The latter is for "consistency with previous bad API" according to a comment in the code.
  • So, while this is not quite backward-compatible, I think it's the cleanest way to go. What do you think?
• Also, SymmetricLogScale() now does not suppress minor tick labels. This I could hide behind the new rcParam if you want.
• I thought about having _SymmetricalLogUtil.firstdec() cache its result, as it is needed quite a bit. However, I was now unsure if the efficiency is worth the added code complexity. What do you think?

No documentation changes or release notes are included, yet. Once the API is set, I will have a look at what's necessary there.

This is how it looks.

And here is the "legacy" version.

For comparison, this is how it used to look (identical to legacy version).

import numpy as np
import matplotlib as mpl
from matplotlib import pyplot as plt

mpl.rcParams['axes.formatter.legacy_symlog_ticker'] = False

def showcase_scales(axs, *plotargs, **plotkwargs):
    for ax, scale in zip(axs, ['linear', 'symlog', 'log']):
        ax.set_yscale(scale)
        ax.yaxis.grid()
        ax.plot(*plotargs, **plotkwargs)

values = [
    np.linspace(3, 150),
    np.linspace(20, 60),
    np.linspace(0.5, 12),
    np.linspace(0.5, 5),
    np.linspace(0.6, 3),
    np.linspace(1e-4, 1e-2),
    np.linspace(0, 40),
    np.linspace(-0.8, 0.9),
    np.linspace(-4, 4),
    np.linspace(-22, 22),
    np.linspace(0, 0),
    np.linspace(1, 1),
    np.linspace(2, 2),
    np.linspace(10, 10),
    np.linspace(13, 13),
]
fig, axs = plt.subplots(len(values), 3, squeeze=False, sharex=True,
                        figsize=(9, 2 * len(values)))
for a, v in zip(axs, values):
    showcase_scales(a, v)
axs[0, 0].set_title('linear')
axs[0, 1].set_title('symlog')
axs[0, 2].set_title('log')
fig.savefig('showcase.png', bbox_inches='tight')

I would like to discuss whether we need a flag and the legacy behavior. Do we make / want to make guarantees on tick placement? Does anybody depend on reproducible exact positioning of ticks?

#29698 has been merged as a strict improvement without the ability to keep the old behavior. We should consider doing the same here (and probably mention this change here in the #29698 what's new message).

I would like to discuss whether we need a flag and the legacy behavior.

I'm not sure that I am meant to participate in this discussion, but since there have been no comments so far, let me note that I agree that this could be merged as a strict improvement much like #29698. Removing the relevant class parameters and rcParam is easy and would simplify the code a bit.

@QuLogic has your reasoning from back in the day changed or do you still see reasons to hide the change behind a flag for now?

That was the conclusion from the meeting; I do not recall the discussion at the time for why, and unfortunately the meeting notes do not have any detail.

I'll note that @timhoffm was not in that meeting; perhaps we should re-discuss this at the next meeting?

Sure, we can discuss. I’ll put my opinion in already here.

So far we have done several changes to ticks without backs compatibility options, e.g. #29698, #29054, #18754, #13069 (and possibly more).

We haven’t seen any complaints on these improvements/fixes of tick positions so likely nobody relies on them (or they can cope with changes). Therefore, flags just for the sake of keeping old behavior in tick locations seem like unnecessary complexity.