Miri test_native_type_pow test failing

[adamreeve]

After merging #7633 the MIRI tests have started failing (https://github.com/apache/arrow-rs/actions/runs/15575898901/job/43860649183):

failures:

---- arithmetic::tests::test_native_type_pow stdout ----

thread 'arithmetic::tests::test_native_type_pow' panicked at arrow-array/src/arithmetic.rs:807:9:
assertion `left == right` failed
  left: 63.999977
 right: 64.0

The corresponding line is:

assert_eq!(8.0_f32.pow_wrapping(2_u32), 64_f32);

This looks unrelated to the changes in that PR though, and the failure also corresponds to a new nightly version being used: 1.89.0-nightly (1677d46cb 2025-06-10)

[adamreeve]

Looks like it was likely to have been caused by this change in miri, which was added between nightly versions d13a431 and 1677d46: rust-lang/rust#138062

[alamb]

Unless we think this particular test is adding additional MIRI coverage, I think we could #cfg(not(miri)) or something to not run this test under MIRI mode temporarily until we sort out what, if any, real changes are warranted

[RalfJung]

FWIW the point of that Miri behavior is to find code that incorrectly relies on powf and other functions giving precise results, despite the fact that the docs say:

The precision of this function is non-deterministic. This means it varies by platform, Rust version, and can even differ within the same execution from one invocation to the next.

[alamb]

FWIW the point of that Miri behavior is to find code that incorrectly relies on powf and other functions giving precise results, despite the fact that the docs say:

The precision of this function is non-deterministic. This means it varies by platform, Rust version, and can even differ within the same execution from one invocation to the next.

Thank you @RalfJung -- this makes sense.

I think in the test that is failing is not trying to verify that we have a numerically stable pow implementation, but instead is trying to verify basic functionality

The reason the test is failing is a classic issue of "a test is comparing floating point values using (bitwise) equality when they should be compared using a allowable epsilon"

We were just "lucky" before that it didn't cause issues.

So TLDR I think this is just a test thing and we should update the test

[alamb]

label_issue.py automatically added labels {'arrow'} from #7646