hard proof not to use floating point for currency

5 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Tzadik Vanderhoof

ungelesen,
03.04.2000, 03:00:0003.04.00
an
Can anyone point me to some paper, study, list of examples, or some
other *hard proof* that I can show to management to convince them that
using binary floating point for storage and calculation of monetery
quantities is a Bad Idea? I've painstakingly laid out the reasons
logically... rounding error... inexact representation... pennies not
adding up, etc. and put forward the idea of using some kind of scaled
decimal representation. But that has not worked. I'm thinking some
hard numbers and demonstrations of how it could go wrong would help.

By the way, is there any standard class library for C++ on Windows that
deals with monetery/scaled decimal calculations?

Thanks,

Tzadik


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]


Andrei Alexandrescu

ungelesen,
04.04.2000, 03:00:0004.04.00
an
Go to http://boic.com, then follow their "Base One Number Class" link.


Andrei

Yura Koblents-Mishke

ungelesen,
04.04.2000, 03:00:0004.04.00
an

Tzadik Vanderhoof wrote:
>
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>

"The New is a well forgotten Old".

Exactly for this reason the separate "commercial" and
"scientific" computer models and lines existed in
50-th.

The IBM-360 (1965-68?) was heralded as a breakthrough
"universal" computer line, because its instruction set
(machine level) supported both floating point
arithmetic and the decimal representation, packed with
2 decimal digits per byte. AWAIRemember, though, the
lower models of the IBM-360 series did not support
float: this was considered too expensive, sort of
luxury.

AWAIRemember, Cobol supports the decimal
representation, and very probably mainframe programs
are still using it.

May I suggest, please, to get some IBM mainframe
documentation? An introductory course in "data
processing" or something in this kind.

Francis Glassborow

ungelesen,
04.04.2000, 03:00:0004.04.00
an
In article <8cavou$reo$1...@nnrp1.deja.com>, Tzadik Vanderhoof <tzadikv@my-
deja.com> writes

>Can anyone point me to some paper, study, list of examples, or some
>other *hard proof* that I can show to management to convince them that
>using binary floating point for storage and calculation of monetery
>quantities is a Bad Idea?

If they never care about accounts not balancing to the last cent, do not
expect to trade outside the US, determinedly never want to become a
large company, never wish to trade over the Internet (for what might
become fractions of a cent), and do not expect to survive possible
hyper-inflation or even long enough for ordinary inflation to bite hard
they are probably right. However companies writing software in the
1970's did not expect two figure years would ever be a problem:)


The simple case is, why do it badly if doing it right is not going to be
very expensive.


Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

Michael Tiomkin

ungelesen,
04.04.2000, 03:00:0004.04.00
an
Tzadik Vanderhoof wrote:
>
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetary

> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>
> By the way, is there any standard class library for C++ on Windows that
> deals with monetary/scaled decimal calculations?

I think that just the opposite is true. Recall that with 32-bit integers
the maximal sum you can keep is +-$20M, (2G cents), whereas using a double
as the amount of cents (or whatever is your smallest currency) will allow you
to keep something like $ 2^51 (2^53 cents) in a number. With the amount
of money people get from selling Internet stocks, I'd prefer the last
representation.
Anyway, in some computations you'd rather want to have floating point values,
e.g. interest computation etc.

Good luck!

Michael

Mike Smith

ungelesen,
04.04.2000, 03:00:0004.04.00
an
"Tzadik Vanderhoof" <tza...@my-deja.com> wrote in message
news:8cavou$reo$1...@nnrp1.deja.com...

> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery

> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.

If your managers are this dense, you don't need better proofs; you need a
new job.

--
Mike Smith

There are perhaps 5% of the population that simply *can't* think.
There are another 5% who *can*, and *do*.
The remaining 90% *can* think, but *don't*.
-- R. A. Heinlein

Sam Lindley

ungelesen,
04.04.2000, 03:00:0004.04.00
an
> Go to http://boic.com, then follow their "Base One Number Class" link.

[Since this seems to be patent status of a C++ class, I'm letting it
through, but further discussion concerning the pros and cons of
software patents is NOT on subject, and will be rejected -- mod/jak]

According to the blurb they have a 'U.S. Patent Pending'. Sorry if this is
off topic, but I find it disturbing that someone should even consider
patenting such elementary systems. Yet more evidence of the broken US patent
system.

Seem to remember Martin Fowler describes some money-related patterns in his
book 'Analysis Patterns'.

Sam

Luis Malheiro

ungelesen,
04.04.2000, 03:00:0004.04.00
an

Hmmm... I remember there's a Rogue Wave package for finance, I think is
Money.h++, should work in Windows and Unix.

http://www.roguewave.com

Cheers.

Tzadik Vanderhoof wrote:

> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>

> By the way, is there any standard class library for C++ on Windows
that

> deals with monetery/scaled decimal calculations?

Tzadik Vanderhoof

ungelesen,
04.04.2000, 03:00:0004.04.00
an
Just to play the devil's advocate...

If decimal representation is so important, why did both C and C++ leave
it out of both the language and the "standard libraries"?


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Charles Villa

