On Wed, 29 Apr 2026 08:34:37 GMT, Anton Artemov <[email protected]> wrote:

> Hi, please consider the following changes:
> 
> This is a fix for the `StrictMath.pow()` method, which corrects its numerical 
> behavior in certain cases. 
> 
> It was recently reported by [Gladman et 
> al](https://members.loria.fr/PZimmermann/papers/accuracy.pdf) that the 
> `pow()` method in the original FDLIBM returns with error of 636 ulps in 
> certain cases. `StrictMath.pow()` is a direct port of FDLIBM `pow()`.
> 
> It turned out that `ivln2` constant split into high  and low parts (`ivln2_h` 
> and `ivln2_l` respectively) in the original method is not sufficient to 
> compute `u = ivln2_h * t` exactly in certain cases, namely when the span of 
> non-zero bits in `t` is wide. 
> 
> By the default split, the high part `ivln2_h` contains 24 high bits of 
> `ivln2`, and by changing the split so that `ivln2_h` contains only 21 bits of 
> `ivln2` we ensure that `u = ivln2_h * t` is computed exactly in all cases 
> when pow(x,y) does no overflow.
> 
> New testcases added.
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/30984

Reply via email to