You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not super happy with having floating point checks but we have to try to define a set of test cases that function across different languages with different precision capabilities and this is the best we came up with.
If you want to propose an alternative feel free. Otherwise I don't see this as something we need to address.
I did have the macros there as a proposed solution.
When doing a decoding test, we should not require the result to exactly equal the required test case.
Instead we should only require them to be within 0.00000001 of each other. Because on 32-bit systems numbers are considered equivalent if they are that close.
This issue can please stay open. I can contribute PRs. Working on this is blocked on updating the specification. Specifically if we are still supporting 32-bit implementations or only 64-bit. (Those will have slightly different ways to properly do the test case.)
When creating test cases, it is best practice to NOT compare floating point values using an equality check.
Therefore, test cases like these are inappropriate: https://github.com/google/open-location-code/blob/master/test_data/decoding.csv#L26
Or, there should be a lot more documentation (in the test case) to explain why that specific value is expected.
References:
The text was updated successfully, but these errors were encountered: