RFR: 8341402: BigDecimal's square root optimization [v23]

[Raffaello Giulietti]

On Tue, 26 Nov 2024 17:13:04 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> OK. But for the sake of completeness, I would add at least one test case for an overflowing `workingScale`.
>> 
>> I'm afraid it's not possible to produce such a test case, with the current implementation of `BigInteger`.
>> Indeed, `workingScale` is defined by `workingScale = this.scale - normScale`, and `normScale` by:
>> 
>> long ns = minWorkingPrec - this.precision() + this.scale;
>> long normScale = ns + (ns & 1L);
>> 
>> Therefore `workingScale ==  this.precision() - minWorkingPrec - (ns & 1L)`, so to overflow `workingScale` it is necessary to maximize `this.precision()`, thus`this.intVal` must have at least `Integer.MAX_VALUE + 1` digits, but `BigInteger.TEN.pow(Integer.MAX_VALUE)` surely exceeds the supported range for  `BigInteger`s...
>
> Actually, this proves also that `workingScale` should never overflow, as `this.precision()` is also an `int`, so it cannot have a value larger than `Integer.MAX_VALUE`.

I don't get your point. Here's an example:

BigDecimal.ONE.sqrt(new MathContext(2_000_000_000, RoundingMode.UP))
|  Exception java.lang.ArithmeticException: Overflow
|        at BigDecimal.sqrt (BigDecimal.java:2226)
|        at (#4:1)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1858957065