ungelesen,
04.04.2000, 03:00:0004.04.00
an
I don't have a proof (my managers have been intelligent enough to leave
detailed data formats to the programmers). For Windows with Microsoft tools
you can use COleCurrency. It an 8 byte fixed-point integer with a scale of
1/10,000 (range of 922337203685477.5807 to -922337203685477.5808). There
are probably other implementations that allow larger sized values or
variable size values, but I don't write financial software.

Charles Villa
remove the x's to use the e-mail address

"Tzadik Vanderhoof" <tza...@my-deja.com> wrote in message
news:8cavou$reo$1...@nnrp1.deja.com...

> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>
> By the way, is there any standard class library for C++ on Windows that
> deals with monetery/scaled decimal calculations?
>

> Thanks,
>
> Tzadik

Yura Koblents-Mishke

ungelesen,
04.04.2000, 03:00:0004.04.00
an

Tzadik Vanderhoof wrote:
>
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>

BTW, if all data are represented in cents, not dollars,
it may be really better to use double than int.
On most current computers we have 32-bit ints and longs
are often the same thing as int. ONOH, double is
64-bit. I.e. mantissa by itself, ignoring exp,
precisely represents larger range than int and often
than long.

Kurt Watzka

ungelesen,
04.04.2000, 03:00:0004.04.00
an
Tzadik Vanderhoof <tza...@my-deja.com> writes:

>Can anyone point me to some paper, study, list of examples, or some
>other *hard proof* that I can show to management to convince them that
>using binary floating point for storage and calculation of monetery
>quantities is a Bad Idea?

Or maybe hard proof that the earth is flat, or that man cannot travel
faster than 35 mph because breathing would be impossible at a higher
speed?

Storing currency units in scaled binary floating point representation
might in fact be a very good idea. Whatever can be done exactly with
a scaled decimal representation can be done equally well with a scaled
binary floating point representation.

You are a C++ programmer. Wrap the representation in a CurrencyAmount
class to take care of the trickier aspects, but be sure that
binary floating point representing cents (or whatever your smallest
currency unit is) is not a bad idea per se.

Kurt

--
| Kurt Watzka
| wat...@stat.uni-muenchen.de

Pete Becker

ungelesen,
04.04.2000, 03:00:0004.04.00
an
Tzadik Vanderhoof wrote:
>
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
>

Have you come up with any code examples that run into these problems? In
fact, an IEEE-754 double can represent integral values from -2^53
through 2^53 exactly. For many purposes that's sufficient.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

Robert O'Dowd

ungelesen,
05.04.2000, 03:00:0005.04.00
an
Michael Tiomkin wrote:
>
> Tzadik Vanderhoof wrote:
> >
> > Can anyone point me to some paper, study, list of examples, or some
> > other *hard proof* that I can show to management to convince them that
> > using binary floating point for storage and calculation of monetary

> > quantities is a Bad Idea? I've painstakingly laid out the reasons
> > logically... rounding error... inexact representation... pennies not
> > adding up, etc. and put forward the idea of using some kind of scaled
> > decimal representation. But that has not worked. I'm thinking some
> > hard numbers and demonstrations of how it could go wrong would help.
> >
> > By the way, is there any standard class library for C++ on Windows that
> > deals with monetary/scaled decimal calculations?
>
> I think that just the opposite is true. Recall that with 32-bit integers
> the maximal sum you can keep is +-$20M, (2G cents), whereas using a double
> as the amount of cents (or whatever is your smallest currency) will allow you
> to keep something like $ 2^51 (2^53 cents) in a number. With the amount
> of money people get from selling Internet stocks, I'd prefer the last
> representation.

I wouldn't. The range of floating point values is achieved at a cost
of precision (eg the difference between two consecutive values that
can be represented). I'm sure your accountants would be very unhappy
with being told by their accounting package that

$30M + $1 = $30M

or [a side effect of the above] after starting with $30M and doing
a million transactions of $1 each, that they still have $30M.

[I've pulled the $30M from the air; my point is that at some large
number of cents, the above effects will occur with floating point
representation of currency. And, worse, the set of dollar values
where it will be seen is machine dependent].

As someone else has mentioned, there is also the issue of converting
between currencies. For example, the Australian dollar has
varied in value from over US$0.70 down to just over US$0.60 in
the last couple of years. And then there are different currencies
(eg european, asian) that use a system totally unlike dollars
and cents.

> Anyway, in some computations you'd rather want to have floating point values,
> e.g. interest computation etc.
>

You still need to define the precision at which you do those
computations. Floating point (assuming it supports the
necessary precision for all required cases) is one way of
doing that. It is not the only way --- and can introduce
issues of precision if used carelessly.

Stan Brown

ungelesen,
05.04.2000, 03:00:0005.04.00
an
Said tza...@my-deja.com (Tzadik Vanderhoof) in
comp.lang.c++.moderated:

>Can anyone point me to some paper, study, list of examples, or some
>other *hard proof* that I can show to management to convince them that
>using binary floating point for storage and calculation of monetery

