BigDecimal with division and other operations which need to round

[littledan]

Division is a bit of a conundrum with arbitrary-sized decimal types. This was discussed in the 2017 TC39 presentation. There are two basic approaches I've seen in the ecosystem:

• Java-like: Require that the user provide the precision and/or rounding mode as a parameter when performing division
• Ruby-like: Just choose an arbitrary amount of extra decimal places to use for the division result
• The implicit third option is to avoid division, and instead have a div/mod operation, or a "partition" operation (to split a BigDecimal into an integer number of buckets as equally as possible, at the precision of the BigDecimal)

I'm not sure what to do here. I've even considered whether this is the straw that breaks the camel's back, requiring 128-bit IEEE 754 decimal. What are your thoughts?

[qzb]

I'm not entirely sure if it's a good idea, but there is another option (or rather a variant of Java-like approach) - use precision based on product of precisions of the multiplication factors:

1m / 3m === 0m
1.00m / 3m === 0.33m
1.00m / 3.00m === 0.3333m

I'm not sure if it's intuitive enough, but it's for sure more convenient than using method instead of operator, it gives more control than Ruby-like approach, and it's a nice parallel to multiplication.

[littledan]

@qzb Thanks for including this option; we should definitely be considering this option among the three others above. It makes sense formally, considering the precision rules for other operators.

Personally, I find 1m / 3m === 0m to be confusing enough (for a feature which is all about preserving decimal precision) to cast some significant doubt on this version.

[qzb]

@littledan Even worse, according to these rules 1m / 2m === 0m, even thought it have not only finite but also short decimal expansion. Maybe some compromise can be made, e.g.: quotient precision could be a maximum of some predefined value (let say 10) and of sum of precisions of dividend and divisor:

1.000m / 3m = 0.333333333m // max(10, 3 + 0) = 10
1.000m / 3.0000000000m = 0.3333333333333m // max(10, 3 + 10) = 13

It gives some control over result's precision, works with existing operator, but starts to be pretty convoluted...

---

BTW, it's worth mention that we can have both Java-like and Ruby-like operations, one using .divide() method and other / operator. In my opinion Java-like approach should be implemented, the only question is what method should be used for / operator (if any).

[littledan]

@qzb This may be a reasonable compromise. I think this is what Ruby does. The ugly part is that we have to arbitrarily choose this constant (e.g., 10).

[domenic]

FWIW, here was my short thought process upon hearing of this conundrum:

• It would be bonkers if you couldn't divide decimals. What if I want to split an amount of money between two people?
• OK, but I see there is a clearly a precision problem. I guess the easiest solution is to require specifying the precision, e.g. 1m.divide(2m, { precision: 10 }).
  • I wonder what units that precision value has... bits? Decimal places? Significant figures? Ah well, someone smart will figure that out.
• But it's so un-ergonomic to have to drop down to .divide() for a common-ish operation like this. / should really work. I guess the only way out of this is to pick a default precision value which / uses, i.e. to explain that xDec / yDec is shorthand for xDec.divide(yDec, { precision: SOME_DEFAULT }).

[MaxGraey]

What about static field which could read / write in BigDecimal namespace like BigDecimal.MIN_DECIMAL_PRECISION?

[qzb]

@domenic Actually splitting money is not a good use case for dividing. Let's assume you are trying to split 10$ between three people, you have to end up with one person which pays 3.34$ instead 3.33$. When comes to splitting money you want some kind of div/mod or partition operation described by littledan in 3rd point of this issue. It could work like this:

const [ q, r ] = (10m).divmod(3m, { precision: 2 }) // q === 3.33m, r === 0.01m
const [ a, b, c ] = (10m).partition(3n, { precision: 2 }) // a === 3.33m, b === 3.33m, c === 3.34m

[qzb]

@MaxGraey AFAIK currently specification doesn't include even single (writable) constant like this and adding one would probably be pretty controversial. Also it sounds like a method for producing really nasty bugs, since any of your dependencies could change it.

If some minimal precision is chosen we should definitely add constant like this, Number already have 8, but it should not be writable.

[littledan]

Yeah, I don't think we can have a global setting for these sorts of things. For one, primitives live outside of any particular JS global object, so they couldn't even reference that. But stepping back a bit, global settings are just the enemy of composability of different pieces of code, which is what the JS ecosystem is based on.

[mmis1000]

Just for curious, why not big fraction (someone actually implemented that with big int) instead?
BigDecimal is effectively fraction but allow only 10 based denominator.

If non 10 based denominator is allowed.

1.0040 is just 10040 / 10000.
1.0040 / 3 would just be 10040 / 30000.

Not got rounded (Because you don't need to)

Allowing non 10 based fraction will also makes something 1 / 3 + 1 / 3 + 1 / 3 works as anyone would expect(the computation will be more expensive though).

[qzb]

@mmis1000 It's called Rational, and it's discussed in issue #6

[Skalman]

I haven't seen it proposed elsewhere, so here goes. You could have a "use ..." directive.

"use decimalDivision fractionDigits:2 round:down";

1m / 3m === 0.33m

In order to use the / operator with BigDecimals, you have a "use decimalDivision ..." directive. If there are multiple such (possibly conflicting) directives in the same function/file, use the first one.

This syntax is quite ugly though, and quite verbose. And I suppose it'd be impossible to support something similar for your own implementations if operator overloading is ever standardized.