Tolerate floating point precision in multi node tests #110238
Conversation
dnhatn
added
>test
elasticsearchmachine
added
the
Team:Analytics
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
There was a problem hiding this comment.
Could we opt into this behavior with some kind of setting or class override or something? I think sometimes we want to assert that we really get precise decimals when we're running on a single shard just to make sure kahan is plugged in. At least, I think that's true.
Great suggestion. I will update the PR. |
|
@nik9000 Can you take another look? Thank you! |
There was a problem hiding this comment.
Thanks Nhat!
This should close #108560 and the 4 related issues, neat!
|
We discussed this a while ago, and decided we didn't want to do this. See https://github.com/elastic/elasticsearch-internal/pull/1333#issuecomment-1665615734 What's changed? |
|
Not sure if it was clear back then that our test would run against so many different environments. Esp. in multi-node scenarios (Serverless), there's essentially always going to be a small amount of non-determinism. IMHO rounding to 10 decimal places is reasonable to deal with this, esp. since per default (single node tests) rounding is disabled. |
|
@not-napoleon Yes, the difference is in Nik's suggestion to enable rounding conditionally. We disable rounding in single-node tests but enable it in multi-node tests. This allows us to still verify the precision of double values in single-node tests. Moreover, the tolerance used in multi-node tests in the PR is quite small, around 1E-10. |
|
Thanks everyone! |
dnhatn
changed the title
💚 Backport successful
|
Some assertions with floating-point values are failing on serverless because we run tests with three shards with serverless. This can cause variations in precision because data may arrive in different orders. For example, sum([a, b, c]) can yield a different precision than sum([a, c, b]). This change introduces tolerance for precision differences beyond e-10, which should be acceptable for ESQL.
) Some assertions with floating-point values are failing on serverless because we run tests with three shards with serverless. This can cause variations in precision because data may arrive in different orders. For example, sum([a, b, c]) can yield a different precision than sum([a, c, b]). This change introduces tolerance for precision differences beyond e-10, which should be acceptable for ESQL.
Some assertions with floating-point values are failing on serverless because we run tests with three shards with serverless. This can cause variations in precision because data may arrive in different orders. For example, sum([a, b, c]) can yield a different precision than sum([a, c, b]). This change introduces tolerance for precision differences beyond e-10, which should be acceptable for ESQL.