ES Decimal status

Sam Ruby rubys at intertwingly.net
Wed Sep 24 08:28:05 PDT 2008


Maciej Stachowiak wrote:
> 
> You probably meant to send this to the list.

Oops.  Resending.  Thanks!

>  - Maciej
> 
> On Sep 24, 2008, at 8:17 AM, Sam Ruby wrote:
> 
>> On Wed, Sep 24, 2008 at 10:45 AM, Maciej Stachowiak <mjs at apple.com> 
>> wrote:
>>>
>>> On Sep 24, 2008, at 7:31 AM, Sam Ruby wrote:
>>>
>>>> Maciej Stachowiak wrote:
>>>>> On Sep 24, 2008, at 3:33 AM, Mike Cowlishaw wrote:
>>>>>>> and in particular they don't call it on the index in an array
>>>>>>> indexing
>>>>>>> operation.
>>>>>> This is true.  But that in itself is not the problem.  Currently,
>>>>>> should a
>>>>>> programmer write:
>>>>>>
>>>>>> a[1]="first"
>>>>>> a[1.000]="second"
>>>>>>
>>>>>> it's assumed that the second case was an accidental typo and they
>>>>>> really
>>>>>> did not mean to type the extra '.000'.  The problem occurs at
>>>>>> that  point,
>>>>>> on the conversion from a decimal (ASCII/Unicode/whatever) string
>>>>>> in  the
>>>>>> program to an internal representation.  When the internal
>>>>>> representation
>>>>>> cannot preserve the distinction (as with binary doubles) there's
>>>>>> not  much
>>>>>> that can be done about it.  But a decimal internal representation
>>>>>> can
>>>>>> preserve the distinction, and so it should - 1m and 1.000m differ
>>>>>> in  the
>>>>>> same was a "1" and "1.000".  They are distinguishable, but when
>>>>>> interpreted as a number, they are considered equal.
>>>>> I'm not sure what you are getting at. a[1] and a[1.000] refer to
>>>>> the  same property in ECMAScript, but a[1m] and a[1.000m] would
>>>>> not. Are  you saying this isn't a problem?
>>>>> I would agree with Waldermar that it is a serious problem. Not so
>>>>> much  for literals as for values that end up with varying numbers
>>>>> of  trailing zeroes depending on how they were computed, even
>>>>> though they  are numerically the same. Certainly it seems it would
>>>>> make arrays  unusable for someone trying to use decimal numbers only.
>>>>
>>>> "broken", "unusable".  Given superlatives such as these, one would
>>>> think that code which would change in behavior would be abundant,
>>>> and readily identified.
>>>
>>> I would not expect there to be a wide body of existing code using the
>>> decimal extension to ECMAScript, let alone trying to use it for all
>>> browsers. Such code would not work at all in today's browsers, and has
>>> probably been written by specialist experts, so I am not sure studying
>>> it would show anything interesting.
>>
>> My apologies.  That wasn't the question I was intending.
>>
>> Can you identify code that today depends on numeric binary 64 floating
>> point which makes use of operations such as unrounded division and
>> depends on trailing zeros being truncated to compute array indexes?
>>
>> I would think that such code would be more affected by factors such as
>> the increased precision and the fact that 1.2-1.1 produces
>> 0.09999999999999987 than on the presence or absence of any trailing
>> zeros.
>>
>> But given the continued use of words such as "broken" and "unusable",
>> I'm wondering if I'm missing something obvious.
>>
>>> Regards,
>>> Maciej
>>
>> - Sam Ruby
> 
> 





More information about the Es-discuss mailing list