I wrote:

	> Except decimal floats.  Addition, subtraction, and multiplication of
	> in-range numbers stated in decimal with in-range results are *exact*.
	> We *really* want the new IEEE standard, don't we?
	
>From some other comemnts I have seen, I should emphasise that the decimal
arithmetic in the new IEEE standard is *not* based on BCD, and should be
able to go nearly as fast as binary arithmetic.  It has a slightly greater
range than IEEE binary arithmetic, and really, the only defect it has
relative to IEEE binary arithmetic is the 'wobbling precision' problem that
affects any base other 2.  Given the kluges Microsoft have layered on top
of IEEE binary arithmetic, corrupting the results of Excel calculations to
avoid surprising the naive, the sooner we get decent decimal arithmetic in
our hardware the better for everyone using spreadsheets.  Less surprise
with *no* fiddling with the results of the hardware.

"Jarvis, Robert P. (Bob) (Contingent)" <bob.jarvis at timken.com> wrote:
	While it certainly sounds like an improvement, I think this is more of a
	band-aid than a fix.  As soon as you exceed the precision of a floating
	point number, be it binary or decimal, you have the situation where a
	comparison like
	
		f = f + 1.0
	
	answers 'true', at which point the auditors and lawyers will want to have a
	word.

You need to remember that not everyone is an American.
This country has 4 million people (including infants).
Let them each have 20 million dollars (please! start with me!).
Keep all money accounts in cents.
The sum fits in 53 bits; this amount can be represented exactly in
IEEE arithmetic.

It is true that not ALL financial calculations can be done using
floating point.
It is also true that if your language supports 64-bit integer arithmetic
(and COBOL has long had a minimum requirement of 18 decimal digits, and
C these days has 'long long') you get an even bigger accurate range by
using integers than floats.

Many financial calculations *MAY* be done safely using floating point.

As I said before, there are more than a few calculations where
the use of floating point will give the auditors and lawyers nothing
to complain of.  Their concern is that you should keep accurate records
of *actual* sums of money which have passed through your hands.  However,
projections, forecasts, statistical analyses, data mining, all that kind
of stuff may legitimately use approximations.

	My choice, if I was given one, would be to get rid of floating
	point entirely and replace it with some form of
	unlimited-precision scaled decimal.

Horses for courses.  I don't know if you've ever tried doing any serious
matrix calculations in a symbolic algebra package like Macsyma or
Reduce, but if you haven't you'd be *amazed* how fast
unlimited-precision arithmetic can fill your memory up.  There are
calculations where you have exact inputs and exact algorithms so exact
results are appropriate.  There are also calculations where you have
approximate inputs and approximate algorithms so that approximate
results are appropriate.  Smalltalk is one of the few languages that
offers BOTH.  (Java of course has java.math.BigInteger and
java.math.BigDecimal, corresponding to Large{Positive,Negative}Integer
and ScaledDecimal, more or less.  There doesn't seem to be anything like
Fraction, though.)


Oddly enough, a few minuets after I posted in this thread yesterday,
I received a message in the Clean mailing list, where someone's problem
was precisely an inappropriate equality test on floating point numbers.

We agree that people _should_ avoid floating-point equality tests unless
they know exactly what they are doing.  Maybe I'm a bit over-sensitive
here, but I have seen people who should have known better so scared by
advice that they never really had explained to them that they were
advocating the removal of floating-point comparison from a language I
cared about.  That's going too far.  Adults are allowed to use sharp knives.