On Fri, 24 Oct 2025 15:36:58 GMT, fabioromano1 <[email protected]> wrote:
> > Here's a way to aim at the correctly rounded result, maybe only upon > > request because of the additional costs. > > Let y = x^(1/n) (mathematically exact), yp = rootn(x, n) (approximation), > > and assume the existence of nextHalfUp(decimal) and nextHalfDown(decimal). > > pseudo code for any rounding-to-nearest mode and for n > 0 (monotonically > > increasing function) > > ``` > > cmp = compare(yp^n, x) > > if cmp = 0 then return yp > > elsif cmp < 0 then > > while nextHalfUp(yp)^n ≤ x do yp := nextUp(yp) od > > return yp or nextDown(yp), depending on specific rounding mode > > else > > while nextHalfDown(vp)^n ≥ x do yp := nextDown(yp) od > > return yp or nextUp(yp), depending on specific rounding mode > > fi > > ``` > > > > > > > > > > > > > > > > > > > > > > > > There are various ways to improve this sketchy code. > > Similar corrective actions could be defined for the other rounding modes > > and for n < 0 (monotonically decreasing function). > > @fabioromano1 @jddarcy WDYT? Is it worth adding correct rounding upon > > request? > > I had the same idea, quite tricky to implement though. I had the following idea while reading over the code, but haven't thought it through yet so perhaps it is a non-starter: The half-way rounding modes have decision points at the midpoints between representable numbers while the other rounding points have decision points at the numbers. Since there is a code now to make the results correctly rounding for the half-way rounding mode, is there a way to use that capability to finding half-way results to one precision to infer the non-half-way results in a different precision? (In half-way rounding mode, the mapping of the real number line to results has isosceles triangles while the non-half-way rounding more have right triangle, so some kind of fix-up would presumably be needed.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27148#issuecomment-3449549945
