From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,7cda96e9413b780c X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,7cda96e9413b780c X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,7cda96e9413b780c X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2002-07-19 10:34:48 PST Message-ID: <3D384C88.9060806@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: Floating Decimal Package/Library? References: <3D2F0FAB.3000108@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Jul 2002 13:29:44 -0400 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1027099784 198.96.47.195 (Fri, 19 Jul 2002 13:29:44 EDT) NNTP-Posting-Date: Fri, 19 Jul 2002 13:29:44 EDT Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:27251 comp.lang.c:139508 comp.lang.c++:160077 Date: 2002-07-19T13:29:44-04:00 List-Id: 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. 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)! 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. > 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. 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). > 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). 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. > 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! For fun, try the simple test program below. There are obviously more sophisticated tests one could try, but this is a simple one (hash totals). When the program runs, the output looks something like this: $ ./eg Decimal Total = 9000.0000 Float Total = 8.99728E+03 $ Then modify the program to use Fixed point binary and try it again. Warren. -- This code assumes GNAT is being used with Ada.Text_IO; use Ada.Text_IO; procedure Eg is type Decimal is delta 0.0001 digits 18; V : Decimal := 0.3; Total : Decimal := 0.0; F : Float := 0.3; F_Total : Float := 0.0; begin for X in 1..30000 loop Total := Total + V; end loop; Put_Line("Decimal Total =" & Total'Img); for X in 1..30000 loop F_Total := F_Total + F; end loop; Put_Line(" Float Total =" & F_Total'Img); end Eg;