Thoughts on IEEE P754
waldemar at google.com
Thu Aug 21 18:24:02 PDT 2008
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.
More information about the Es-discuss