Floating Decimal Package/Library?

Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[Robert Wessel]

"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

Re: Floating Decimal Package/Library?

[Dann Corbit]

"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

Re: Floating Decimal Package/Library?

[Björn Lundin]

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

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

RE: Floating Decimal Package/Library?

[Robert C. Leif]

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.

RE: Floating Decimal Package/Library?

[tmoran]

>>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.

RE: Floating Decimal Package/Library?

[Robert C. Leif]

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.

Re: Floating Decimal Package/Library?

[Pascal Obry]

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

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[tmoran]

> 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.

RE: Floating Decimal Package/Library?

[tmoran]

> > 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.

RE: Floating Decimal Package/Library?

[Robert C. Leif]

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.

RE: Floating Decimal Package/Library?

[tmoran]

> 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.

Re: Floating Decimal Package/Library?

[Vadim Godunko]

> > 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.

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[Waldek Hebisch]

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 

Re: Floating Decimal Package/Library?

[tmoran]

>> $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

RE: Floating Decimal Package/Library?

[Robert C. Leif]

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 

Re: Floating Decimal Package/Library?

[Waldek Hebisch]

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 

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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;

Re: Floating Decimal Package/Library?

[Waldek Hebisch]

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 

Re: Floating Decimal Package/Library?

[Robert I. Eachus]

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. ;-)


 

Re: Floating Decimal Package/Library?

[Marin David Condic]

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:

Re: Floating Decimal Package/Library?

[Darren New]

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.

Re: Floating Decimal Package/Library?

[Hyman Rosen]

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.

Re: Floating Decimal Package/Library?

[Fraser Wilson]

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.

Re: Floating Decimal Package/Library?

[Warren W. Gay VE3WWG]

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.

Re: Floating Decimal Package/Library?

[tmoran]

>>   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?

Re: Floating Decimal Package/Library?

[Jean-Pierre Rosen]

[-- 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

Re: Floating Decimal Package/Library?

[John H. Lindsay]

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