I just had some time to spend reading the proposed draft of the new floating
point spec. It quickly became apparent that ES3.1 is far out of conformance
with that draft and it would be a significant undertaking to update it to
conform to the new standard. In addition, doing so would introduce breaking
incompatibilities into the language.
Here is a smattering of major issues. The chapter and section numbers refer to
the draft IEEE P754:
- Many, if not most, of the mandatory functions in chapter 5 are not
implemented in ES3.1. There are a lot that we'd also need to implement on
binary floating-point numbers.
- IEEE P754 5.12.1 mandates that (decimal or binary) -0 print as "-0". This is
not going to happen.
- IEEE P754 5.12 mandates that binary floating-point numbers convert exactly to
a string format with a hexadecimal mantissa and back. An implementation must
provide these conversions.
A few other tidbits about IEEE P754:
- There are many different ways of representing the same decimal number, which
the standard calls a cohort. Some numbers, such as zeroes, have thousands of
different variants within the cohort. Fortunately, printing a decimal number
is not required to indicate which member of a cohort is chosen. This avoids
problems for us such as having the numbers x == y but a[x] and a[y] silently
referring to different array elements (which is what would happen if we printed
5.00m differently from 5.m).
- The standard now supports signed NaN's which are distinguishable from each
other in various ways (total order predicate, isSignMinus, etc.). There has
been some talk about deferring to the IEEE spec instead of listing the
permissible binary floating-point values explicitly as was done in ES3, but we
must maintain something like the existing language to avoid getting into this
quagmire.
- Implementors of the standard could not agree on the binary representation of
decimal numbers. There are two mutually incompatible ways of representing them
-- the mantissa can be either a binary integer or an array of 10-bit groups,
each representing three decimal digits. I can't tell whether they behave
differently in some scenarios -- if the format is wide enough, the integral
representation can represent more values, and their handling of noncanonicals
differs.
- Some parts of IEEE P754 are ambiguous. For example, the notion of a
subnormal is unclear when applied to decimal numbers. It appears that you can
have two equal values x and y of the same decimal format where x == y, x is
subnormal, but y is not subnormal.
Some tidbits about our embedding of decimal:
- Contagion should be towards decimal if decimal and binary are mixed as
operands. 5.3m + 1 should be 6.3m, not 6.3. If we use 128-bit decimal, this
also makes the behavior of heterogeneous comparisons (binary compared to
decimal) sensible.
- We should not print the trailing zeroes. IEEE P754 does not require it, and
it breaks things such as array lookup. There is precedence for this in
ECMAScript: -0 and +0 both print as "0". If someone really wants to
distinguish among equal numbers, he can do it with a function call to one of
the mandated functions.
Waldemar
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
