TST: account for flakiness with Numpy v1 (part 2)#31442
TST: account for flakiness with Numpy v1 (part 2)#31442jklymak merged 1 commit intomatplotlib:mainfrom
Conversation
timhoffm
left a comment
There was a problem hiding this comment.
Thanks for the rigorous investigation!
|
I assume the failure is that the 10^-2 tick doesn't show up? What is the hypothesized problem with numpy that this is working around? Is it really numpy flakiness, or our tick locator flakiness? I'm somewhat concerned our locator logic should be more robust, rather than count on numpy precision. |
|
I agree that the tick logic could be more robust. However,
Overall, ticket robustness could be evaluated as a follow-up, but I don’t see it as a high priority. |
|
If vmin is 0.1, wouldn't the 10**-2 tick be off the end of the colorbar anyway? |
|
... sorry, whatever the failing tick is |
| im.set_norm(LogNorm(vmin=0.09999, vmax=10)) | ||
| fig.canvas.draw() | ||
| assert (cbar.ax.yaxis.get_ticklabels()[0].get_text() == | ||
| '$\\mathdefault{10^{-2}}$') |
There was a problem hiding this comment.
I assume this is the assertion that fails, and the first tick is 10^{-1} instead of 10^{-2}. The first visible tick is 10^{-1}, so the test is a bit goofy. This basically boils down to our undetermined zeroth tick issue.
I guess this fix is fine here, as we are not testing the ticking, but rather the formatting.,
There was a problem hiding this comment.
Yes exactly. Sorry, I should have pasted or directly linked the error.
PR summary
Following #30950, fix the flaky colorbar test in minver in the same way we fixed the flaky pcolor test before. In my local dev environment with Numpy v2.3, I verified that setting vmin slightly higher (
vmin=0.100001) reproduces the failure.I also ran minver multiple times in parallel on my fork and found
AI Disclosure
None
PR checklist