RFR: 8366478: BigDecimal roots [v9]

[Joe Darcy]

On Fri, 24 Oct 2025 15:36:58 GMT, fabioromano1 <duke at openjdk.org> 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