ES Decimal status
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
> >>>>> 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
> >>> 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
> > 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
This is true. But that in itself is not the problem. Currently, should a
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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the Es-discuss