>quantities is a Bad Idea? I've painstakingly laid out the reasons
>logically... rounding error... inexact representation... pennies not
>adding up, etc. and put forward the idea of using some kind of scaled
>decimal representation. But that has not worked.

I don't understand. You've explained to management that the numbers
will be inaccurate, and they still want to go ahead?

Maybe it would be appropriate to ask them why they want floating
point. If you could find out their real requirement, maybe you
could find a way to meet it.

I suppose it would be out of place to suggest that you won't try to
manage the company if they don't try to make every last decision in
programming. <grin>

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
more FAQs: http://www.mindspring.com/~brahms/faqget.htm

Cees Roos

ungelesen,
05.04.2000, 03:00:0005.04.00
an

"Pete Becker" <peteb...@acm.org> schreef in bericht
news:38EA5552...@acm.org...

> Tzadik Vanderhoof wrote:
> >
> > Can anyone point me to some paper, study, list of examples, or some
> > other *hard proof* that I can show to management to convince them that
> > using binary floating point for storage and calculation of monetery
> > quantities is a Bad Idea? I've painstakingly laid out the reasons
> > logically... rounding error... inexact representation... pennies not
> > adding up, etc. and put forward the idea of using some kind of scaled
> > decimal representation. But that has not worked. I'm thinking some
> > hard numbers and demonstrations of how it could go wrong would help.
> >
>
> Have you come up with any code examples that run into these problems? In
> fact, an IEEE-754 double can represent integral values from -2^53
> through 2^53 exactly. For many purposes that's sufficient.
>
I think the cause of potential trouble is not in the capacity of
the representation, but in the proper rounding.
The software handling the monetary calculations should ensure
that any time a float is used to represent a monetary value,
it should be rounded to the proper number of the smallest fraction
used in the currency involved, i.e. amounts in US$ should be
represented as integral numbers of US$ cents.
Using a float for that representation can have efficiency advantages
because it eliminates casts to float values and the reverse, during
the processing of monetary values. Final results should be rounded
to integral numbers.
--
Regards, Cees Roos
I think it's much more interesting to live not knowing than
to have answers which might be wrong. R. Feynman 1981

David Ferguson

ungelesen,
05.04.2000, 03:00:0005.04.00
an
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.
I don't know of any studies. As an alternative you might be able to come up
with a small program that would demonstrate one or more flaws.

As a compromise you might begin development with a simple Money class, using
double for the implementation. A more robust implementation could be
substituted later.

> By the way, is there any standard class library for C++ on Windows that

> deals with monetery/scaled decimal calculations?
Here are some libraries to consider. If you have time to review them I
would be interested in your findings.

GNU MP is a 'C' library for arbitrary precision arithmetic, operating on
signed integers, rational numbers, and floating point numbers. It claims to
be very fast.
http://www.gnu.org/software/gmp/gmp.html

BIGINT - N-bit integer math class
http://www.rossi.com/sqr2.htm

MAPM is a 'C' library for arbitrary precision integer/floating point math
http://www.tc.umn.edu/~ringx004/mapm-main.html

The LEDA Research project has a large integer class
http://www.mpi-sb.mpg.de/LEDA/index.html
http://www.mpi-sb.mpg.de/LEDA/MANUAL/integer.html

There are several multiprecision libraries listed here:
http://www.oonumerics.org/oon/#libraries
Multiprecision, arbitrary precision data types
NTL Arbitrary length integers, vectors/matrices/polynomials
over integers and over finite fields.

EXTNUM Version of double which has the same number of mantissa
bits as IEEE 754, but extends the exponent to have range
from 10^-646456993 to 10^646456992.

CLN An extensive number library. Arbitrary precision
integer, float, rational, polynomials, complex, modular
integers, transcendental functions, assembly language
kernels for some CPUs.

MPFUN++ A multiple precision floating point computation package in
C++.

LiDIA A library for computational number theory. Provides a
collection of highly optimized implementations of various
multiprecision data types and time-intensive algorithms.

Apfloat A C++ High Performance Arbitrary Precision Arithmetic
Package

hfloat An arbitrary precision package, optimized for very large
(> 1000) (decimal) digit numbers.

fPoint A C++ class which helps convert floating-point
arithmetic to fixed-point arithmetic by recommending
range and precision requirements.

doubledouble A quad-precision (approximately 30 decimal place)
floating point arithmetic class.

I hope your project goes well.
Cheers...David

Francis Glassborow

ungelesen,
06.04.2000, 03:00:0006.04.00
an
In article <38EA2337...@pop3.concentric.net>, Yura Koblents-Mishke
<yu...@concentric.net> writes

>BTW, if all data are represented in cents, not dollars,
>it may be really better to use double than int.
>On most current computers we have 32-bit ints and longs
>are often the same thing as int. ONOH, double is
>64-bit. I.e. mantissa by itself, ignoring exp,
>precisely represents larger range than int and often
>than long.

But ideally you should consider using either a BigInt type or a
specifically created currency type that did not suffer from an arbitrary
precision limit.

Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Hyman Rosen

ungelesen,
06.04.2000, 03:00:0006.04.00
an
Tzadik Vanderhoof <tza...@my-deja.com> writes:
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea?

