Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[TST] Adjust tests to be more tolerant to floating point math operations being imprecise #25813

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 6, 2023

Conversation

ksunden
Copy link
Member

@ksunden ksunden commented May 4, 2023

PR summary

Closes #25789, see there for detailed discussion of what changed

This is addressing the extremely small (literally Unit of Least Precision, ULP) changes to how numpy computes sin/cos on main.
Through a combination of ratios of small numbers and relying on precise edge case behavior in tests of floats, we saw 3 cases where the miniscule difference compounded to test failures.

Two cases of projections having degenerate points where the edge case is inherently unstable:

  • Mollweide projection is degenerate at the poles, we were lucky that the floating point operations precisely canceled
    • Fixed by just not testing round tripping of the poles, as they shouldn't necessarily round trip
  • Formatting of polar coordinates
    • Polar coordinates are degenerate at r=0, thus we were relying on boundary behavior to get zero decimals of precision
    • Does an absolute difference mod 2 pi, thus the maximum possible is pi, and then divides by pi, thus the only way to get the tested precision was to get exactly np.pi
      • The only place this can actually happen in adjacent pixels is around the origin
    • The method is used for tool tip in interactive plotting, and precisely placing the mouse at 0,0 is unlikely to impossible depending on resolution, etc
    • Fixed by moving the radius out far enough that we are no longer degenerate and have stable expected precision

one case of attempting to do equality checks on processed floats:

  • Round tripping of 3d axis colors with light source at 90 degrees
  • since pi/2 is imprecise (because all floats except sums of powers of two are) there should be some allowance for float precision error
  • The tolerance is still really tight (4 ULPs, or a relative tolerance of ~1e-15)

PR checklist

…ons being imprecise

Two cases of projections having degenerate points where the edge case is inherently unstable, one case of attempting to do equality checks on processed floats
@ksunden
Copy link
Member Author

ksunden commented May 5, 2023

Not sure why azure didn't run here (I was initially hoping that our tk/macos azure image problems were resolved when I saw a green checkmark instead of a red X, but no, no azure at all here...)

@oscargus
Copy link
Member

oscargus commented May 5, 2023

(because all floats except sums of powers of two, the power differing at most 53 are)

@tacaswell tacaswell added this to the v3.7.2 milestone May 5, 2023
@oscargus oscargus merged commit 4bdae2e into matplotlib:main May 6, 2023
meeseeksmachine pushed a commit to meeseeksmachine/matplotlib that referenced this pull request May 6, 2023
…to floating point math operations being imprecise
QuLogic added a commit that referenced this pull request May 6, 2023
…813-on-v3.7.x

Backport PR #25813 on branch v3.7.x ([TST] Adjust tests to be more tolerant to floating point math operations being imprecise)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[TST] Upcoming dependency test failures
3 participants