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: 109fba,7cda96e9413b780c X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,7cda96e9413b780c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-19 14:50:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.mailgate.org!newsfeed.stueberl.de!news-mue1.dfn.de!news-fra1.dfn.de!news.man.poznan.pl!pwr.wroc.pl!panorama.wcss.wroc.pl!hebisch From: hebisch@math.uni.wroc.pl (Waldek Hebisch) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: Floating Decimal Package/Library? Followup-To: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 19 Jul 2002 21:50:13 GMT Organization: Politechnika Wroclawska Message-ID: References: <3D2F0FAB.3000108@cogeco.ca> <3D384C88.9060806@cogeco.ca> NNTP-Posting-Host: hera.math.uni.wroc.pl X-Trace: panorama.wcss.wroc.pl 1027115413 1787 156.17.86.1 (19 Jul 2002 21:50:13 GMT) X-Complaints-To: abuse@news.pwr.wroc.pl NNTP-Posting-Date: 19 Jul 2002 21:50:13 GMT X-Newsreader: TIN [version 1.2 PL2] Xref: archiver1.google.com comp.lang.ada:27253 comp.lang.c:139563 comp.lang.c++:160121 Date: 2002-07-19T21:50:13+00:00 List-Id: 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. Been there ... -- Waldek Hebisch hebisch@math.uni.wroc.pl or hebisch@hera.math.uni.wroc.pl