On Thu, 7 Jul 2022 15:20:32 GMT, Raffaello Giulietti <rgiulie...@openjdk.org>
wrote:
> A reimplementation of `BigDecimal.[double|float]Value()` to enhance
> performance, avoiding an intermediate string and its subsequent parsing on
> the slow path.
src/java.base/share/classes/java/math/BigDecimal.java line 308:
> 306: /*
> 307: * Let l = log_2(10).
> 308: * Then, L < l < L + ulp(L) / 2, that is, L = roundTiesToEven(l).
It doesn't matter in terms of the code, but shouldn't this be something like:
L - (ulp(L)) < l < L ulp(L)
In other words, without further checking, it isn't clear that L is the
lower-bound of the two double value bracketing l.
(If the ulp function being discussed were the real-valued version than L +/-
ulp(l) would also be a reasonable formulation.)
src/java.base/share/classes/java/math/BigDecimal.java line 3749:
> 3747: */
> 3748: @Override
> 3749: public float floatValue() {
If the total size of code were a concern, I wouldn't be adverse to floatValue()
being implemented as
return (float)doubleValue();
Given the 2p+2 property between the float and double formats, BigDecimal ->
double -> float and BigDecimal -> float round the same way.
src/java.base/share/classes/java/math/BigDecimal.java line 3777:
> 3775: return 0.0f;
> 3776: }
> 3777: BigInteger d = unscaledValue().abs();
I'd prefer a name other than "d" be used for the BigInteger significand's
magnitude.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177225652
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177230119
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177228393
