On Wed, 23 Sep 2026 20:15:14 GMT, Justin Lu <[email protected]> wrote:
>> This PR addresses a rounding error for >> `CompactNumberFormat.format(BigDecimal)`, which occurs when the maximum >> fraction digits value is greater than the minimum fraction digits value. >> >> For example, given a format with 0 minimum fraction digits and 2 maximum >> fraction digits and a `BigDecimal` of 21_534_567.20, the following behavior >> occurs. >> >> - `21_534_567.20` is first scaled to `21_534_567` to determine which compact >> divisor should be used >> - The millions pattern is selected, and the following division occurs -> >> `21_534_567` / `1_000_000`. During the division operation, the minimum >> fraction digits is inherited as the scale and applied to the resulting >> quotient which produces 22. >> >> Instead, the division should occur exactly, and `21_534_567` / `1_000_000` >> should produce `21.534567` which is then later rounded with the 2 maximum >> fraction digits to a value of `"21.53M"`. >> >> While the filed regression points out the BD path, this also occurs for the >> BI formatting path when the underlying value is greater than what a `long` >> supports and whose division result would produce a fraction. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > simplify negation in getRoundedQuotient Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/32933#issuecomment-5838171954
