-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include non-finite BigDecimal values? #9
Comments
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. |
Number includes these types only because they are required for IEEE floating point compliance. They should not be added to BigDecimal in my opinion. |
Looks like we have some consensus that Decimal (regardless of the BigDecimal vs. Decimal128 discussion) should allow representing and working with only finite values? |
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:
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 ( What about JS's +/- |
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- I'd suggest that Decimal have an is-zero method. It would return true for these two (distinct) values, but nothing else. |
If they’re objects, yes, but the precedent is simpler with primitives - 0 and -0 are === but not Object.is. |
Current thinking about these values (working here in with the Decimal128 data model):
I find it hard to justify blessing NaN as a Decimal value, whether that means treating the already existing |
Does your thinking extend to a Decimal128-based version of Decimal? |
Should we include Infinity, -Infinity and NaN as BigDecimal values? Number includes these, and BigInt does not.
The text was updated successfully, but these errors were encountered: