Is this the same as #20950 ?

Is this the same as #20950 ?

Nope, that's a PR to do with contouring, not with the locator itself.

I took a quick look at this, but I can't really tell from the description or tests what has changed and if it is truly an improvement or not. len(ticks) < numticks is the only test of the numticks that I can see, and that doesn't seem a very strict criteria. I'm also leery of the "improves numerical issues when vmin and vmax are on a decade". That should always work, even if it means adding an epsilon to what is shown.

len(ticks) < numticks is the only test of the numticks that I can see, and that doesn't seem a very strict criteria.

This isn't strict, but is what is promised in the docstring, and this PR fixes the locator to honour that promise.

I'm also leery of the "improves numerical issues when vmin and vmax are on a decade". That should always work, even if it means adding an epsilon to what is shown.

I've added some extra tests to check that it works for different bases, and removed that comment.

I've added an API change note. The tradeoff here is
Fixed bugs

• maxticks is respected
• The ticks on a log-scaled errorbar plot are now correct - see the third test image change.

Behaviour change

• In some cases (two of our test cases that use log scales, see 1st/2nd test image change) an extra tick is added to a log-axis, but there is still plenty of room to display the tick values so (beyond being a change) this isn't an issue.

I guess the image changes are my point though; many of them have twice as many ticks as before, and it is not clear to me why that is "right" or desirable...

I don't think any have as much as twice as many ticks - maybe I missed something though? In some cases the stride increases by 1, but the test image changes show that this is a reasonable change as the ticks still fit comfortably along the Axis.

The last axes in the last image test is what particularly jumps out at me as suddenly having a lot more ticks. Maybe its fine though?

You mean the one where minor ticks are now drawn? I think that's a bug fix - there's nothing in the tests that requests minor ticks not to be drawn, and I think it looks better for them being there.

They aren't drawn on master because the major ticks are 2 decades apart. With this change they are one decade apart.

This needs a rebase...

Does anyone else have opinions about whether this is the correct algorithm or not? Its a breaking change, but certainly numticks should be better respected for log scales!

Thanks - I'll wait on a third opinion before rebasing.

We talked about this on the call and have a couple of quetions:

• do we have a case where we actually return more ticks than we promise (at the "will be shown" level)
• can we get away with being clearer in the docstring about what numticks means (because major ticks can only go on decades this ends up being way over-constrained)
• We were not convinced that two of the images that got more ticks actually looked better, but this may just be an issue of moving across a hard edge (how many decades the major tick steps are) and there is no way around putting the jump someplace. Is it possible to tweak that logic a bit to make it earlier again?

I've marked this as orphaned as I don't have the time/bandwidth to work more on this at the moment - if someone else wants to pick it up feel free.

I've put a large chunk of this in #24436, which is clearer and easier to review, so closing this.