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: 103376,7cda96e9413b780c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-16 11:05:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!torn!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3D345DB3.5080609@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 Subject: Re: Floating Decimal Package/Library? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Jul 2002 13:53:55 -0400 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1026842017 198.96.47.195 (Tue, 16 Jul 2002 13:53:37 EDT) NNTP-Posting-Date: Tue, 16 Jul 2002 13:53:37 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:27157 Date: 2002-07-16T13:53:55-04:00 List-Id: tmoran@acm.org wrote: >>>When doing financial software, you become very interested >>> >>If the static requirement of Package decimal could be simply circumvented >> > What kind of financial software needs more than 18 decimal digits? > 18 digits allows 9,999 trillion dollars to one cent precision. First of all, I need a data type that can manage the data being stored by the PostgreSQL data column type "decimal" (or "numeric"), which is arbitrary precision (at least to a point -- 1000 digits or so). Secondly, if you perform any computations in a binary floating point data type and think that 18 digits of precision is going to compensate for the binary nature of the calculation, then you are showing your ignorance of the difference between binary floating point calculations and decimal ones. You'll have to do your own homework on this. Systems that are written to use binary floats for accounting purposes, always leave the programmer with the joy all of those "off by one penny" errors. Even a simple hash total can become a major challenge because of rounding problems that add to the error over 1000's of records. Without naming names, I know of a specific instance where one financial company cannot always get the hash totals right in their hash total record. Most of the time it works, but occaisionally it will be out by one. Decimal totals make this perfectly easy to accomplish. And this is just speaking of a summing process. What I've ended up doing for now is to cut the PostgreSQL decimal code out of the engine and mangle it for my own use (with Ada binding in the works). Its not a perfect solution, but it works. Finally, I should mention that I am using GNAT. Unless I am mistaken, it seemed that the decimal support wasn't exactly decimal (I'd have to go back and recheck, but I got the impression that it is implemented in binary floating point). If it truly is implemented in decimal, then I'd like to know about it (I have other reasons to care about this). Oh, one more thing.. how many Turkish Liras does the amount "9,999 trillion dollars" come to? Well, let's see: You'd have to multiply that number by 1,089,334.54877 today (assuming the former figure was Canadian $). Its not a totally unmanageable number, but it starts to huge if you want to be precise about it. Warren.