Re: Floating Decimal Package/Library?

[hebisch@math.uni.wroc.pl (Waldek Hebisch)]

Warren W. Gay VE3WWG (ve3wwg@cogeco.ca) wrote:
: Waldek Hebisch wrote:

: > Warren W. Gay VE3WWG (ve3wwg@cogeco.ca) wrote:
: > : Since the PostgreSQL group have expressed no
: > : interest in supporting floating decimal
: > : routines for the client, I wonder if anyone
: > : in these groups know of an Ada package (preferred),
: > : or C/C++ library that supports arbitrary
: > : prcecision floating decimal values. I could
: > : hack the PostgreSQL back end C routines, but
: > : this may not be practical.
: > 
: > : The GNU GMP library comes close, but its
: > : floating support library uses binary
: > : arithmetic (this is a no-no for financial
: > : work). I've suggested that they augment GMP
: > : with this support, but I'm not sure what
: > : response I'll get to the request.
: > 
: > : I am looking for a PD/GPL/Open Sourced work.
: > 
: > Well, decimal floating point is an oxymoron: 


: This is not true. Floating point decimal, does
: have a precision limitation, yes. No question. However,
: it does offer superior accuracy in that numbers
: like 0.3 can be represented accurately. This permits
: perfectly accurate summing, at least until the
: precision fails to carry enough digits.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
That is the point: with binary floating point if you care to 
have any spare precision (abave of what is required to acomodate 
errors, if you sum 1000 numbers than four additional digits is 
enough) and round at the end, then you get perfect results. 
Typicaly, when you use fixed point you want to get an exception
to save you from the error (or a estimating errors)
: Binary floating point OTOH, does not sum numbers like
: 0.3 accurately. This is because the representation
: of numbers like 0.3 are an approximation to begin with.
: > floating 
: > point is inherently inaccurate so the representation 
: > does not matter. 


: Again, this is not true. If you add two numbers within
: the same exponential range, in decimal, you get a
: precise result.  This is precisely what your $2.95
: calculator does (floating point and all)!
Well, you say: if floating point is the same as fixed point
then I get correct result.

: OTOH, this is not necessarily true with binary floating
: point, because rounding and approximation must be
: used for numbers like 0.3.  If you sum several 0.3
: in binary floats (or fixed point), the total will
: eventually accumulate enough error to throw the result
: off.
It is VERY unlikely that you will sum so easy numbers. And even in that 
case if you have 12 digit (~40 bit mantissa) binary floating point and 
say 9-digit decimal floating point then binary will resonably sum 
1 000 000 000 times before serious errors wil appear. And 
in decimal floating point you will get massive error (think what happens
if you add 0.3 to 123456789.0 with 9 digits of accuracy ...). If you take 
more complicated numbers (with more digits) errors will appear much 
earlier but again the format with more digits will win. You may think 
that comparison is unjust, but both formats are likely to require the 
same amount of storage and binary is likely to be more time efficient. 
And well: did you think that decimal may give you so much error?


: > What you want is fixed point arithmetic.
: > Fixed point is not hard to do once you have arbitrary 
: > precision integers (for integers again binary versus decimal 
: >  does not matter). 


: Fixed point does make a difference, also. If you try to
: create a hash total of fractional values in a
: binary fixed point system, then you will experience
: similar round off errors in the total (for example, the
: total will often be right, but will occaisionally be off
: by one because of round off errors and approximations
: with numbers like 0.3).

: It never ceases to amaze me
: how many programmers seem to be unaware of these issues.
Well, sorry, I assumed that it is clear that I mean decimal 
fixed point implemented using binary integers (like implementation 
used by GNAT).

: Decimal based systems do not have to approximate
: decimal values like 0.3 (these are represented
: precisely). So provided you do not overflow the
: fixed point decimal precision, you ALWAYS have a
: precisely correct total (for example).
Well, if you take exception on overflow than you are
sure that normal computation gives correct result.

: > For example Tiny Cobol build all its 
: > decimal on top of GMP. 


: Of course one way to compensate for the 0.3 problem,
: is to internally move the decimal point in order to
: work with the values as integers (and then rescale
: at the end).
Yes, exactly.

: Probably what they're (Tiny Cobol) doing is using
: rational arithmetic in GMP, which
: keeps everything as a numerator/denominator pair
: until the final result is required. This is probably
: good enough in many cases, but I remain skeptical
: about it being perfectly good enough. The problem
: is deferred until the very end where a "rounding"
: must occur. It is the rounding (to compensate for
: the error) that creates all of the trouble.
Well, they are NOT using GMP rationals. If you remember
grade school (in US maybe high school), then you will
recall that decimal are also called decimal fractions:
denominator has to be power of 10. If you work with 
fixed precision, there is no need to store denominator,
it will not change. If you change precision, then it 
is enough to store exponent insted of whole denominator 
-- one may call it floating point, but even though all
thing are stored in binary it is decimal (remember, NO
current computer is trurly decimal, the closest thing
is BCD, where you code digits in binary). 
When you talk about rounding at the end: yes it is a 
problem, but a problem for decimal: you must decide 
how much intermediate digits should be kept, how much 
rounded (truncated). Typical solution (probably mandated 
by COBOL) is to calculate expressions with maximal precison
and rounding on assignment. 

: > One may be concerned with 
: > efficency of such implementation, but I think that 
: > on binary machines 20-30 digit decimal arithmetic 
: > cannot be really fast.


: When financial computations are done, there is usually

: no desire to worry about efficiency. It is more important
: to be correct!  Otherwise an awful lot of wasted time
: is spent looking for where that stupid missing penny
: went!
Agreed.

: For fun, try the simple test program below. 
<snip>
Been there ...


--
                              Waldek Hebisch
hebisch@math.uni.wroc.pl    or hebisch@hera.math.uni.wroc.pl