* Floating Decimal Package/Library? @ 2002-07-12 17:19 Warren W. Gay VE3WWG 2002-07-12 22:58 ` Robert Wessel ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-12 17:19 UTC (permalink / raw) 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. Thanks, Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-12 17:19 Floating Decimal Package/Library? Warren W. Gay VE3WWG @ 2002-07-12 22:58 ` Robert Wessel 2002-07-12 23:30 ` Dann Corbit 2002-07-13 21:55 ` Björn Lundin 2002-07-17 21:56 ` Waldek Hebisch 2 siblings, 1 reply; 34+ messages in thread From: Robert Wessel @ 2002-07-12 22:58 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D2F0FAB.3000108@cogeco.ca>... > 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. You may be able to find something from here: http://www2.hursley.ibm.com/decimal/ The decNumber package looks like it might meet your requirements, although I don't know how it's licensed: http://www.alphaworks.ibm.com/tech/decNumber ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-12 22:58 ` Robert Wessel @ 2002-07-12 23:30 ` Dann Corbit 2002-07-15 13:34 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 34+ messages in thread From: Dann Corbit @ 2002-07-12 23:30 UTC (permalink / raw) "Robert Wessel" <robertwessel2@yahoo.com> wrote in message news:bea2590e.0207121458.1bf92f6d@posting.google.com... > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3D2F0FAB.3000108@cogeco.ca>... > > 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. > > You may be able to find something from here: > > http://www2.hursley.ibm.com/decimal/ > > The decNumber package looks like it might meet your requirements, > although I don't know how it's licensed: > > http://www.alphaworks.ibm.com/tech/decNumber The numeric type of PostgreSQL supports thousands of digits and is decimal rather than binary. http://www.postgresql.org/idocs/index.php?datatype.html#DATATYPE-NUMERIC Have you tried news:mailing.database.postgresql-novice ? I think you must have never bothered to read the documentation. In case that still does not do it for you, there are bazillions of arbitrary precision packages around. A web search or a gander at the C faq will reveal a boatload of them. -- C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html "The C-FAQ Book" ISBN 0-201-84519-9 C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-12 23:30 ` Dann Corbit @ 2002-07-15 13:34 ` Warren W. Gay VE3WWG 2002-07-16 5:04 ` Robert C. Leif 0 siblings, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-15 13:34 UTC (permalink / raw) Dann Corbit wrote: > "Robert Wessel" <robertwessel2@yahoo.com> wrote in message > news:bea2590e.0207121458.1bf92f6d@posting.google.com... >>"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:<3D2F0FAB.3000108@cogeco.ca>... > >>>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. >>> >>You may be able to find something from here: >> >>http://www2.hursley.ibm.com/decimal/ >> >>The decNumber package looks like it might meet your requirements, >>although I don't know how it's licensed: >> >>http://www.alphaworks.ibm.com/tech/decNumber It is licensed software for a fee, when I checked it last week. Otherwise it looked quite good. > The numeric type of PostgreSQL supports thousands of digits and is decimal > rather than binary. Exactly, just what I was looking for (decimal). But it is available only on the SERVER side. > http://www.postgresql.org/idocs/index.php?datatype.html#DATATYPE-NUMERIC > > Have you tried news:mailing.database.postgresql-novice > ? > > I think you must have never bothered to read the documentation. I have emailed their mailing list to see if they were interested in providing decimal support on the client side, and they said no. Their response was that their code was "server optimized and slow", and that there were no plans to make it available in libpq. > In case that still does not do it for you, there are bazillions of arbitrary > precision packages around. A web search or a gander at the C faq will > reveal a boatload of them. > -- > C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html > "The C-FAQ Book" ISBN 0-201-84519-9 > C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm There are a large number of BINARY arbitrary precision packages -- but I challenge you to find a decimal one. Many support RATIONAL numbers, but not DECIMAL floating point. When doing financial software, you become very interested in DECIMAL calculations. Doing financial calculations in binary floating point means that you are always struggling with the off by one penny problem. Last night, I did manage to extract their server side C code and adapt it. However, if there are better packages available (ie. faster and more complete), I'd be very interersted in hearing about it. TIA, Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-15 13:34 ` Warren W. Gay VE3WWG @ 2002-07-16 5:04 ` Robert C. Leif 2002-07-16 7:01 ` tmoran 0 siblings, 1 reply; 34+ messages in thread From: Robert C. Leif @ 2002-07-16 5:04 UTC (permalink / raw) From: Bob Leif To: Warren W. Gay et al. If the static requirement of Package decimal could be simply circumvented, then one could employ the venerable slide rule formula: Result_Exponent = Numerator_Exponent - Denominator_Exponent Two possible ways to achieve this would be at run time to permit the creation of a new decimal type; or to select a preexisting decimal type. LRM "3.5.9 Fixed Point Types Legality Rules" "In a fixed_point_definition or digits_constraint, the expressions given after the reserved words delta and digits shall be static; their values shall be positive." At present, there is more than enough computing power to permit the use of decimal types where they provide a better model of reality than floating point. In fact, one way to check mathematical libraries would be to perform the same calculation with both floating point and decimal implementations and compare the results. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Warren W. Gay VE3WWG Sent: Monday, July 15, 2002 6:35 AM To: comp.lang.ada@ada.eu.org Subject: Re: Floating Decimal Package/Library? Dann Corbit wrote: > "Robert Wessel" <robertwessel2@yahoo.com> wrote in message > news:bea2590e.0207121458.1bf92f6d@posting.google.com... >>"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:<3D2F0FAB.3000108@cogeco.ca>... > >>>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. >>> >>You may be able to find something from here: >> >>http://www2.hursley.ibm.com/decimal/ >> >>The decNumber package looks like it might meet your requirements, >>although I don't know how it's licensed: >> >>http://www.alphaworks.ibm.com/tech/decNumber It is licensed software for a fee, when I checked it last week. Otherwise it looked quite good. > The numeric type of PostgreSQL supports thousands of digits and is decimal > rather than binary. Exactly, just what I was looking for (decimal). But it is available only on the SERVER side. > http://www.postgresql.org/idocs/index.php?datatype.html#DATATYPE-NUMERIC > > Have you tried news:mailing.database.postgresql-novice > ? > > I think you must have never bothered to read the documentation. I have emailed their mailing list to see if they were interested in providing decimal support on the client side, and they said no. Their response was that their code was "server optimized and slow", and that there were no plans to make it available in libpq. > In case that still does not do it for you, there are bazillions of arbitrary > precision packages around. A web search or a gander at the C faq will > reveal a boatload of them. > -- > C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html > "The C-FAQ Book" ISBN 0-201-84519-9 > C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm There are a large number of BINARY arbitrary precision packages -- but I challenge you to find a decimal one. Many support RATIONAL numbers, but not DECIMAL floating point. When doing financial software, you become very interested in DECIMAL calculations. Doing financial calculations in binary floating point means that you are always struggling with the off by one penny problem. Last night, I did manage to extract their server side C code and adapt it. However, if there are better packages available (ie. faster and more complete), I'd be very interersted in hearing about it. TIA, Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-16 5:04 ` Robert C. Leif @ 2002-07-16 7:01 ` tmoran 2002-07-16 15:50 ` Robert C. Leif ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: tmoran @ 2002-07-16 7:01 UTC (permalink / raw) >>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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-16 7:01 ` tmoran @ 2002-07-16 15:50 ` Robert C. Leif 2002-07-17 1:24 ` tmoran 2002-07-16 16:32 ` Pascal Obry 2002-07-16 17:53 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 34+ messages in thread From: Robert C. Leif @ 2002-07-16 15:50 UTC (permalink / raw) From: Bob Leif To: Tom Moran et al. The problem is not precision. It is the choice of the value for the exponent If I divide X * 10**5 by Y * 10**2, I want the result to be Z * 10**3. This is what I did with a slide-rule 50 years ago! -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of tmoran@acm.org Sent: Tuesday, July 16, 2002 12:02 AM To: comp.lang.ada@ada.eu.org Subject: RE: Floating Decimal Package/Library? >>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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-16 15:50 ` Robert C. Leif @ 2002-07-17 1:24 ` tmoran 2002-07-17 2:53 ` Robert C. Leif 0 siblings, 1 reply; 34+ messages in thread From: tmoran @ 2002-07-17 1:24 UTC (permalink / raw) > > What kind of financial software needs more than 18 decimal digits? > The problem is not precision. It is the choice of the value for the > exponent > > If I divide X * 10**5 by Y * 10**2, I want the result to be Z * 10**3. > This is what I did with a slide-rule 50 years ago! What's the interest, at 4.75% p.a., for the first month of a $10,000 loan. To-the-penny accuracy required. I doubt you could read off all four digits of $39.58 on your slide rule. The slide rule and floating point both have excellent range, but poor precision. You use both because they are, respectively, faster than full precision paper and pencil or a full precision multi-digit arithmetic subroutine package, and because a few digits and an exponent take less paper/RAM. It's a tradeoff of accuracy for speed+space. Unless there's a speed or space problem using full 18 digit decimal numbers, you needn't make that tradeoff - you can cover the entire US GNP and have accuracy to the penny at the same time by using Ada's decimal fixed point types. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-17 1:24 ` tmoran @ 2002-07-17 2:53 ` Robert C. Leif 2002-07-17 4:41 ` tmoran 0 siblings, 1 reply; 34+ messages in thread From: Robert C. Leif @ 2002-07-17 2:53 UTC (permalink / raw) From: Bob Leif To: Tom Moran et al. I do not intend to return to my slide-rule. However, I would like to be able to optimize the precision of my calculations. Since Turkish Lira have been mentioned, when one tries to directly calculate currency equivalents based on the exchange rate between any two currencies, Ada.Decimal did not appear to permit optimizing the exponent of ratios. I admit that this is somewhat contrived and one could be US dollar centric and employ the dollar or one other currency as a common intermediate. Again, I would prefer to use decimals for engineering and scientific calculations. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of tmoran@acm.org Sent: Tuesday, July 16, 2002 6:25 PM To: comp.lang.ada@ada.eu.org Subject: RE: Floating Decimal Package/Library? > > What kind of financial software needs more than 18 decimal digits? > The problem is not precision. It is the choice of the value for the > exponent > > If I divide X * 10**5 by Y * 10**2, I want the result to be Z * 10**3. > This is what I did with a slide-rule 50 years ago! What's the interest, at 4.75% p.a., for the first month of a $10,000 loan. To-the-penny accuracy required. I doubt you could read off all four digits of $39.58 on your slide rule. The slide rule and floating point both have excellent range, but poor precision. You use both because they are, respectively, faster than full precision paper and pencil or a full precision multi-digit arithmetic subroutine package, and because a few digits and an exponent take less paper/RAM. It's a tradeoff of accuracy for speed+space. Unless there's a speed or space problem using full 18 digit decimal numbers, you needn't make that tradeoff - you can cover the entire US GNP and have accuracy to the penny at the same time by using Ada's decimal fixed point types. ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-17 2:53 ` Robert C. Leif @ 2002-07-17 4:41 ` tmoran 2002-07-17 16:30 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 34+ messages in thread From: tmoran @ 2002-07-17 4:41 UTC (permalink / raw) > Since Turkish Lira have been mentioned, when one tries to directly > calculate currency equivalents based on the exchange rate Using Gnat, the program: with Ada.Text_IO; with Ada.Text_IO.Editing; procedure Turk is type Turkish is delta 0.01 digits 18; type US is delta 0.01 digits 18; package Turkish_Output is new Ada.Text_IO.Editing.Decimal_Output(Turkish); package US_Output is new Ada.Text_IO.Editing.Decimal_Output(US); Money_Pic: constant Ada.Text_IO.Editing.Picture := Ada.Text_IO.Editing.To_Picture("-$$_$$$_$$$_$$$_$$$_$$9.99"); Dollars : US := 3_300_000_000.00; Lira : Turkish; begin Lira := Turkish(Dollars * 1097213.08); Ada.Text_IO.Put_Line(US_Output.Image(Dollars, Money_Pic) & Turkish_Output.Image(Lira, Money_Pic)); end Turk; produced: $3,300,000,000.00 $3,620,803,164,000,000.00 Perhaps the IMF's accounting department has a library to go higher, but $3.3 billion should satisfy most of the rest of us. > Again, I would prefer to use decimals for engineering and scientific > calculations. I agree for that you would want floating point decimal. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 4:41 ` tmoran @ 2002-07-17 16:30 ` Warren W. Gay VE3WWG 2002-07-17 22:09 ` tmoran 0 siblings, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-17 16:30 UTC (permalink / raw) tmoran@acm.org wrote: >>Since Turkish Lira have been mentioned, when one tries to directly >>calculate currency equivalents based on the exchange rate >> > Using Gnat, the program: > with Ada.Text_IO; > with Ada.Text_IO.Editing; > procedure Turk is > type Turkish is delta 0.01 digits 18; > type US is delta 0.01 digits 18; > > package Turkish_Output is new Ada.Text_IO.Editing.Decimal_Output(Turkish); > package US_Output is new Ada.Text_IO.Editing.Decimal_Output(US); > > Money_Pic: constant Ada.Text_IO.Editing.Picture > := Ada.Text_IO.Editing.To_Picture("-$$_$$$_$$$_$$$_$$$_$$9.99"); > > Dollars : US := 3_300_000_000.00; > Lira : Turkish; > > begin > Lira := Turkish(Dollars * 1097213.08); > Ada.Text_IO.Put_Line(US_Output.Image(Dollars, Money_Pic) > & Turkish_Output.Image(Lira, Money_Pic)); > end Turk; > produced: > $3,300,000,000.00 $3,620,803,164,000,000.00 > Perhaps the IMF's accounting department has a library to go higher, but > $3.3 billion should satisfy most of the rest of us. Not true. Look at mutual fund holdings, or your bank's, or pension funds. To deal with these kinds of issues, INFORMIX and Oracle (for example) do supply businesses with Decimal library routines for use in applications. This allows them to accurately deal with the precision and exactness of the values involved. Accountants and auditors just blink at you when you try to explain about binary floating point "error". 8-) The example above shows the currency to only 2 decimal places and already uses 18 digits. We typically use 4 or more decimal places, because not all currencies are held to 2 decimal places (especially after conversion). In light of the example above, we already need 20-22 digits. Someone else suggested "why not keep all amounts in dollars?" There are numerous situations where this doesn't work well. One is when you buy a security (stock) on an exchange: you keep on record what you paid for it -- in the currency of that trade. You keep the exchange rate history in a separate table. If you store the trade price amount in dollars, you mix exchange rate and price in one value. This can lead to precision errors (at least for some data types and precision ranges), and it makes life much more complicated for your software. Imagine that the dollar amount is incorrect because the exchange rate was wrong. Now you have to find all trades in that currency, divide out the wrong exchange rate, multiply in the new. Very messy, and the very sort of things that make programmers and auditors alike, cringe. It is much purer as a data model to store price and exchange rate separately and perform currency conversions only when required. This way, if your trade was done in Liras, the amount will be reported on the report precisely, and you can still compute holdings in Canadian or US currency on demand. Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 16:30 ` Warren W. Gay VE3WWG @ 2002-07-17 22:09 ` tmoran 2002-07-29 17:05 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 34+ messages in thread From: tmoran @ 2002-07-17 22:09 UTC (permalink / raw) >> $3.3 billion should satisfy most of the rest of us. >Not true. Look at mutual fund holdings, or your bank's, or >... >The example above shows the currency to only 2 decimal >pension funds. > ... >we already need 20-22 digits. The Turkish GNP is about $200 billion, so another two digits to the left would cover it, ie, you would have to drop fractions of a lira (round to nearest 1/10,000 US cent) to fit. If instead you want to go to 4 digits to the right of the decimal (round to nearest one millionth of a US cent) then yes, you will indeed need 22 digits. I myself would rather go to type Turkish_GNP_Numbers is delta 1_000.0 digits 18; (round to nearest tenth of a US cent) but then I'm not your customer. ;) >To deal with these kinds of issues, INFORMIX >and Oracle (for example) do supply businesses with Decimal Did you check http://www.chez.com/bignumber ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 22:09 ` tmoran @ 2002-07-29 17:05 ` Warren W. Gay VE3WWG 2002-07-29 17:41 ` tmoran 0 siblings, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-29 17:05 UTC (permalink / raw) tmoran@acm.org wrote: ...snip... >>To deal with these kinds of issues, INFORMIX >>and Oracle (for example) do supply businesses with Decimal >> > Did you check http://www.chez.com/bignumber Yep: "It allows computations on big integers, signed or unsigned, and on big fractions." So what this says is integers and rational computations only. Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-29 17:05 ` Warren W. Gay VE3WWG @ 2002-07-29 17:41 ` tmoran 2002-07-30 8:58 ` Jean-Pierre Rosen 2002-07-30 16:20 ` John H. Lindsay 0 siblings, 2 replies; 34+ messages in thread From: tmoran @ 2002-07-29 17:41 UTC (permalink / raw) >> Did you check http://www.chez.com/bignumber >Yep: "It allows computations on big integers, signed or unsigned, >and on big fractions." So what this says is integers and >rational computations only. IIRC you wanted a fixed point representation. A fixed point type *is* an integer. If you want to represent up to a hundred trillion Turkish lira, down to a millionth of a lira, you use an integer count of micro-lira, with the integer having a maximum value of a hundred million trillion micro-liras. Ada's fixed point types are nothing but integers with the compiler handling the scaling. Random question: At what fraction of a lira is the error involved in dropping the rightmost digit of precision less than the cost of the extra electricity to include that digit in calculations? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-29 17:41 ` tmoran @ 2002-07-30 8:58 ` Jean-Pierre Rosen 2002-07-30 16:20 ` John H. Lindsay 1 sibling, 0 replies; 34+ messages in thread From: Jean-Pierre Rosen @ 2002-07-30 8:58 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 573 bytes --] <tmoran@acm.org> a �crit dans le message news: Y6f19.18869$vX4.189933792@newssvr13.news.prodigy.com... > Ada's fixed point types are > nothing but integers with the compiler handling the scaling. And arrays are nothing but an address with the compiler handling the indexing.... Kidding apart, handling the scaling requires care, and having fixed points in the language relieves the programmer from a delicate task. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-29 17:41 ` tmoran 2002-07-30 8:58 ` Jean-Pierre Rosen @ 2002-07-30 16:20 ` John H. Lindsay 1 sibling, 0 replies; 34+ messages in thread From: John H. Lindsay @ 2002-07-30 16:20 UTC (permalink / raw) tmoran@acm.org wrote: > ..... A fixed point type > *is* an integer. Owch! We've got a terminological problem here; Sure, integers (any length or unlimited length) are fixed point in that the decimal (binory, hexadecimal, ....) point (actual or virtual) sits in a position fixed with respect to the units digit or with respect to any fraction digits. But other quantities, dollars and cents amounts and currency conversion and interest rates, and often other commercial numeric quantities with a fixed number of digit places after the decimal point (usually, too, with a fixed number before the decimal point) have this property too. This must be me wearing a COBOL or PL/I hat speaking. The usual work- around in languages that don't have data types which allow a fixed number of digit positions after the decimal point is to carry such quantities as a multiple of the intended value by a power of ten to allow storage as some sort of integer, and (painfully) allowing for the multipliers all through the code. There's a bit of confusion too about the handling of fixed point quantities (of various radices) by compilers. The confusion arises because of two views of the meaning of these -- accurate to within a half a unit of the last digit shown or stored (the usual scientific view if an error range is not stated) or totally accurate as shown (a frequent commercial interpretation). The former view leads to the some of the PL/I type conversion rules; the latter leads to most of the COBOL implementations of handling numeric operations, and COBOL people to gasp at PL/I and PL/I people to sputter over COBOL. John. -- John H. Lindsay jlindsay@kingston.net ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-16 7:01 ` tmoran 2002-07-16 15:50 ` Robert C. Leif @ 2002-07-16 16:32 ` Pascal Obry 2002-07-16 17:53 ` Warren W. Gay VE3WWG 2 siblings, 0 replies; 34+ messages in thread From: Pascal Obry @ 2002-07-16 16:32 UTC (permalink / raw) tmoran@acm.org writes: > >>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. Accounting sofware to manage my personal bank account :) Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-16 7:01 ` tmoran 2002-07-16 15:50 ` Robert C. Leif 2002-07-16 16:32 ` Pascal Obry @ 2002-07-16 17:53 ` Warren W. Gay VE3WWG 2002-07-17 1:24 ` tmoran 2 siblings, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-16 17:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-16 17:53 ` Warren W. Gay VE3WWG @ 2002-07-17 1:24 ` tmoran 2002-07-17 8:28 ` Vadim Godunko 2002-07-17 13:30 ` Warren W. Gay VE3WWG 0 siblings, 2 replies; 34+ messages in thread From: tmoran @ 2002-07-17 1:24 UTC (permalink / raw) > 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, You got the wrong impression. Decimal is implemented as decimal, not binary. type Change_In_My_Pocket is delta 0.01 digits 3; allows values up to $9.99 with one penny precision. type Gates_Tax_Calculations is delta 1.0 digits 11; allows values up to $99 billion with rounding to whole dollars. > 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. Are you aware of the Information Systems Annex? It's there to make decimal accounting programming easy. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 1:24 ` tmoran @ 2002-07-17 8:28 ` Vadim Godunko 2002-07-17 13:32 ` Warren W. Gay VE3WWG 2002-07-17 13:30 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 34+ messages in thread From: Vadim Godunko @ 2002-07-17 8:28 UTC (permalink / raw) > > 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, > You got the wrong impression. Decimal is implemented as > decimal, not binary. GNAT implement decimals as binary fixed point values. Another way to implement fixed point decimals is packed or not packed binary-coded decimals (BCD). Please get agreement with terminology. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 8:28 ` Vadim Godunko @ 2002-07-17 13:32 ` Warren W. Gay VE3WWG 2002-07-22 23:33 ` Robert I. Eachus 0 siblings, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-17 13:32 UTC (permalink / raw) Vadim Godunko wrote: >>>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, >>> >> You got the wrong impression. Decimal is implemented as >>decimal, not binary. >> > GNAT implement decimals as binary fixed point values. Another way to > implement fixed point decimals is packed or not packed binary-coded decimals > (BCD). > Please get agreement with terminology. Are you sure that it is "binary fixed point". Is Robert lurking about here? Thanks, Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 13:32 ` Warren W. Gay VE3WWG @ 2002-07-22 23:33 ` Robert I. Eachus 2002-07-23 13:16 ` Marin David Condic 0 siblings, 1 reply; 34+ messages in thread From: Robert I. Eachus @ 2002-07-22 23:33 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > Are you sure that it is "binary fixed point". Is Robert lurking > about here? You may have been looking for Robert Dewar, but I think I am at least one of the right Roberts to answer this. Ada decimal fixed point types are decimal. Unless you insist on peeking under the covers, you need know nothing else. But if you insist on peeking, read on. Decimal types are implemented as (almost always twos-complement) binary integer representations, with a static divisor that is a power of ten. So if you say: type Dollars is delta 0.01 digits 10; You get a type that can exactly represent hundredths of dollars, and more important, cannot represent any value that is not an exact multiple of one cent. (Or more generally all values of the type must be a multiple of 'Small.) However, there is another thing you may care about. The maximum representable value is not specified for the type Dollars above. The implementation (compiler) may choose any representation as long as all values from -99_999_999.99..99_999_999.99 are exactly representable. But the actual data type may allow larger values. In this case, I would not be surprised if the representation used 64-bit signed integers, and allowed values up to 184_467_440_737_095_516.15. But if you want to restrict the values of the type you can put a range constraint on the type declaration: type Dollars is delta 0.01 digits 10 range -99_999_999.99..99_999_999.99; My recommended approach for Cobol/SQL style programming is to declare most base types like Dollars without a range constraint, and have constrained subtypes: subtype Salary is Dollars range 0.0..10_000_000.00; ...for all database fields. If the underlying database wants to store this as a string, seems wasteful to me but okay. Now for the really gory stuff. What about PostGres support for a thousand digits of floating decimal arithmetic? Chump change. ;-) In Ada the results of certain operations on fixed point types are required to be represented exactly. In practice values of type _universal_fixed_ exist only to make your life easier. (And sometimes the life of the compiler implementor more complex.) For example, in the calculation: Base_Wages := Dollars(Hours_Worked * Base_Pay); Hours_Worked might be represented in tenths of hours and Base_Pay in mills (thousanths of a dollar). Doesn't matter, the result of the multiplication will only be rounded once, to the Dollars type, and will only overflow if the result is outside the bounds of Dollars (or Base_Wages!!!). If you don't want rounding, but truncation to the nearest cent use: Base_Wages := Dollars'Truncation(Hours_Worked * Base_Pay); ...but be sure to check the union contract first. ;-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-22 23:33 ` Robert I. Eachus @ 2002-07-23 13:16 ` Marin David Condic 2002-07-24 15:18 ` Darren New 0 siblings, 1 reply; 34+ messages in thread From: Marin David Condic @ 2002-07-23 13:16 UTC (permalink / raw) More out of curiosity than anything else: Some hardware supports Binary Coded Decimal (BCD) which was there to support Cobol-like numeric values. (Its been a while, but IIRC, the MC680x0 supported it.) I'd suspect that BCD would be suitable for Ada's decimal types. How would this apply here? What would it likely look like under the hood? Would it be a better answer than using some sort of scaled integer? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:3D3C963D.5020304@attbi.com... > > Ada decimal fixed point types are decimal. Unless you insist on peeking > under the covers, you need know nothing else. But if you insist on > peeking, read on. > > Decimal types are implemented as (almost always twos-complement) binary > integer representations, with a static divisor that is a power of ten. > So if you say: ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-23 13:16 ` Marin David Condic @ 2002-07-24 15:18 ` Darren New 2002-07-24 15:43 ` Hyman Rosen 2002-07-24 16:17 ` Fraser Wilson 0 siblings, 2 replies; 34+ messages in thread From: Darren New @ 2002-07-24 15:18 UTC (permalink / raw) Marin David Condic wrote: > > More out of curiosity than anything else: Some hardware supports Binary > Coded Decimal (BCD) which was there to support Cobol-like numeric values. > (Its been a while, but IIRC, the MC680x0 supported it.) The 6502 let you add two BCD digits using a binary add, then had an instruction (adjust decimal?) that would look at the half-carry flag and convert it back to BCD with the appropriate carry bit set. The Sigma-9/Xerox-560 had two optional units, the "scientific unit" (which was a floating point coprocessor) and the "business unit" (which was a BCD processor), either of which would be emulated if not present. The "business unit" had built in instructions for things like COBOL's edit-byte-string. Mmmmm... Text_IO.Editing in hardware! -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** Things to be thankful for, #37: No sausage was served at the Last Supper. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-24 15:18 ` Darren New @ 2002-07-24 15:43 ` Hyman Rosen 2002-07-24 16:17 ` Fraser Wilson 1 sibling, 0 replies; 34+ messages in thread From: Hyman Rosen @ 2002-07-24 15:43 UTC (permalink / raw) Darren New wrote: > The 6502 let you add two BCD digits using a binary add, then had an > instruction (adjust decimal?) that would look at the half-carry flag and > convert it back to BCD with the appropriate carry bit set. The 80x86 processors also have decimal instructions. AA[ASMD] adjust after unpacked decimal operations. DA[AS] adjust after packed decimal operations. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-24 15:18 ` Darren New 2002-07-24 15:43 ` Hyman Rosen @ 2002-07-24 16:17 ` Fraser Wilson 1 sibling, 0 replies; 34+ messages in thread From: Fraser Wilson @ 2002-07-24 16:17 UTC (permalink / raw) Darren New <dnew@san.rr.com> writes: > The 6502 let you add two BCD digits using a binary add, then had an > instruction (adjust decimal?) that would look at the half-carry flag and > convert it back to BCD with the appropriate carry bit set. That's the 8086 I think. The 6502 has a decimal flag in the status word that, when set, causes all add and subtract instructions to treat their arguments as the BCD you mentioned. What an odd feature for a tiny little processor. Fraser. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 1:24 ` tmoran 2002-07-17 8:28 ` Vadim Godunko @ 2002-07-17 13:30 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-17 13:30 UTC (permalink / raw) tmoran@acm.org wrote: >>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, >> > You got the wrong impression. Decimal is implemented as > decimal, not binary. > type Change_In_My_Pocket is delta 0.01 digits 3; > allows values up to $9.99 with one penny precision. > type Gates_Tax_Calculations is delta 1.0 digits 11; > allows values up to $99 billion with rounding to whole dollars. OK, I checked this out last night, and I was wrong about GNAT's implementation. Part of me wanted to wait before I stuck my foot in my mouth.. I now withdraw it. ;-) >>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. >> > Are you aware of the Information Systems Annex? It's there > to make decimal accounting programming easy. GNAT's limitation of 18 digits however, still make some problems difficult to solve. Imagine 4 to 6 decimal positions, leaving 12 digits to represent figures in Turkish Liras. It doesn't leave much head room for further devaluation. Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-12 17:19 Floating Decimal Package/Library? Warren W. Gay VE3WWG 2002-07-12 22:58 ` Robert Wessel @ 2002-07-13 21:55 ` Björn Lundin 2002-07-15 13:37 ` Warren W. Gay VE3WWG 2002-07-17 21:56 ` Waldek Hebisch 2 siblings, 1 reply; 34+ messages in thread From: Björn Lundin @ 2002-07-13 21:55 UTC (permalink / raw) Warren W. Gay VE3WWG 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. PostgreSQL returns everything but binary data as string, as far as I know. Can't you convert as string to what you want? There is a VERY rudimentary PostgreSQL package doing that here: http://home.swipnet.se/lundin/ada_95_tools.html I have a better one, but it's not published yet. But then again, it might not be what you want /Bj�rn ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-13 21:55 ` Björn Lundin @ 2002-07-15 13:37 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-15 13:37 UTC (permalink / raw) Bj�rn Lundin wrote: > Warren W. Gay VE3WWG 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. >> > > PostgreSQL returns everything but binary data as string, as far as I know. > Can't you convert as string to what you want? The string is not the problem. I need a decimal library to do DECIMAL FLOAT arithmetic after I get the result back from the SELECT. I do not want to send arithmetic requests to the server (in a SELECT) -- that would be very expensive. > There is a VERY rudimentary PostgreSQL package doing that here: > http://home.swipnet.se/lundin/ada_95_tools.html > > I have a better one, but it's not published yet. > > But then again, it might not be what you want > /Bj�rn Thanks for trying, but you misunderstand what I was looking for. Warren. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-12 17:19 Floating Decimal Package/Library? Warren W. Gay VE3WWG 2002-07-12 22:58 ` Robert Wessel 2002-07-13 21:55 ` Björn Lundin @ 2002-07-17 21:56 ` Waldek Hebisch 2002-07-18 14:13 ` Robert C. Leif 2002-07-19 17:29 ` Warren W. Gay VE3WWG 2 siblings, 2 replies; 34+ messages in thread From: Waldek Hebisch @ 2002-07-17 21:56 UTC (permalink / raw) 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: floating point is inherently inaccurate so the representation does not matter. 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). For example Tiny Cobol build all its decimal on top of GMP. 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. -- Waldek Hebisch hebisch@math.uni.wroc.pl or hebisch@hera.math.uni.wroc.pl ^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: Floating Decimal Package/Library? 2002-07-17 21:56 ` Waldek Hebisch @ 2002-07-18 14:13 ` Robert C. Leif 2002-07-19 14:41 ` Waldek Hebisch 2002-07-19 17:29 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 34+ messages in thread From: Robert C. Leif @ 2002-07-18 14:13 UTC (permalink / raw) From: Bob Leif To: Waldek Hebisch et al. The point is NOT speed but is accuracy and understandability. Our arithmetic education is based on decimals. Fixed point types including decimal types have the problem of not being able to create a type with an exponent (delta) value calculated at run-time. Either a user formula or a default to the equivalent of floating point could be used for calculating the value of the exponent. This probably is a pain for the compiler writers. However, one of the virtues of Ada is that the compiler writers work to ease the developers' work. A simple example of the use of a floating decimal type is spreadsheets, which should be based on type decimal. -----Original Message----- From: comp.lang.ada-admin@ada.eu.org [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Waldek Hebisch Sent: Wednesday, July 17, 2002 2:56 PM To: comp.lang.ada@ada.eu.org Subject: Re: Floating Decimal Package/Library? 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: floating point is inherently inaccurate so the representation does not matter. 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). For example Tiny Cobol build all its decimal on top of GMP. 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. -- Waldek Hebisch hebisch@math.uni.wroc.pl or hebisch@hera.math.uni.wroc.pl ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-18 14:13 ` Robert C. Leif @ 2002-07-19 14:41 ` Waldek Hebisch 0 siblings, 0 replies; 34+ messages in thread From: Waldek Hebisch @ 2002-07-19 14:41 UTC (permalink / raw) Robert C. Leif (rleif@rleif.com) wrote: : From: Bob Leif : To: Waldek Hebisch et al. : The point is NOT speed but is accuracy and understandability. Our : arithmetic education is based on decimals. Fixed point types including : decimal types have the problem of not being able to create a type with : an exponent (delta) value calculated at run-time. Either a user formula : or a default to the equivalent of floating point could be used for : calculating the value of the exponent. This probably is a pain for the : compiler writers. However, one of the virtues of Ada is that the : compiler writers work to ease the developers' work. A simple example of : the use of a floating decimal type is spreadsheets, which should be : based on type decimal. <snip> My second claim was that using GMP one can make reasonable implementation of fixed point arithmetic, it looks that you agree. My first claim was that floating point is NOT easy to understand (in your sense): its round-off error is very hard to control. Especialy in finacial applications decimal floating point have most of disadvantages of binary arithmetic, with added trap that on "small" numbers all looks ok, and errors kick in only when you have many decimal digits. So I think that binary floating point is easier to understand thentrue decimal floating point, with binary you get burned early and learn that it is inaccurate, with decimal you discover errors much later. And for example IBM PL/1 implemnts decimal floating point just as binary (hexadecimal), while for fixed point uses special decimal hardware instructions. In other words, either you give up precise control over rounding and use floating point, or you specify your rounding policy and use fixed point. This does not exlude posibility to specify precision at run-time, you just must prescribe how much precision you need. -- Waldek Hebisch hebisch@math.uni.wroc.pl or hebisch@hera.math.uni.wroc.pl ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-17 21:56 ` Waldek Hebisch 2002-07-18 14:13 ` Robert C. Leif @ 2002-07-19 17:29 ` Warren W. Gay VE3WWG 2002-07-19 21:50 ` Waldek Hebisch 1 sibling, 1 reply; 34+ messages in thread From: Warren W. Gay VE3WWG @ 2002-07-19 17:29 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Floating Decimal Package/Library? 2002-07-19 17:29 ` Warren W. Gay VE3WWG @ 2002-07-19 21:50 ` Waldek Hebisch 0 siblings, 0 replies; 34+ messages in thread From: Waldek Hebisch @ 2002-07-19 21:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2002-07-30 16:20 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-12 17:19 Floating Decimal Package/Library? Warren W. Gay VE3WWG 2002-07-12 22:58 ` Robert Wessel 2002-07-12 23:30 ` Dann Corbit 2002-07-15 13:34 ` Warren W. Gay VE3WWG 2002-07-16 5:04 ` Robert C. Leif 2002-07-16 7:01 ` tmoran 2002-07-16 15:50 ` Robert C. Leif 2002-07-17 1:24 ` tmoran 2002-07-17 2:53 ` Robert C. Leif 2002-07-17 4:41 ` tmoran 2002-07-17 16:30 ` Warren W. Gay VE3WWG 2002-07-17 22:09 ` tmoran 2002-07-29 17:05 ` Warren W. Gay VE3WWG 2002-07-29 17:41 ` tmoran 2002-07-30 8:58 ` Jean-Pierre Rosen 2002-07-30 16:20 ` John H. Lindsay 2002-07-16 16:32 ` Pascal Obry 2002-07-16 17:53 ` Warren W. Gay VE3WWG 2002-07-17 1:24 ` tmoran 2002-07-17 8:28 ` Vadim Godunko 2002-07-17 13:32 ` Warren W. Gay VE3WWG 2002-07-22 23:33 ` Robert I. Eachus 2002-07-23 13:16 ` Marin David Condic 2002-07-24 15:18 ` Darren New 2002-07-24 15:43 ` Hyman Rosen 2002-07-24 16:17 ` Fraser Wilson 2002-07-17 13:30 ` Warren W. Gay VE3WWG 2002-07-13 21:55 ` Björn Lundin 2002-07-15 13:37 ` Warren W. Gay VE3WWG 2002-07-17 21:56 ` Waldek Hebisch 2002-07-18 14:13 ` Robert C. Leif 2002-07-19 14:41 ` Waldek Hebisch 2002-07-19 17:29 ` Warren W. Gay VE3WWG 2002-07-19 21:50 ` Waldek Hebisch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox