Initial comments on Kona draft

Sam Ruby 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.

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



More information about the Es-discuss mailing list