-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Add an error margin when comparing floats. #129721
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
gmarouli
merged 6 commits into
elastic:main
from
gmarouli:test-fix/add-error-margin-for-float-equality
Jun 23, 2025
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
4670b5b
Add an error margin when comparing floats.
gmarouli b1ae833
Merge branch 'main' into test-fix/add-error-margin-for-float-equality
gmarouli f790ff5
Align implementation with method name
gmarouli bba2f47
Merge branch 'main' into test-fix/add-error-margin-for-float-equality
gmarouli 238e422
Add comment to explain the normalisation choices
gmarouli 458d665
Merge branch 'main' into test-fix/add-error-margin-for-float-equality
gmarouli File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of these checks are on the normalized lists, which have null values removed. This means if there's an extra null somewhere, or if the null is in a different position between the expected and actual, we wouldn't catch it here. Not sure if this is intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct @jordan-powers , it's not exactly intentional, more preserving existing behaviour.
I have been contemplating about it. The check before was less strict, it only checked for the unique values to be the same, no order, no null, no duplicates. I thought we need to make it stricter at least by checking the order and the values. I wasn't sure about the nulls, mainly, to avoid tripping an NPE, somewhere else.
On the other hand, I guess since we made it stricter, we could take it "all the way".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more update, while snooping a little bit more around the code I found this:
elasticsearch/test/framework/src/main/java/org/elasticsearch/datageneration/matchers/source/SourceTransforms.java
Lines 55 to 62 in 5e2b199
It appears that this was intentional. But if I am not mistaken, it doesn't hold anymore, we do preserve order now, right @martijnvg ?
If that is correct, I will open a follow up PR where I address this in all both places and not only when checking doubles. Otherwise, I will revert back to the original so they are in sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed offline, indeed this is not the case anymore. But considering the scope of this PR we do not want to expand to the other normalisers. This can be changed in follow up work.
We chose to keep the non-null values in the given order for the double normalisation because this helps the float comparison with the error margin.