[libc-commits] [PATCH] D83931: Update Test (EXPECT_EQ and friends) to accept __uint128_t and floating point types (float, double, long double).

[Tue Ly via Phabricator via libc-commits]

lntue added a comment.

In D83931#2156530 <https://reviews.llvm.org/D83931#2156530>, @sivachandra wrote:

> In D83931#2155091 <https://reviews.llvm.org/D83931#2155091>, @abrachet wrote:
>
> > Why add support to the TEST macros for this when we have the MPFR macros which I think handle floats better than we can with TEST.  Comparisons with floating points are not fun, its why we use the mpfr library in the first place. Is there even a need to use the TEST macros with floats?
>
>
> Let me give some explanation from my side for this. For non-trivial math functions like trignometric functions, comparing with MPFR result makes sense because we can use MPFR as source of truth/correctness. But, for functions like `fmin` and friends, comparing with MPFR is an overkill. I agree that comparing floating points in general could be problematic and that is the reason why we did not allow floating comparisons until now. But, if we restrict ourselves to values which have an exact bit representation, then comparisons are precise and deterministic. For example, zero, infinity and small decimals like 10.0, 1.2345 etc. have exact bit representation in all relevant floating point formats Likewise, if a floating point number is actually constructed from the bit representation, then that number has exact bit representation by construction. So, comparing such numbers would be precise.
>
> One can ask, how can we ensure one uses only exact floating point numbers in tests. I don't have a good answer other than saying "code review". May be we can write a clang-tidy driven tool in future. Irrespective, I think this patch improves the readability of the tests. @lntue is the expert here so he might have more to add.


As Siva mentioned, for math functions that are correctly rounded, the bit patterns of the results are well-defined, and so we can compared their exact bit patterns directly (unless when they are both NaNs, which we can ignore).  This would simplify and improve readability for testing such functions.  Going further, I plan to add a simple ULP function to allow testing with controlled numbers of error bits.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83931/new/

https://reviews.llvm.org/D83931