Consistent decimal semantics
brendan at mozilla.org
Mon Aug 25 16:55:37 PDT 2008
On Aug 25, 2008, at 4:41 PM, Waldemar Horwat wrote:
> We're going round in circles on a few issues surrounding Decimal.
It seems to me people have reached the conclusion you already did on
===. I'm not sure anyone advocated otherwise (I've missed most 3.1
calls lately, so can't be sure).
> Some of these have clear resolutions; others have a little wiggle
> room. Here's my summary:
Thanks, the FAQ format is helpful. I agree with your answers, but I
have a couple of questions.
> - Should decimal values behave as objects (pure library
> implementation) or as primitives?
> If they behave as objects, then we'd get into situations such as
> 3m != 3m in some cases and 3m == 3m in other cases. Also, -0m !=
> 0m would be necessary. This is clearly unworkable.
What should be the result of (typeof 3m)?
> - What should cross-type === do on 5 === 5m?
> These objects are of different types, so it should return false.
Confusion: 5 is of "number" type (a primitive type, typeof agrees),
so "These objects" should have been "These values" -- right?
Sam and I, not going in circles (much), agree that typeof 3m should
be "object", and that we add hardwired operator support for such
> - How should mixed type arithmetic work in general?
> There are a few consistent design alternatives:
> 1. Always disallow it. For consistency you'd have to disallow ==
> between Number and decimal as well.
This was what Igor Bukanov and I were advocating last week.
> 2. Allow it, converting to the wider type (Decimal128). There are
> a couple design choices when doing the conversion:
> 2a. Convert per the IEEE P754 spec: 5.1 turns into
> 5.099999999999999644728632119949907m. This is how most programming
> languages operate (C++, Java, Lisp, etc.) when converting among the
> built-in floating point values (float -> double etc.).
(I'm asking anyone who thinks so, as well as asking for your
opinion:) Better than alternative 1? If so, why?
> 2b. Convert the Number to a string and then to a Decimal: 5.1
> turns into 5.1m. As a special case, -0 would turn into -0m. This
> might work, but I haven't thought through the implications of this
More information about the Es-discuss