Es-discuss - several decimal discussions
rubys at intertwingly.net
Sat Aug 23 10:35:41 PDT 2008
On Sat, Aug 23, 2008 at 4:49 AM, Mike Cowlishaw <MFC at uk.ibm.com> wrote:
> So I think this comes down to 'what to do for Decimal.parse'? There
> are two obvious choices:
> * Sam's proposal for Decimal.parse is a perfectly good one: if the
> source is a binary floating point Number then use the existing
> binary64 -> string conversion in ES to get a (decimal) string,
> and then convert from that to decimal128 (which should always be
> This has the advantage that it is simple to define (given that
> binary64 -> string already has a definition) and to implement,
> and in the ES3.1 timeframe that may be important.
> It has the disadvantage that different implementations can give
> different results for the conversion. This is 'ugly', but may
> not be important given that one is starting from a binary64.
> * The alternative is to do a correctly-rounded conversion. This is
> equally simple to define but a little harder to implement (in
> that it does not already exist in ES implementations). However,
> Java already has this in the BigDecimal class, and there are also
> now hardware implementations, so it's not a showstopper. Also,
> this could also provide or use a correctly-rounded (or exact) and
> sign-preserving binary64 -> string conversion.
> The advantage of the second approach is that ES would have
> 754-compliant binary -> decimal conversions from day 1, and at the
> same time could provide the enhanced conversion for binary -> string.
> The first approach would need the addition of a different method
> later (Decimal.correctparse?) to comply. But the first approach may
> be more in the spirit of ES.
There clearly is a requirement for a string to decimal128 conversion,
if for no other reason than it would be common to want to create a
decimal value based on a form field in a DOM. It is not uncommon for
functions in ES which expect a string as input to perform a conversion
ToString prior to proceeding.
A "correctly-rounded" conversion does seem hand to have.
Both could be provided. I'd suggest Decimal.parse and
Number.toDecimal as names for these two, but I'm not hung up on the
Sleeping on it overnight, having access to such a correctly-rounded
conversion can solve a number of usability concern with the current
approach I've been pursing with respect to mixed mode decimals. It
factors in Mike's use of the word "contagious" and quite possibly
could eliminate the need for Doug's suggestion for "use decimal".
If decimal128 were "contagious" instead of binary64, and all implicit
conversions were correctly and precisely rounded, then no failures or
data loss would occur; instead some excruciatingly precise answers may
result. The fact that decimal operations will tend retain such
precision will contribute to the "contagiousness" of the result. The
programmer could then chose where and when to apply the appropriate
rounding. Or, instead, motivate someone to track down an original
constant which is in dire need of an 'm' suffix.
Such an approach has the nice characteristic that integers whose
absolute value is less than 2**53 would convert exactly.
It is this last observation that would seem to me to dramatically
reduces the the need for Doug's "use decimal" suggestion.
- Sam Ruby
More information about the Es-discuss