Match lerped values using moreOrLessEquals #64908
Merged
Conversation
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
flutter-dashboard
bot
added
f: cupertino
Member
Author
|
An alternative is that we change some tests to use values with exact floating point representations, such as 0.25, 0.5 or other numbers that can be represented as sums of inverse powers of two, but that feels like a bit of an unfair constraint to place on test authors. Probably better to continue using the values we like, and continue migrating any cases we run into where we're doing exact equality checks on values that have been scaled/etc. that aren't using already using |
cbracken
changed the title
Contributor
|
We normally use "moreOrLessEquals" which abstracts out the epsilon. |
Several of our tests make use of numbers without an exact floating point representation (frequently 0.x where x!=5) which, when scaled, also scale the error. The end result is that some of these tests currently implicitly rely on an implementation detail of floating point math and are sensitive to differences in the ~15th decimal place. This patch reduces the sensitivity of some of these tests, checking values up to the precisionErrorTolerance from the foundation layer rather than requiring en exact match.
Member
Author
|
TIL. Done! Also sent out #64914, which migrates other uses of |
cbracken
changed the title
tvolkert
approved these changes
Aug 31, 2020
mingwandroid
pushed a commit
to mingwandroid/flutter
that referenced
this pull request
Sep 6, 2020
Several of our tests make use of numbers without an exact floating point representation (frequently 0.x where x!=5) which, when scaled, also scale the error. The end result is that some of these tests currently implicitly rely on an implementation detail of floating point math and are sensitive to differences in the ~15th decimal place. This patch reduces the sensitivity of some of these tests, checking values using `moreOrLessEquals` from the flutter_test package rather than requiring en exact match.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
Description
Several of our tests make use of numbers without an exact floating point representation (frequently 0.x where x!=5) which, when scaled, also scale the error. The end result is that some of these tests currently implicitly rely on an implementation detail of floating point math and are sensitive to differences in the ~15th decimal place.
This patch reduces the sensitivity of some of these tests, checking values up to the
precisionErrorTolerancefrom the foundation layer rather than requiring en exact match.Related patches
flutter/engine#20879 fixes a bug in
lerpDoublesuch that when thea,bendpoint parameters differ significantly in value, 0.0 is always returned rather than an intermediate value. As part of that patch, we change the implementation of the calculation to an algebraically-equivalent form which reduces the floating point error, but which produces small differences in the least-significant bits of the double representation, particularly when the arguments in the test have no exact floating-point representation (such as 0.2, 0.3, 0.6, 0.8 in several of these particular tests).