Try running this program in front of them -

#define test(v1,op,v2) if (v1 op v2) printf(#v1 " " #op " " #v2 "\n")
#include <stdio.h>
#include <math.h>
int main()
{
volatile double a, b, c;
char buf[50];

a = 13.06;
b = 0.54;
sprintf(buf, "%f", a + b);
c = atof(buf);

test(c,>,13.60);
test(c,==,13.60);
test(c,<,13.60);
test(a + b,>,13.60);
test(a + b,==,13.60);
test(a + b,<,13.60);

return 0;

Tzadik Vanderhoof

ungelesen,
06.04.2000, 03:00:0006.04.00
an

> BTW, if all data are represented in cents, not dollars,
> it may be really better to use double than int.
> On most current computers we have 32-bit ints and longs
> are often the same thing as int. ONOH, double is
> 64-bit. I.e. mantissa by itself, ignoring exp,
> precisely represents larger range than int and often
> than long.

Understood, but it's exactly this point they're resisting. They want
the amounts in floating-point dollars.


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Tzadik Vanderhoof

ungelesen,
06.04.2000, 03:00:0006.04.00
an
In article <MPG.135488709...@news.mindspring.com>,

bra...@mindspring.com (Stan Brown) wrote:
> Said tza...@my-deja.com (Tzadik Vanderhoof) in
> comp.lang.c++.moderated:
> >Can anyone point me to some paper, study, list of examples, or some
> >other *hard proof* that I can show to management to convince them
that
> >using binary floating point for storage and calculation of monetery
> >quantities is a Bad Idea? I've painstakingly laid out the reasons
> >logically... rounding error... inexact representation... pennies not
> >adding up, etc. and put forward the idea of using some kind of scaled
> >decimal representation. But that has not worked.
>
> I don't understand. You've explained to management that the numbers
> will be inaccurate, and they still want to go ahead?
>
> Maybe it would be appropriate to ask them why they want floating
> point. If you could find out their real requirement, maybe you
> could find a way to meet it.
>
> I suppose it would be out of place to suggest that you won't try to
> manage the company if they don't try to make every last decision in
> programming. <grin>

Their problem is that it is already partially written using floating
point. BTW some posters seem to be assuming that the floating points
I'm talking about are representing cents. This is not the case. I
would have no problem if that were the case. What they're doing is
using floating point to represent dollars.

Saiid

ungelesen,
06.04.2000, 03:00:0006.04.00
an

Hyman Rosen <hy...@prolifics.com> wrote in message
news:t78zysc...@calumny.jyacc.com...

> Tzadik Vanderhoof <tza...@my-deja.com> writes:
> > Can anyone point me to some paper, study, list of examples, or some
> > other *hard proof* that I can show to management to convince them that
> > using binary floating point for storage and calculation of monetery
> > quantities is a Bad Idea?
>

Here is another program that might also convince them:

#include <stdio.h>
#include <math.h>

int main()
{

float newAmount = (float)1.0;
float prevAmount = (float)0.0;
int count = 0;

while (newAmount != prevAmount)
{
count++;
prevAmount = newAmount;
newAmount += (float)0.01;
}

printf("Started out with $1.00\n");
printf("Added a penny %d number of times, or $%f.\n",count, (float)(count /
100.0));
printf("We now have $%f <----- ?????\n",newAmount);
printf("Lets add $1,000,000 more, one penny at a time:\n");

for (int i=1; i<=100000000; i++)
newAmount += (float)0.01;

printf("This is how much we have now $%f <----- ?????\n",newAmount);

return 0;
}

~Saiid Paryavi

Pierre Baillargeon

ungelesen,
06.04.2000, 03:00:0006.04.00
an
Tzadik Vanderhoof wrote:
>
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea?

While I have no study to provide, you can use the following argument.
The problem with floating point is that the point is floating. Numbers
with different magnitudes (10 billions vs 0.00001) have precision down
to different units. Thus at *every* calculation made, you have to prove
that the representation (floating point) provides sufficient precision
for each number for all possible value of each number at any time. It
can be done, but:

1- it takes time.
2- it requires specific assumption about magnitude of each number.
3- it is very hard to test (must take point 2 values and test it).
4- it must be redone every time you change your values.

So it is much better to *at least* encapsulate the floating point in a
class where you have a single point where to insert your assumptions and
tests.

The second point is that not all numbers have an exact representation.
That problem is harder to test even in a class. With a fixed point
representation, the precision and representability can be established
once for all numbers.

In short, floating point saves on design time (costs zero), but costs in
testing, debugging and possible support.

NeilB

ungelesen,
06.04.2000, 03:00:0006.04.00
an
Stan Brown <bra...@mindspring.com> wrote in message
news:MPG.135488709...@news.mindspring.com...

> Said tza...@my-deja.com (Tzadik Vanderhoof) in
> comp.lang.c++.moderated:
> >Can anyone point me to some paper, study, list of examples, or some
> >other *hard proof* that I can show to management to convince them
that
> >using binary floating point for storage and calculation of monetery
> >quantities is a Bad Idea? I've painstakingly laid out the reasons
> >logically... rounding error... inexact representation... pennies not
> >adding up, etc. and put forward the idea of using some kind of scaled
> >decimal representation. But that has not worked.
>
> I don't understand. You've explained to management that the numbers
> will be inaccurate, and they still want to go ahead?
>

For many analytic financial applications, small errors don't matter. For
example, I once worked on a risk management system where the average
trade
value was in the millions of UKP. The fact that we used floating point
to
represent the trade values meant that we might be out by a few pounds,
but
that didn't matter.

> Maybe it would be appropriate to ask them why they want floating
> point. If you could find out their real requirement, maybe you
> could find a way to meet it.

I doubt that this is their reason, but floating point ops on some modern
chips can be faster than integer ops! I think Kernighan's latest book
"The
Practice Of Programming" has some examples, but I don't have my copy to
hand
at the moment.

> I suppose it would be out of place to suggest that you won't try to
> manage the company if they don't try to make every last decision in
> programming. <grin>

I am always shocked & appalled by the Dilbertesque tendencies of _some_
managers. However, there are others (like me, when I'm in a management
role
:-)) who do know what they are talking about.

