On Wed, 26 Apr 2023 01:47:07 GMT, Joe Darcy <da...@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 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.
No, that would not be correct. It would be subject to [double
rounding](https://en.wikipedia.org/wiki/Rounding#Double_rounding), against the
spec.
For example, `BigDecimal` 1.000000059604644775390626 should round to `float`
`1.0000001f`.
When going to the closest `double` and then to the closest `float`, however, it
first rounds to `double` `1.0000000596046448` and the to `float` `1.0f`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/9410#discussion_r1177530816
