On Sat, Aug 23, 2008 at 4:49 AM, Mike Cowlishaw <[EMAIL PROTECTED]> 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 > exact). > > 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 names. 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 _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
