Adobe position paper on the ECMAScript 4 proposal space -- decimal
Mike Cowlishaw
MFC at uk.ibm.com
Mon Mar 3 07:25:55 PST 2008
"Igor Bukanov" <igor at mir2.org> wrote on 03/03/2008 14:39:32:
> On 27/02/2008, Brendan Eich <brendan at mozilla.org> wrote:
> ...
> > I agree with what Lars wrote, except here I think the value of a
> > hypothetical (possibly mythical) "big red switch" is understated.
> ...
> >The common problem is that you can't do "dollars
> > and cents" or "pounds and pennies" arithmetic and get the "right
> > answer":
> >
> > js> 74.96-39.96
> > 34.99999999999999
>
> The problem here is not the binary float arithmetics but rather the
> conversion of numbers into strings. If a global switch would exist
> that would make a default toString conversion to use a particular
> version of toFixed, the problem would disappear for most user cases.
That's unfortunately not true. Not only is the required toFixed number
unpredictable in many applications, but it may give the wrong answer even
when known. See item 2 at:
http://www2.hursley.ibm.com/decimal/decifaq1.html#inexact
(This particular problem is systematic, and it adds up to around $2M for a
medium-sized telco. That misplaced $2M is cheating either the
shareholders, the customers, or the taxman. None of those options look
good in a newspaper report :-).)
Hiding a wrong answer by rounding makes problems worse, because the errors
accumulate unseen.
> Moreover, decimal floats does not help much when calculating a VAT or
> similar taxes. In many countries that requires explicit rounding to
> cents, øre etc. of the final result with a particular minimal
> precision in the intermediate calculations. Such requirements can be
> meet both with decimal and binary floats.
The IEEE 754r description of decimal floating-point allows for this (as do
the implementations). If a requirement for an intermediate or final
precision is defined as a number of decimal digits (as in Euro
conversions, for example), this cannot in general be done accurately in
binary floating-point.
> For example, in Norway shops almost always show a price that includes
> VAT. Typically the prices are round numbers or in those x9(9) formats.
> Then the price excluding VAT is calculated using devisions and
> included into the receipt using toFixed(2). Thus with either decimal
> or binary floats the rounding is inevitable.
The rounding is inevitable, but the rounding you get using binary
floating-point is different to decimal because there is no base-5
component available. (See the item referred to at the URL above.)
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 Es4-discuss
mailing list