ES Decimal status

Mike Cowlishaw MFC at uk.ibm.com
Wed Sep 24 03:33:41 PDT 2008


David-Sarah Hopwood wrote:
> Mike Cowlishaw wrote:
> >> 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. [...]
> >>>>
> >>>> 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 [...]
> >>>
> >>> 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.
> > 
> > I don't really have an opinion on how the operation should be spelled.
> 
> That matters, because .toString() is used implicitly in primitive
> operations, unlike other most other methods (.valueOf() aside).

Understood.  I meant that if the function had to be provided under another 
name that is OK, but not ideal.

> > But it would seem nice, not bizarre, for the default conversion 
> > from a decimal 
> > number to a string in ES to work the same as in Java and in the 
equivalent 
> > functions and methods for C, C++, Python, many other languages, and in 

> > existing decimal packages.
> 
> Java, C and C++ do not have implicit conversions that call .toString(),

Java certainly does (the concatenate operator, and in many common methods 
(println for example)).  And in the new C extensions, printf does the 
equivalent on decimal data and gives the same string results by default.

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

Mike





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








More information about the Es-discuss mailing list