NeilB

Pete Becker

ungelesen,
06.04.2000, 03:00:0006.04.00
an
Cees Roos wrote:
>
> "Pete Becker" <peteb...@acm.org> schreef in bericht
> news:38EA5552...@acm.org...
> > Tzadik Vanderhoof wrote:
> > >
> > > Can anyone point me to some paper, study, list of examples, or
some
> > > other *hard proof* that I can show to management to convince them
that
> > > using binary floating point for storage and calculation of
monetery
> > > quantities is a Bad Idea? I've painstakingly laid out the reasons
> > > logically... rounding error... inexact representation... pennies
not
> > > adding up, etc. and put forward the idea of using some kind of
scaled
> > > decimal representation. But that has not worked. I'm thinking
some
> > > hard numbers and demonstrations of how it could go wrong would
help.
> > >
> >
> > Have you come up with any code examples that run into these
problems? In
> > fact, an IEEE-754 double can represent integral values from -2^53
> > through 2^53 exactly. For many purposes that's sufficient.
> >
> I think the cause of potential trouble is not in the capacity of
> the representation, but in the proper rounding.
> The software handling the monetary calculations should ensure
> that any time a float is used to represent a monetary value,
> it should be rounded to the proper number of the smallest fraction
> used in the currency involved, i.e. amounts in US$ should be
> represented as integral numbers of US$ cents.
> Using a float for that representation can have efficiency advantages
> because it eliminates casts to float values and the reverse, during
> the processing of monetary values. Final results should be rounded
> to integral numbers.

Yes, that's all generically true, but it is nevertheless also true that
53 bits are sufficient for many purposes. For example, if you're logging
deposits to and withdrawals from a bank account you're not dealing with
fractional cents, so rounding isn't an issue.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Robert O'Dowd

ungelesen,
06.04.2000, 03:00:0006.04.00
an

If by "proper rounding" you mean ensuring calculations are
done to adequate precision, I agree. Of course, this assumes
that integral values in the range -2^53->2^53 are adequate
for your application and that IEEE floating point representation
is available with every compiler/operating system your
application is targetted at.

> The software handling the monetary calculations should ensure
> that any time a float is used to represent a monetary value,
> it should be rounded to the proper number of the smallest fraction
> used in the currency involved, i.e. amounts in US$ should be
> represented as integral numbers of US$ cents.
> Using a float for that representation can have efficiency advantages
> because it eliminates casts to float values and the reverse, during
> the processing of monetary values. Final results should be rounded
> to integral numbers.

The question, which again depends on your application, is
when should that happen. Let's say we wish to compute interest
charges over a six month period on a $100000 mortgage, at 6.95% per
annum interest compounded daily, with payments of $471 fortnightly.

Given that there are a lot of daily interest charges, the
choice of when to round can affect the profit received
by the lender. Doing the rounding every day will give
a different result than doing the calculations over a
6 month period and then rounding. The differences, although
relatively small, can cause conflict between lender and
the person paying the loan.

Jens Kilian

ungelesen,
06.04.2000, 03:00:0006.04.00
an
Tzadik Vanderhoof <tza...@my-deja.com> writes:
> Can anyone point me to some paper, study, list of examples, or some
> other *hard proof* that I can show to management to convince them that
> using binary floating point for storage and calculation of monetery
> quantities is a Bad Idea? I've painstakingly laid out the reasons
> logically... rounding error... inexact representation... pennies not
> adding up, etc. and put forward the idea of using some kind of scaled
> decimal representation. But that has not worked. I'm thinking some
> hard numbers and demonstrations of how it could go wrong would help.

Let them indemnify you, in writing, from any losses they or customers
will
incur due to rounding inaccuracies. Then go ahead with what they tell
you.
They'll notice their mistake when you start driving to work in a brand
new
Ferrari.

