Include non-finite BigDecimal values?

[littledan]

Should we include Infinity, -Infinity and NaN as BigDecimal values? Number includes these, and BigInt does not.

[qzb]

There is no point to have NaN value, when all operations which could return it throw exception instead. There is also no operation between two finite (big)decimals which could end up with Inifinity, but having Infinity could be handy in some cases.

By the way, why Infinity is not included in BigInt? I've tried to find a rationale in discussion around original proposal and TC39 notes, but I didn't find anything except this comment, which is not very elaborate. But following this argumentation: BigDecimal does not represent infinity, it only represents decimals.

[sffc]

Number includes these types only because they are required for IEEE floating point compliance. They should not be added to BigDecimal in my opinion.

[jessealama]

Looks like we have some consensus that Decimal (regardless of the BigDecimal vs. Decimal128 discussion) should allow representing and working with only finite values?

[jessealama]

Based on feedback we've received at the TC39 plenary, I'd like to re-open this discussion a bit. In short, the feedback I've received questions our deviation from official IEEE 754.

If we decide to use IEEE 754 Decimal128 as the underlying data model for Decimal, our intention is, of course, to stick as close as possible to the spirit and letter of that spec as possible, though we allow that, in a few places, some deviations may be necessary whereas in other places one might insist on sticking to the spec. In particular, one could argue that +/- Infinity, minus zero, and NaN, should be present, for conformity. (Or some non-empty subset of these options should be included.) My questions:

Our previous stance was that:

1. 0 and -0 are the same (both "0" and "-0" are syntactically valid but yield equal decimal numbers, and any calculation that would produce -0 would actually produce 0), and
2. any calculation that would yield NaN, Infinity, or -Infinity, if carried out in an ideal Decimal128 world, would throw in the JS world.

Look at this from a JS engine implementor's point of view. Our goal (again, assuming that Decimal128 is the way to go) is to basically allow an implementor to "just" plug in a C/C++ library for Decimal128 and work with that as is. We want to minimize the amount of intervention the JS engine implementor needs to do to try to bridge any gap between official Decimal128 at the C/C++ level with the JS world. So if the C/C++ library spits out NaN, Decimal could spit out NaN, too, and the same goes for +/- Infinity and minus zero.

Here are a couple of questions:

In JS, 0 and -0 are already the same (0 === -0), so you might say there's precedent for ignoring this bit of IEEE 754. Do we want to stick with that precedent, or do we want to allow -0 as a distinct Decimal value?

What about JS's +/- Infinity? Do we want a new version of them (think Decimal.POSITIVE_INFINITY, etc.) or are these JS values also valid Decimal values?

[ljharb]

They’re observably different Numbers with Object.is.

[jessealama]

They’re observably different Numbers with Object.is.

Interesting! That's a good catch. OK, then I need to cancel my line of argument that we may want to "follow precedent". Based on this, perhaps we could then consider making 0 and -0, as decimals, distinct (non-equals).

I'd suggest that Decimal have an is-zero method. It would return true for these two (distinct) values, but nothing else.

[ljharb]

If they’re objects, yes, but the precedent is simpler with primitives - 0 and -0 are === but not Object.is.

[jessealama]

Current thinking about these values (working here in with the Decimal128 data model):

• Infinity (positive, negative) might be useful in some scenarios.
• Same for minus zero.
• Banish NaN.

I find it hard to justify blessing NaN as a Decimal value, whether that means treating the already existing NaN as a valid Decimal value or having a one-off value (e.g., a symbol) for representing Decimal NaN. I agree with @qzb that Decimal should just throw if a calculation would produce NaN. If there are any counterarguments, do chime in!

[jessealama]

Number includes these types only because they are required for IEEE floating point compliance. They should not be added to BigDecimal in my opinion.

Does your thinking extend to a Decimal128-based version of Decimal?