FIX: fill contourf minimum region when it falls just below the lowest level (#21382)#31903
Open
SharadhNaidu wants to merge 1 commit into
Open
FIX: fill contourf minimum region when it falls just below the lowest level (#21382)#31903SharadhNaidu wants to merge 1 commit into
SharadhNaidu wants to merge 1 commit into
Conversation
… level (matplotlib#21382) contourf left the minimum-valued region unfilled when the data minimum fell a floating-point hair below the lowest contour level instead of being exactly equal to it (e.g. a computed -1.7e-13 where 0 was meant). ContourSet._get_lowers_and_uppers only extended the lowest filled interval down to the minimum when self.zmin == lowers[0] exactly, so such near-equal minima, or rounding during automatic level selection, slipped through and the region was clipped. On a linear scale, compare the level against the data minimum with a tolerance scaled to the data range rather than strict equality, the same way Colorbar._add_solids does. The check is one-sided and tolerance- bounded, so genuine gaps such as user-specified levels starting above the data are left untouched, and every case the old equality test caught still extends identically. Log scales span many decades where an additive tolerance is not meaningful, so the exact-equality test is kept there unchanged. Adds check_figures_equal regression tests that a float-noise minimum renders like a clean zero, including at very small and very large data scales, plus guard tests that a user-specified lowest level above the data is not back-filled, even when a large data range inflates the tolerance to order unity. Includes a behaviour-change note under doc/api/next_api_changes/.
4f525d1 to
d70e9b9
Compare
Member
Please don't do that; we want your description of what you did, and AI's writing is tiring to read. |
Contributor
Author
|
i am really sorry , i will make sure to not use AI for PR description in future , please give me some time , i will update the PR description . |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #21382.
PR summary
When the smallest value in the data sits just a hair below the lowest contour level instead of being exactly equal to it,
contourfends up leaving that region blank. It's an easy one to trip over, because the minimum is often a computed value like-1.7e-13that was really supposed to be0, or autoscaling lands on a lowest level that's slightly off.It all comes down to
ContourSet._get_lowers_and_uppers. The lowest band only gets stretched down to the minimum whenself.zmin == lowers[0]exactly, so anything that's off by a rounding error just slips past and the area gets clipped.So I replaced the exact
==with a tolerance scaled to the data range, but only on linear scales. It's one-sided and bounded, so a real gap (say user-supplied levels that start above the data) is left alone, and anything the old equality check used to catch still behaves exactly the same. Log scales cover way too many orders of magnitude for an additive tolerance to mean anything, so I left the exact check alone there.I used AI to help me understand parts of the codebase in the contour code and in drafting this PR description. The code changes and design decisions were developed independently.
Testing
Added a
check_figures_equaltest that a float-noise minimum draws the same as a clean zero (including at very small and very large data scales), plus guard tests so a user-specified lowest level above the data doesn't get back-filled even when a big data range inflates the tolerance.PR checklist