Initial comments on Kona draft
rubys at intertwingly.net
Fri Nov 14 20:16:58 PST 2008
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.
> 9.3: ToDecimal on a Number gives the Number unchanged?
> ToNumber on a Decimal is not defined.
> 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.
> 9.3.1: ToDecimal on a string results in a Number. Also, it
> optionally drops significant digits after the 20th.
> 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.
- Sam Ruby
More information about the Es-discuss