Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Improve DoubleNearPredFormat output on bad epsilons DoubleNearPredFormat will happily accept epsilon values (abs_error) that are so small that they are meaningless. This turns EXPECT_NEAR into a complicated and non-obvious version of EXPECT_EQ. This change modifies DoubleNearPredFormat) so that when there is a failure it calculates the smallest meaningful epsilon value, given the input values, and then prints a message which explains what happened. If a true equality test is wanted either pass a literal 0.0 as abs_error or use EXPECT_EQ. If a check for being almost equal is wanted consider using EXPECT_DOUBLE_EQ which, contrary to its name, verifies that the two numbers are *almost* equal (within four ULPs). With this change the flaky test mentioned in crbug.com/786046 gives this output: The difference between 4.2934311416234112e+18 and 4.2934311416234107e+18 is 512, where 4.2934311416234112e+18 evaluates to 4.2934311416234112e+18, 4.2934311416234107e+18 evaluates to 4.2934311416234107e+18. The abs_error parameter 1.0 evaluates to 1 which is smaller than the minimum distance between doubles for numbers of this magnitude which is 512, thus making this EXPECT_NEAR check equivalent to EXPECT_EQUAL. Consider using EXPECT_DOUBLE_EQ instead. Tested: I confirmed that this change detects the bad epsilon value that caused crbug.com/786046 in Chromium and added a test for the desired output. PiperOrigin-RevId: 332946880
- Loading branch information