ES Decimal status

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Sep 23 12:15:39 PDT 2008


Waldemar Horwat wrote:
> Mike Cowlishaw wrote:
>>> There is still a blocking issue that's been discussed a lot but left
>>> off the issues here:
>>>
>>> - Treatment of cohorts in the default conversion of decimal to 
>>> string.  Despite objections, I still get the following results:
>>>
>>> 1/3m - 1/3m produces 0e-34
>>>
>>> 1e12m - 1e12m produces 0e+12
>>>
>>> 1/.1m produces 1e+1
>> I'm still not clear what your objections are -- we can discuss on 
>> Thursday, but the intent here is that the toString conversion be 
>> reversible (i.e., from the string representation one can recreate the 
>> decimal128 from which it was derived).  So I think you are really 
>> complaining about the rule for division (which is 'the best yet' that 
>> anyone has come up with, as it matches the rule for multiplication) and 
>> the rule for subtraction (which preserves the smaller exponent).  Hence 
>> 1.23-1.22 -> 0.01 and 1.23-1.23 -> 0.00.   The exponent is not 
>> data-dependent unless there is rounding.
>>
>> Mike
> 
> No; I'm complaining about the bizarre results that toString produces
> which are counter to its existing behavior.  I don't care how many extra
> zeroes division sticks at the end of the number because I should never
> see them.  This has been hashed out many times and also breaks things
> such as arrays if left uncorrected.

Agreed. It's fine to have an operation that maps decimal128 values to
strings reversibly, but '.toString()' should not be that operation.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list