Re: float decimal

Nick Maclaren wrote:
In article <cmjj44-8pe.ln1@xxxxxxxxxxxxxxxxxxxxxxx>,
Terje Mathisen <terje.mathisen@xxxxxxxxxxxxx> writes:
|> Mike Cowlishaw wrote:
|> > |> > The DFP arithmetic in the 754r draft is exactly that: unnormalized
|> > scaled integers (whether these are internally BCD or binary is
|> > irrelevant). The big difference from fixed-point math is that the
|> > scale (exponent) is handled automatically for the programmer (so 1.2
|> > x 1.2 gives 1.44 not 1.4), and so until you 'run out' of precision,
|> > results are exact (after which the arithmetic degrades gracefully
|> > into the usual fixed-precision floating-point).
|> |> That _is_ good.

Well, it would be if it were true :-(

Consider the sort of code that you might well write to multiply two
fixed-point numbers with 2 digits, rounding according to the usual
convention:

C = INTPT(100.0*A*B+0.5)/100.0

Now work out what happens if the operations overflows in fixed-point,
and the 'graceful' degradation occurs. 'Tain't pretty, even with a
simple rounding rule (let alone IEEE 754R's).

For currency calculations, the _only_ possible way to handle this is to trap any inexact operations, i.e. you ad better make sure you work with a number type which is large enough to cover any possible legal input/result.

Several languages have numeric types that automatically extends from a fast integer type to bignum in case of overflow, this seems like a useful approach.

The 34-digit (128 bit right?) BCD FP type _should_ be enough, just like 640 K once upon a time. :-)

Terje
--
- <Terje.Mathisen@xxxxxxxxxxxxx>
"almost all programming can be viewed as an exercise in caching"
.