Waldemar Horwat wrote:
7.8.3: This states that decimal literals may be rounded to 20 significant digits. Is that what we want?
That's a bug.
8.5: "The Decimal type has exactly 10^34*12288+3 values". I don't think this is correct. How did you arrive at this figure?
Mantissa has 34 digits Exponent can range from -6144 to 6143 NaN, +Infinity, -Infinity Oversight: sign would double the number of values.
There are not ten times as many denormalized Decimal values as there are normalized Decimal values. All of the Decimal number counts in this section appear suspect.
There should be approximately 9 times as many... values with a non-zero mantissa that end with a digit of 0 as compared to mantissas which end in a non-zero value.
Why do we need to distinguish Decimal denorms anyway? The concept is not used anywhere in the document.
Do we need to distinguish binary floating point denorms? Dropping both would make me happy.
Fix grammar and spelling errors. 9: Decimal support broken in most of the tables.
Bug.
9.3: ToDecimal on a Number gives the Number unchanged? ToNumber on a Decimal is not defined.
Bug.
9.8: ToString on a Decimal is not defined in the table. The algorithm only works on Number values. +0, -0, etc. are Number values, not Decimal values. Also, it internally references conversions to Numbers.
Bugs.
9.3.1: ToDecimal on a string results in a Number. Also, it optionally drops significant digits after the 20th.
Bug.
11.3.1, 11.3.2: All four of the return statemets are wrong in different ways. Some return the preincremented value. Some return an lvalue instead of an rvalue.
Others have already noted this. David-Sarah has proposed new wording.
11.5: What's the corresponding Decimal operation? There are a bunch of different remainder options.
Should specify roundTowardZero. Good catch.
11.8.5: Status: You're treating Unicode character codes as Decimal numbers. Which characters have Unicode numbers that are Numbers, and which ones have Unicode numbers that are Decimals?
I don't follow. If either value is of type Decimal, both are converted to Decimal, and the results are then compared.
If you fix this and apply the same contagion rules as for +, -, *, etc., then you'll have the issue that 1e-400m > 0m but 1e-400m > 0 is false. The contagion rules need rethinking.
Again, I don't follow. The intent is that in the latter case, the binary 0 is first converted to decimal prior to the comparison.
11.9.3: The contagion here is from Number to Decimal. This is inconsistent with +, -, *, etc., where the contagion is from Decimal to Number. It should be the same for all arithmetic operations.
The contagion should consistently be from Number to Decimal. I distinctly remember making this change this time, but double checking what I sent to Pratap, it seems like the version of the document that I sent him did not include this change. *sigh*
To be clear, step 5 in the binary operators should read "5. If Type(Result(2)) is Decimal or Type(Result(4)) is Decimal, then", substituting "or" for "and" in the expression.
11.9.6: Don't need to call ToDecimal on values that are already Decimals.
Agreed. - Sam Ruby _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
