Floating Point and Financial Software

There seem to be a few mini-flames on the list over whether
floating point data representations are appropriate for financial
software.

In a nutshell, the answer is "YES", and the use of floating point
arithmetic is common in such applications.

One argument heard against the use of floating point is that it
is inherently "imprecise." In reality, floating point
representations and the results of floating point operations are
perfectly well defined, and the points on the real number line
which are exactly representable by double-precision floating
point values are usually a superset of those representable by the
default integer on most machines.

Storing monetary values as double-precision floats having integer
values in cents is even common in COBOL programs, where the
"COMP-3" data type allows the use of fast floating point in lieu
of the default and slow manipulation of packed decimal and
decimal data.

It is even common in certain CPUs, like CDC Mainframes and
SPARCS, which are primarily floating point engines, to omit
integer divide and sometimes even multiply, and to provide a
subroutine which employs floating point calculations to emulate
these operations. This is completely transparent to the user of
the machine, and there is no problem in using floating point to
do integer operations.

In fact, when running financial applications on large engineering
mainframes, which generally lack a business instruction set,
floating point is not only commonly employed, it is the obvious
way to get the maximum performance out of the machine.

--
     Mike Duvos         $    PGP 2.6 Public Key available     $
     mpd@netcom.com     $    via Finger.                      $

Mike Duvos writes:
> There seem to be a few mini-flames on the list over whether
> floating point data representations are appropriate for financial
> software.
> 
> In a nutshell, the answer is "YES", and the use of floating point
> arithmetic is common in such applications.

Again, I have seen floating point used for things like rates and in
simulations. I have never seen it used for accounting. If you can
name a system in which accounts were kept in floats I'd like to hear
about it -- personally I'd be surprised. I've never seen such a thing.

.pm

per@oiemont.com writes:
>Again, I have seen floating point used for things like rates and in
>simulations. I have never seen it used for accounting. If you can
>name a system in which accounts were kept in floats I'd like to hear
>about it -- personally I'd be surprised. I've never seen such a thing.

I don't think its all that uncommon....

The Options Clearing Corporation does all of their clearing in 64  
bit floats, for one.
Most market making firms (read not a huge bank, clearing risk of  
less than say 50 mil) tend to do their accounting (both in house,  
and inventory (derivative instrument inventory) )in packages written  
in dos which mostly do 32 bit floats -
Swiss Bank/O'connor, NationsBank/CRT, Fannie Mae, Merril Lynch use  
NeXT's as their trading platform so you can rest assured that they  
are using 64's

The Federal Reserve Bank, European Ecomonic Community, England,  
France, Germany, Japan, Canada, etc store their historical data in a  
time series database called FAME, which does 64 bit representation  
of floating point data....

Once you get down into the 10000th's of a us penny it really  
doesn't matter anymore...

--Kurt

Kurt Vile writes:
> The Federal Reserve Bank, European Ecomonic Community, England,  
> France, Germany, Japan, Canada, etc store their historical data in a  
> time series database called FAME, which does 64 bit representation  
> of floating point data....

FAME is NOT an accounting package. I'm talking about accounting. 

> The Options Clearing Corporation does all of their clearing in 64  
> bit floats, for one.

Options are traded in integral units. Why would they use floats for
counting them?

> Swiss Bank/O'connor, NationsBank/CRT, Fannie Mae, Merril Lynch use  
> NeXT's as their trading platform so you can rest assured that they  
> are using 64's

1) Most of those firms have used *some* NeXT machines, none have used
   them exclusively. (My friends who were at Swiss Bank used HPs. My
   friends at M-L use Suns). In any case, it doesn't matter. Why would
   the native floating point representation of the machine have
   anything to do with accounting? Most of the accounting in those
   firms wasn't ever done on their trading platforms at all anyway --
   many of them still do all their accounting on mainframes, and
   whether they use mainframes or not they tend to write their
   accounting on top of database packages that have exact numerical
   representations available for money. The accounting systems are in
   any case back office systems, not front office systems, and have
   nothing to do with the trading platforms.

Perry

While I wont argue the veracity of floating point use in financials, I 
will make a point or two for your consideration.

The basic issue in the micro world has been imprecision - primarily due 
to word size (8 and 16 bit). Frankly I view it more as a pain tolerance 
to estimation. 

Now that 32 and 64 processors are handy (yes the 80 bit x87 has been 
around for a while), it becomes more of an issue of hair splitting. 

I never incorporate floating point into any of the financial software I 
have written over the years, primarily just on a matter of principle. 
Secondly, since most of it was written to the Intel platform (read 
washing machine controller), there is a very distinct advantage in doing 
integer only from purely a performance basis.

As to acuracy. Normally it doesn't matter when the rounding error sits 
some 18 to 23 decimal places out, when you are calculating dollars and 
cents, but many of the calculations I have been forced to endure center 
around such mathematical abuses as compound interest. Here, it is not 
only probably, but expected to work thousands of recalculations in a 
series, with each building upon the last. Rounding error grows very 
quickly in these types of circumstances. However, just to be fair, there 
is a plethora of business math done in software that limits itself from 
one to several recalcs, and the accuracy only needs to be to the penny or 
at worst 4 to 6 decimal places out.

Even Intel can handle this.... :-)

>From alt.humor.pentium:

DId you hear that Intel has found a home for all those pentiums with the 
floating point error ? They sold them to Mattel.

Now when you pull Barbie's string, she says "Math is hard..."

...Paul (politically incorrect and loving it..)

On Wed, 22 May 1996, Mike Duvos wrote:

> There seem to be a few mini-flames on the list over whether
> floating point data representations are appropriate for financial
> software.
> 
> In a nutshell, the answer is "YES", and the use of floating point
> arithmetic is common in such applications.
> 
> One argument heard against the use of floating point is that it
> is inherently "imprecise." In reality, floating point
> representations and the results of floating point operations are
> perfectly well defined, and the points on the real number line
> which are exactly representable by double-precision floating
> point values are usually a superset of those representable by the
> default integer on most machines.
> 
> Storing monetary values as double-precision floats having integer
> values in cents is even common in COBOL programs, where the
> "COMP-3" data type allows the use of fast floating point in lieu
> of the default and slow manipulation of packed decimal and
> decimal data.
> 
> It is even common in certain CPUs, like CDC Mainframes and
> SPARCS, which are primarily floating point engines, to omit
> integer divide and sometimes even multiply, and to provide a
> subroutine which employs floating point calculations to emulate
> these operations. This is completely transparent to the user of
> the machine, and there is no problem in using floating point to
> do integer operations.
> 
> In fact, when running financial applications on large engineering
> mainframes, which generally lack a business instruction set,
> floating point is not only commonly employed, it is the obvious
> way to get the maximum performance out of the machine.
> 
> --
>      Mike Duvos         $    PGP 2.6 Public Key available     $
>      mpd@netcom.com     $    via Finger.                      $
> 
> 

-------------------------------------------------------------------------

"Faced with the choice between changing one's mind and proving that there
 is no need to do so, almost everybody gets busy on the proof"

                                            -- John Kenneth Galbraith

"Success is attending a funeral as a spectator"

                                            -- E. BonAnno 

-------------------------------------------------------------------------