Adobe position paper on the ECMAScript 4 proposal space -- decimal

Mike Cowlishaw MFC at
Mon Mar 3 07:25:55 PST 2008

"Igor Bukanov" <igor at> wrote on 03/03/2008 14:39:32:

> On 27/02/2008, Brendan Eich <brendan at> 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:

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


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 Es4-discuss mailing list