On Mon, 21 Oct 2024 17:01:43 GMT, fabioromano1 <d...@openjdk.org> wrote:
>>> > Curiously, this one runs in a fraction of a second on the current >>> > implementation, but not on the proposed one: >>> > `BigDecimal.valueOf(100).sqrt(new MathContext(1_000_000, >>> > RoundingMode.HALF_EVEN)).shortValue()` >>> >>> @rgiulietti This is because, in the current implementation, the check for >>> even powers of 10 is always done, while in mine is done only if exact >>> result is required. >> >> Since there's an invocation of `stripTrailingZeros()` anyway, what's the >> reason to _not_ "optimize" for other round modes as well, like in the >> current implementation? > >> Since there's an invocation of `stripTrailingZeros()` anyway, what's the >> reason to _not_ "optimize" for other round modes as well, like in the >> current implementation? > > Because it is not necessary to strip zeros when an exact result is not > requested, so while the call to `stripTrailingZeros()` speeds up only for the > unlikely case that the input is an even power of 10, it slows down for all > other cases... @fabioromano1 I took a look at the code, and at first sight it looks good. However, before approving, I'll have a deeper look in the next couple of days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2474053522
