Re: Floating Decimal Package/Library?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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.