--
mailto:j...@acm.org phone:+49-7031-464-7698 (HP TELNET
778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a
fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible.
[Blake]

Tzadik Vanderhoof

ungelesen,
06.04.2000, 03:00:0006.04.00
an
WOW.... [eyes popping open and jaw hanging down] Now THAT's what I've
been looking for! This example is particularly striking since it deals
with such small values and only 2 decimal places and it uses only
addition.

Thanks!!! (BTW, how did you come up with those numbers?)

Tzadik


In article <t78zysc...@calumny.jyacc.com>,


Hyman Rosen <hy...@prolifics.com> wrote:
> Tzadik Vanderhoof <tza...@my-deja.com> writes:
> > Can anyone point me to some paper, study, list of examples, or some
> > other *hard proof* that I can show to management to convince them
that
> > using binary floating point for storage and calculation of monetery
> > quantities is a Bad Idea?
>

> Try running this program in front of them -
>
> #define test(v1,op,v2) if (v1 op v2) printf(#v1 " " #op " " #v2 "\n")

> #include <stdio.h>
> #include <math.h>
> int main()
> {

> volatile double a, b, c;
> char buf[50];
>
> a = 13.06;
> b = 0.54;
> sprintf(buf, "%f", a + b);
> c = atof(buf);
>
> test(c,>,13.60);
> test(c,==,13.60);
> test(c,<,13.60);
> test(a + b,>,13.60);
> test(a + b,==,13.60);
> test(a + b,<,13.60);
>
> return 0;
> }
>

> [ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
> [ about comp.lang.c++.moderated. First time posters: do this! ]
>
>

--

Tzadik


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Mark Ping

ungelesen,
07.04.2000, 03:00:0007.04.00
an
In article <8cavou$reo$1...@nnrp1.deja.com>,

Tzadik Vanderhoof <tza...@my-deja.com> wrote:
>Can anyone point me to some paper, study, list of examples, or some
>other *hard proof* that I can show to management to convince them that
>using binary floating point for storage and calculation of monetery
>quantities is a Bad Idea? I've painstakingly laid out the reasons
>logically... rounding error... inexact representation... pennies not
>adding up, etc. and put forward the idea of using some kind of scaled
>decimal representation. But that has not worked. I'm thinking some
>hard numbers and demonstrations of how it could go wrong would help.

Check the February issue of the C++ Report. It has an entire article
devoted to "Comparing Floats." Or look for David Goldberg's article,
"What Every Computer Scientist Should Know About Floating-Point
Arithmetic", ACM Computing Surveys 23(1):5-48, March 1991.

They're actually both good articles to read anyway, but if that
doesn't convince them how much *each* developer needs to understand
before using floats, I don't know what will (I found a postscript
version of the second article at:
http://www.validgh.com/goldberg/paper.ps)
--
The above comments represent my opinion only, and in no way
reflect the opinions or policy of Intel Corp.

Mark Ping mp...@scdt.intel.com

Ron Bass

ungelesen,
07.04.2000, 03:00:0007.04.00
an
On 6 Apr 2000 06:43:50 -0400, Tzadik Vanderhoof <tza...@my-deja.com>
wrote:

>> Said tza...@my-deja.com (Tzadik Vanderhoof) in
>> comp.lang.c++.moderated:

>> >Can anyone point me to some paper, study, list of examples, or some
>> >other *hard proof* that I can show to management to convince them
>that
>> >using binary floating point for storage and calculation of monetery
>> >quantities is a Bad Idea? I've painstakingly laid out the reasons
>> >logically... rounding error... inexact representation... pennies not
>> >adding up, etc. and put forward the idea of using some kind of scaled
>> >decimal representation. But that has not worked.
>

>Their problem is that it is already partially written using floating
>point. BTW some posters seem to be assuming that the floating points
>I'm talking about are representing cents. This is not the case. I
>would have no problem if that were the case. What they're doing is
>using floating point to represent dollars.

In this case, you are SOL. If they don't understand that cents cannot
be accurately represented using binary fractions of dollars, and they
have trusted the design to coders who also don't understand this, then
they are making a statement that the code will never be used for
audit-able account maintenance. This isn't a C++, or software
engineering problem. It's a business decision problem. I recommend
that you start looking for a job with a real business.

Good Luck!

-Ron
--
"Anything worth doing is worth doing poorly at first."
Robert Downey, Jr.

Cees Roos

ungelesen,
07.04.2000, 03:00:0007.04.00
an

"Robert O'Dowd" <nos...@nonexistant.com> schreef in bericht
news:38EBCEB6...@nonexistant.com...

> Cees Roos wrote:
> >
> > "Pete Becker" <peteb...@acm.org> schreef in bericht
> > news:38EA5552...@acm.org...
[snip]

> > > Have you come up with any code examples that run into these
> problems? In
> > > fact, an IEEE-754 double can represent integral values from -2^53
> > > through 2^53 exactly. For many purposes that's sufficient.
> > >
> > I think the cause of potential trouble is not in the capacity of
> > the representation, but in the proper rounding.
>
> If by "proper rounding" you mean ensuring calculations are
> done to adequate precision, I agree.
>
That's not what I mean. I mean that amounts should be
represented in intergral numbers of the smallest unit of the
currency involved.

Even in that case it will be necessary for the used algorithm to
define the exact number of decimal places to be used for interim
results, and to ensure that any amount involved will be expressed
in integral numbers of the smallest unit in that definition.

--
Regards, Cees Roos
I think it's much more interesting to live not knowing than
to have answers which might be wrong. R. Feynman 1981

Cees Roos

ungelesen,
07.04.2000, 03:00:0007.04.00
an

"Pete Becker" <peteb...@acm.org> schreef in bericht
news:38EBC835...@acm.org...
> Cees Roos wrote:
> >
[snip]

> > Using a float for that representation can have efficiency advantages
> > because it eliminates casts to float values and the reverse, during
> > the processing of monetary values. Final results should be rounded
> > to integral numbers.
>
> Yes, that's all generically true, but it is nevertheless also true
that
> 53 bits are sufficient for many purposes. For example, if you're
logging
> deposits to and withdrawals from a bank account you're not dealing
with
> fractional cents, so rounding isn't an issue.
>
It would be no issue if two decimal place fractions could always be
accurately expressed in binary digital fractions.
Look at the example program by Hyman Rosen to see what
kind of an issue it is.
Look also what happens when you rewrite it to read:

#define test(v1,op,v2) if (v1 op v2) printf(#v1 " " #op " " #v2 "\n")
#include <stdio.h>
#include <math.h>
int main()
{
volatile double a, b, c;
char buf[50];

a = 1306.0;
b = 054.0;


sprintf(buf, "%f", a + b);
c = atof(buf);

test(c,>,1360.0);
test(c,==,1360.0);
test(c,<,1360.0);
test(a + b,>,1360.0);
test(a + b,==,1360.0);
test(a + b,<,1360.0);
return 0;
}


> --
> Pete Becker

Pete Becker

ungelesen,
08.04.2000, 03:00:0008.04.00
an
Cees Roos wrote:
>
> "Pete Becker" <peteb...@acm.org> schreef in bericht
> news:38EBC835...@acm.org...
> > Cees Roos wrote:
> > >
> [snip]
> > > Using a float for that representation can have efficiency advantages
> > > because it eliminates casts to float values and the reverse, during
> > > the processing of monetary values. Final results should be rounded
> > > to integral numbers.
> >
> > Yes, that's all generically true, but it is nevertheless also true
> that
> > 53 bits are sufficient for many purposes. For example, if you're
> logging
> > deposits to and withdrawals from a bank account you're not dealing
> with
> > fractional cents, so rounding isn't an issue.
> >
> It would be no issue if two decimal place fractions could always be
> accurately expressed in binary digital fractions.

If you count cents instead of dollars you don't have fractions here.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

ka...@gabi-soft.de

ungelesen,
09.04.2000, 03:00:0009.04.00
an
Tzadik Vanderhoof <tza...@my-deja.com> writes:

|> Just to play the devil's advocate...

|> If decimal representation is so important, why did both C and C++
leave
|> it out of both the language and the "standard libraries"?

Because decimal representation is only important for commercial
software, and C didn't target this area. In the case of C++, of course,
the type would probably be in a standard library. Which nobody
proposed.

--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

ka...@gabi-soft.de

ungelesen,
09.04.2000, 03:00:0009.04.00
an
"Robert O'Dowd" <nos...@nonexistant.com> writes:

|> Michael Tiomkin wrote:

|> > Tzadik Vanderhoof wrote:

|> > > Can anyone point me to some paper, study, list of examples, or
|> > > some other *hard proof* that I can show to management to
|> > > convince them that using binary floating point for storage and

|> > > calculation of monetary quantities is a Bad Idea? I've


|> > > painstakingly laid out the reasons logically... rounding
|> > > error... inexact representation... pennies not adding up,
|> > > etc. and put forward the idea of using some kind of scaled

|> > > decimal representation. But that has not worked. I'm thinking
|> > > some hard numbers and demonstrations of how it could go wrong
|> > > would help.

|> > > By the way, is there any standard class library for C++ on
|> > > Windows that deals with monetary/scaled decimal calculations?

|> > I think that just the opposite is true. Recall that with 32-bit
|> > integers the maximal sum you can keep is +-$20M, (2G cents),
|> > whereas using a double as the amount of cents (or whatever is your
|> > smallest currency) will allow you to keep something like $ 2^51
|> > (2^53 cents) in a number. With the amount of money people get
|> > from selling Internet stocks, I'd prefer the last representation.

|> I wouldn't. The range of floating point values is achieved at a
|> cost of precision (eg the difference between two consecutive values
|> that can be represented).

Correct. But his suggestion wasn't to use the entire range of double
(typically 1e302, or something similar), but just the range where it
could represent integer values (of cents) exactly. On most modern
machines, and int is 32 bits, which gives 31 bits precision, whereas a
double is 64 bits, with 52 bits precision.

The Rogue Wave money.h++ package has an option to use this
implementation for its decimal arithmetic. On machines with IEEE
double, for the range it guarantees, it produces exactly the same
results as full decimal arithmetic, often at a significant speed
improvement.

Obviously, such a strategy requires care, especially in operations which
involve rounding and fractional cents, such as interest calculations, so
that the results are the same. But it can be done, and on many
machines, it is worth it for the performance gains.

|> I'm sure your accountants would be very
|> unhappy with being told by their accounting package that

|> $30M + $1 = $30M

|> or [a side effect of the above] after starting with $30M and doing
|> a million transactions of $1 each, that they still have $30M.

|> [I've pulled the $30M from the air; my point is that at some large
|> number of cents, the above effects will occur with floating point
|> representation of currency. And, worse, the set of dollar values
|> where it will be seen is machine dependent].

They'd be even less happy to learn that $21474836.47 + $0.01 =
-$21474836.48. Which is the result when using int's on my machine.
Both representations (and in fact, any fixed size representation) will
fail when values leave an acceptable range. As it happens, your example
will work correctly for double, but not for int (on my machine).

The trick in using double is to limit the range to that where integral
values are exact.

|> As someone else has mentioned, there is also the issue of converting
|> between currencies. For example, the Australian dollar has varied
|> in value from over US$0.70 down to just over US$0.60 in the last
|> couple of years. And then there are different currencies (eg
|> european, asian) that use a system totally unlike dollars and cents.

Luckily, we no longer have to worry about the old imperial system:-).
All of monitary systems I'm familar with use a decimal representation,
although in some (like Italian Lira), the cents are ignored.

|> > Anyway, in some computations you'd rather want to have floating
|> > point values, e.g. interest computation etc.

|> You still need to define the precision at which you do those
|> computations. Floating point (assuming it supports the necessary
|> precision for all required cases) is one way of doing that. It is
|> not the only way --- and can introduce issues of precision if used
|> carelessly.

When dealing with monetary values, the precision is generally defined by
national law, which imposes standard bookkeeping practice. And for most
simple operations, like adding, subtracting and multiplying, the
required precision is exact. Which effectively limits the range
floating point can be used to a very small subset of its normal range.
On a typical machine, float can be used up to 6 digits (pretty useless),
double to 15 or 16 (often sufficient).

ka...@gabi-soft.de

ungelesen,
09.04.2000, 03:00:0009.04.00
an
"Robert O'Dowd" <nos...@nonexistant.com> writes:

|> > The software handling the monetary calculations should ensure that
|> > any time a float is used to represent a monetary value, it should
|> > be rounded to the proper number of the smallest fraction used in
|> > the currency involved, i.e. amounts in US$ should be represented

|> > as integral numbers of US$ cents. Using a float for that


|> > representation can have efficiency advantages because it
|> > eliminates casts to float values and the reverse, during the
|> > processing of monetary values. Final results should be rounded to
|> > integral numbers.

|> The question, which again depends on your application, is


|> when should that happen. Let's say we wish to compute interest
|> charges over a six month period on a $100000 mortgage, at 6.95% per
|> annum interest compounded daily, with payments of $471 fortnightly.

In most countries, there are laws which define the exact rounding
procedure to be used. These laws are based on decimal rounding -- at
least in all cases I've ever heard of. This can be done using double,
but it requires care: here for example, you would probably want to
multiply by 695 to calculate the interest, and continue the operations
in the larger units. At the end, you would see if the value, modulo
10000, was >= 5000, and use that as a basis for rounding. Only after
having rounded would you rescale by dividing by 10000.

Tzadik Vanderhoof

ungelesen,
10.04.2000, 03:00:0010.04.00
an
Thanks! The paper and the examples were just what I was looking for!
Thanks again!

Tzadik

In article <8cirla$r...@news.or.intel.com>,


mp...@scdt.intel.com (Mark Ping) wrote:
> In article <8cavou$reo$1...@nnrp1.deja.com>,

> Tzadik Vanderhoof <tza...@my-deja.com> wrote:
> >Can anyone point me to some paper, study, list of examples, or some
> >other *hard proof* that I can show to management to convince them
that

> >using binary floating point for storage and calculation of monetery


> >quantities is a Bad Idea? I've painstakingly laid out the reasons
> >logically... rounding error... inexact representation... pennies not
> >adding up, etc. and put forward the idea of using some kind of scaled
> >decimal representation. But that has not worked. I'm thinking some
> >hard numbers and demonstrations of how it could go wrong would help.
>

> Check the February issue of the C++ Report. It has an entire article
> devoted to "Comparing Floats." Or look for David Goldberg's article,
> "What Every Computer Scientist Should Know About Floating-Point
> Arithmetic", ACM Computing Surveys 23(1):5-48, March 1991.
>
> They're actually both good articles to read anyway, but if that
> doesn't convince them how much *each* developer needs to understand
> before using floats, I don't know what will (I found a postscript
> version of the second article at:
> http://www.validgh.com/goldberg/paper.ps)
> --
> The above comments represent my opinion only, and in no way
> reflect the opinions or policy of Intel Corp.
>
> Mark Ping mp...@scdt.intel.com
>

- --

Tzadik


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Allen antworten
Dem Autor antworten
Weiterleiten
0 neue Nachrichten