should maximumFractionDigits be an int >= 1 ?

[yukinotech]

hi, I am trying to white a polyfill like jsbi , when it comes to BigDecimal.round, i want to know if maximumFractionDigits of BigDecimal.round in javascript should support 0 or negative number.

According to https://github.com/tc39/proposal-decimal/blob/master/bigdecimal-reference.md

BigDecimal.round(value [, options])

let a = BigDecimal.round(0.53m, {roundingMode: 'up', maximumFractionDigits: 1});
assert(a, 0.5m);

if maximumFractionDigits is 0 or negative number such as -3 , like this

BigDecimal.round(value [, options])

let a = BigDecimal.round(0.53m, {roundingMode: 'up', maximumFractionDigits: -3});
assert(a, 1000m);

java.math.BigDecimal seem support negative number

  BigDecimal d1 = new BigDecimal("0.53");
  BigDecimal d2 = d1.setScale(1, RoundingMode.UP);
  BigDecimal d3 = d1.setScale(-3, RoundingMode.UP);
  System.out.println(d2); // 0.6
  System.out.println(d3); // 1E+3 => 1000

I tend to maximumFractionDigits support negative numbers . Is it right ？ Does anyone have some opinion with these?

[ptomato]

I'd imagine that if the option is called maximumFractionDigits it would behave the same as the maximumFractionDigits option in Intl.NumberFormat to avoid confusion between the two.

Supporting rounding to the nearest 10 or 100 seems like a useful thing, however, so maybe the option should be called something else.

[sarahghp]

Hm, this is a very good question. I'm not certain what I think here yet, especially around consistency.

If the main use cases of this proposal are precision, first in terms of money and secondarily in terms of other high-precision computing, does it make sense to add modes that reduce the precision, at the cost of confusion or slightly different names? If Math.round does not take negative numbers, would it make sense for the Decimal version to do so?

There is also the possibility that we will want to overload the Math.round method rather than creating a new Decimal prototype method, to keep in line with the BigInt Math proposal. In that case, would allowing all calls to Math.round, regardless of value type, take negative numbers enhance the language?

[jessealama]

This issue is pretty old, but I'd like to chime in with the status quo, as of writing:

It used to be that round would take an options bag that included, as one of the options, maxSignificantDigits. In the current design, round takes just one integer argument that expresses how many fractional digits that output should have. We have the toPrecision argument that is about significant digits. The intention of decimal's toPrecision is to be like JS Number's toPrecision.