Test against MPFR #311

tgross35 · 2024-10-18T09:40:12Z

Test against MPFR via rug for infinite precision results in cases where musl might not be accurate.

tgross35 · 2024-10-21T22:49:16Z

I think this is ready for a review too @Amanieu. This adds tests against MPFR for almost all functions, which gives us infinite precision results in cases where we want to be more accurate than musl.

The few untested functions are at

libm/crates/libm-test/tests/multiprecision.rs

Lines 47 to 61 in 4d51e47

    
           skip: [ 
        
               // FIXME: MPFR tests needed 
        
               frexp, 
        
               frexpf, 
        
               ilogb, 
        
               ilogbf, 
        
               ldexp, 
        
               ldexpf, 
        
               modf, 
        
               modff, 
        
               remquo, 
        
               remquof, 
        
               scalbn, 
        
               scalbnf, 
        
           ],

.

This targets my test-refactoring branch so it can't be merged directly (requires #300).

beetrees

Thanks for working on this!

beetrees · 2024-10-25T16:54:53Z

crates/libm-test/src/mpfloat.rs

+where
+    for<'a> &'a MpFloat: az::Cast<F>,
+{
+    mp.subnormalize_ieee();


This will currently cause double rounding for subnormal results, as the result will be rounded once to the full precision and then again to the subnormal precision. Use subnormalize_ieee_round instead, passing it the Ordering from the relevant _round-suffixed function for the operation (e.g. acos_round) so that the subnormalize function is aware of what rounding previously occurred.

Oh good catch. Is there a point in asserting that the rounding returned by subnormalize_ieee_round is Equal?

The rounding returned from subnormalize_ieee_round will only be Equal if no rounding has occured (i.e. the result is exact). Unless you need to know what rounding has occured, you can just ignore the Ordering returned by subnormalize_ieee_round.

For my clarity, is it correct the result will be correctly rounded to 1/2 ULP regardless of what the return value is? Meaning the returned Ordering provides information about what was truncated rather than about accuracy to a bitwise representation.

Changed to use _round rather than _mut and pass the result to prep_retval.

beetrees · 2024-10-25T17:01:55Z

crates/libm-test/src/xfail.rs

+        let outputs_nan = all_nan(&[actual, expected]);
+
+        match &ctx.basis {
+            CheckBasis::Musl => match ctx.fname {
+                // We return +NaN, Musl returns -NaN
+                "tgammaf" => input.0 < 0.0,
+                _ => false,
+            },
+            CheckBasis::MultiPrecision => match ctx.fname {
+                // For almost everything we return -NaN but MPFR does +NaN
+                _ if (input.0.is_nan() || input.0.is_infinite()) && outputs_nan => true,
+                // x86 MacOS NaN doesn't seem to depend on input sign
+                _ if cfg!(x86_macos) && outputs_nan => true,
+                // Out of domain we return +NaN, MPFR returns -NaN
+                "atanhf" => input.0 < -1.0 && outputs_nan,
+                // We return -NaN, MPFR says +NaN
+                "tgammaf" => input.0 < 0.0 && outputs_nan,
+                _ => false,
+            },
+        }


AFAIK, none of the libm functions (except for copysign and abs) provide any guarantees about the sign of returned NaNs, so mismatches in NaN signs can just be blanket ignored (except for copysign and abs) instead of carving out exceptions for where they happen to currently mismatch.

That sounds cleaner. Do you know if these functions should do anything specific with signaling NaNs they receive as input?

Also, do you know if MPFR's operations provide determinism for NaNs? I was thinking that maybe there is some benefit to being deterministic even if not required.

According to Rust's NaN guarantees, signalling NaNs can be returned from arthimetic operations if a signalling NaN was part of the input (Rust also restricts the bitpatterns of returned NaNs, but the restrictions are extremely unlikely to be a problem unless a libm function implementation deliberately creates a NaN with a custom payload). In practice the allowance for signalling NaNs to be returned is mainly to allow LLVM to do transformations like 1.0 * x => x at compile time.

The C23 draft standard recommends (but does not require) that signalling NaNs are quietened (C17, AFAIK from the draft I have access to, doesn't place any requirements on signalling NaN handling).

The IEEE standard (AFAIK; I don't have access to a copy) states that signaling NaNs should be quietened (except for copysign and abs).

Quietening signalling NaNs is probably the "better" behaviour (in complies with more standards). However, ensuring all NaNs returned are quietened may take some extra implementation effort, as Rust explicitly doesn't guarantee the quietening of signalling NaNs by any floating-point operation (although in practice all arithmetic operations will quieten signalling NaNs unless LLVM has optimised out the operation itself). That said, most function implementations have an explicit if-NaN-return-NaN check at the start, so as long as that returns a quietened NaN everything should be fine (as signalling NaNs cannot be produced by any arithmetic operation that doesn't have a signalling NaN in its input, meaning the only possible source of a signalling NaN is the function arguments).

In summary, I think libm should quieten signalling NaNs before returning them (or just return f{16,32,64,128}::NAN instead), but it's not essential.

MPFR will always return the same NaN when converting a MPFR NaN to f32/f64, and only has a single kind of NaN (documentation, source code for converting to f32/f64).

Thank you for all the context, your suggestion sounds reasonable to me.

Adjusted so we no longer check for NaN except the cases you mentioned. This logic is in maybe_check_nan_bits.

Sometimes we want to be able to xfail specific inputs without changing the checked ULP for all cases or skipping the tests. There are also some cases where we need to perform extra checks for only specific functions. Add a trait that provides a hook for providing extra checks or skipping existing checks on a per-function or per-input basis.

Add a way to call MPFR versions of functions in a predictable way, using the `MpOp` trait. Everything new here is guarded by the feature `test-multiprecision` since MPFR cannot easily build on Windows or any cross compiled targets.

This effectively gives us tests against infinite-precision results on MacOS and x86+sse Linux.

tgross35 marked this pull request as draft October 18, 2024 21:47

tgross35 force-pushed the mpfr-test branch 8 times, most recently from e386722 to ded5a3e Compare October 21, 2024 22:19

tgross35 changed the base branch from master to tgross35/test-refactoring October 21, 2024 22:26

tgross35 force-pushed the mpfr-test branch 2 times, most recently from 2bd6dbb to 4d51e47 Compare October 21, 2024 22:43

tgross35 changed the title ~~[wip] test against MPFR~~ Test against MPFR Oct 21, 2024

tgross35 marked this pull request as ready for review October 21, 2024 22:49

tgross35 assigned Amanieu Oct 21, 2024

tgross35 force-pushed the mpfr-test branch from 4d51e47 to b782209 Compare October 21, 2024 23:50

tgross35 force-pushed the tgross35/test-refactoring branch 2 times, most recently from 09d82a7 to 2722bde Compare October 22, 2024 00:06

tgross35 force-pushed the mpfr-test branch 4 times, most recently from a20b0c8 to c76cece Compare October 22, 2024 00:16

tgross35 force-pushed the tgross35/test-refactoring branch 3 times, most recently from 6bf4102 to f778935 Compare October 22, 2024 01:02

tgross35 force-pushed the mpfr-test branch from c76cece to 3a81e92 Compare October 22, 2024 01:02

tgross35 force-pushed the tgross35/test-refactoring branch from f778935 to 044142f Compare October 22, 2024 02:29

tgross35 force-pushed the mpfr-test branch 2 times, most recently from b33d482 to e661694 Compare October 22, 2024 10:10

tgross35 force-pushed the mpfr-test branch 4 times, most recently from 5cb946e to 56c98a8 Compare October 22, 2024 16:03

tgross35 force-pushed the tgross35/test-refactoring branch from 044142f to 93a4bd9 Compare October 22, 2024 16:36

tgross35 force-pushed the mpfr-test branch 3 times, most recently from bba7079 to 0f22dac Compare October 22, 2024 18:34

tgross35 mentioned this pull request Oct 25, 2024

Test porting the core-math cube root implementation #318

Draft

beetrees reviewed Oct 25, 2024

View reviewed changes

beetrees mentioned this pull request Oct 25, 2024

Test more targets against a custom-built musl libm #300

Open

tgross35 force-pushed the tgross35/test-refactoring branch from 93a4bd9 to 12bf64a Compare October 25, 2024 22:44

tgross35 force-pushed the mpfr-test branch from 0f22dac to 2f1e543 Compare October 26, 2024 00:51

tgross35 force-pushed the tgross35/test-refactoring branch from 12bf64a to 8ef0575 Compare October 26, 2024 04:05

tgross35 force-pushed the mpfr-test branch 4 times, most recently from 96bada7 to d3401a2 Compare October 26, 2024 05:14

tgross35 requested a review from beetrees October 26, 2024 05:18

tgross35 mentioned this pull request Oct 26, 2024

Add copysignf16, copysignf128, fabsf16, and fabsf128 #320

Open

tgross35 force-pushed the tgross35/test-refactoring branch from 8ef0575 to c3862a3 Compare October 27, 2024 02:00

tgross35 added 4 commits October 26, 2024 21:11

Create interfaces for testing against MPFR

fa5cf82

Add a way to call MPFR versions of functions in a predictable way, using the `MpOp` trait. Everything new here is guarded by the feature `test-multiprecision` since MPFR cannot easily build on Windows or any cross compiled targets.

Add a test against MPFR using random inputs

4585827

Run tests against MPFR on CI where possible

58c708d

This effectively gives us tests against infinite-precision results on MacOS and x86+sse Linux.

tgross35 force-pushed the mpfr-test branch from d3401a2 to 58c708d Compare October 27, 2024 02:12

tgross35 mentioned this pull request Oct 27, 2024

Add benchmarks against musl libm #314

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test against MPFR #311

Test against MPFR #311

tgross35 commented Oct 18, 2024 •

edited

Loading

tgross35 commented Oct 21, 2024

beetrees left a comment

beetrees Oct 25, 2024

tgross35 Oct 25, 2024

beetrees Oct 25, 2024

tgross35 Oct 25, 2024 •

edited

Loading

beetrees Oct 25, 2024

tgross35 Oct 26, 2024

beetrees Oct 25, 2024 •

edited

Loading

tgross35 Oct 25, 2024

tgross35 Oct 25, 2024

beetrees Oct 25, 2024 •

edited

Loading

beetrees Oct 25, 2024 •

edited

Loading

tgross35 Oct 25, 2024

tgross35 Oct 26, 2024

Test against MPFR #311

Are you sure you want to change the base?

Test against MPFR #311

Conversation

tgross35 commented Oct 18, 2024 • edited Loading

tgross35 commented Oct 21, 2024

beetrees left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tgross35 Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beetrees Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

beetrees Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

beetrees Oct 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tgross35 commented Oct 18, 2024 •

edited

Loading

tgross35 Oct 25, 2024 •

edited

Loading

beetrees Oct 25, 2024 •

edited

Loading

beetrees Oct 25, 2024 •

edited

Loading

beetrees Oct 25, 2024 •

edited

Loading