Not sure if it really makes a performance difference, but AFAICStransform() works on numpy arrays. So this could be pulled out of the loop and calculated in one go. Well, except for theAssertionError - when does that occur?

We still have to do the loop, so can probably keep as-is for now.

I think the Assertion Error happened in CI, possibly get_transform returned None for some wacky axis.

Yeah its from the doc build:gallery/scales/custom_scale.py.

Exception occurred:  File "/home/circleci/project/lib/matplotlib/transforms.py", line 1436, in transform    assert not np.ma.is_masked(res)  # just to be on the safe sideAssertionError

The custom scale uses masks, and transforms.transform doesn't like it.

The previous implementation didn't call the transform, but this one does so that we can do the tolerance checking in log-scale rather than data space.

Are we sure that there are still any ticks on that example when we hit this?

I feel like so as to not break downstream users relying on this being exact, the default should bertol=0

@eric-wieser you probably understand the numerical issues better than me, but is this comparison ever "exact"?

Yes, comparison is always exact. The danger is when you make assumptions about rounding in operations prior to the comparison, but that's for the caller to decide.

OK, done...

Cantransform() returnNone? Otherwise we do not need theloct is None check here.

this one says nothing about tolerance

Fixed!

Do you have examples where we needinterval_contains_close and notinterval_contains here? Why couldn't thelocators be in charge of making sure whatever they return is in the interval and adjusting the values if needed (except for those outside the interval needed for classic mode)?

I don't really like the idea of hardcoding the 1e-10 tolerance here when it's something that can clearly(?) be avoided.

Hah, we currently have a 1/2-pixel tolerance! Surely1e-10 * interval is preferable?

The problem with limits is when people compute them.

On my machine:

3.51-1.51 == 2.0FalseIn [17]: abs(3.51-1.51- 2.0) < 1e-10Out[17]: True

I guess it doesn't make things worse, but at least let's keep interval_contains_close private?

The point is that the Locator API should say something like the following to implementers (including 3rd party locators):

You may return tick values inside or outside of the axis bounds, but any value outside of the bounds (with no tolerance) will be dropped (except in "classic" mode, where we will keep the first outside value on either side).

and the locator classes are the one which should do something like

xmin, xmax = ...ticks = ...if xmin - tol < ticks[0] < xmin: ticks[0] = xmin

(or ticks[1] if that's the one corresponding to xmin).
i.e. the locator displaces the tick to match xmin if it's just below xmin.

But I guess that can wait.

The issue with locators is that some uses want the bracketing ticks, unfortunately, for contour for instance... We could fix/change that as well, but beyond this PR.

Agreed it's beyond this PR.
The design above does not preclude bracketing ticks.

@anntzer did you really wantinterval_contains_close to be private? I actually think its useful to take into account floating point slop, but don't feel strongly about it.

yes, it feels like a hack while waiting for locators to be fixed, but I'm not going to insist on it.

Okey doke - done!