I wrote:
    > Many financial calculations *MAY* be done safely using floating point.

I basically gave two reasons:
 A.  Double-precision floating-point arithmetic (especially IEEE
    floating-point arithmetic) is exact for a useful range of numbers
    (it gives you more than 32-bit integers, not as much as 64-bit ones)
 B.  There are calculations that are *financial* in that they are about
     money and involve financial institutions where approximation is
     entirely harmless.  I made the point that it's necessary to
     distinguish between accounting applications which must keep accurate
     track of actual money and other calculations which happen to involve
     money.

"Lex Spoon" <lex at cc.gatech.edu> wrote (re point A):
	Yes, but of course you need to count in cents, shillings, ore, or
	whatnot, which defeats the purpose most people have of using floating
	point to begin with: to get free support for things after the decimal
	point.
	
I can't speak for "most people".  I can only speak for me.
And from my point of view, these facts about modern machines
are more interesting:

(1) floating-point +, -, *, and / have higher throughput than
    the same integer operations
(2) on super-scalar machines (that is, ALL the machines I have ready
    access to these days), doing data calculations in FP means that
    the addressing calculations are free to tie up the integer unit,
    so the overall calculations go twice as fast.
(3) it's easier to set up the FP unit to trap on inexact answers
    than it is to make C code trap on integer overflow.
(4) they come with C, Fortran, Pascal, Ada &c compilers which do NOT
    support high-precision integers, but MIGHT support 96-bit or
    128-bit 'long double'.  (The machine I'm typing on supports 128-
    bit long double in software, but it's _there_ and I can use it
    without too much pain.)

	So, I think you would agree that people doing financial calculations
	should still default to using integers, even if their language has
	floating point numbers just begging to be used.

No I would not.

I *do* agree that people doing ACCOUNTING applications that have to
keep track of actual money should use good precision exact arithmetic.
Anyone else remember the Burroughs 2500/3500/4500 with their decimal
arithmetic for up to 99 digits?  Only machine I've ever come across
where the Fortran compiler offered you 99-decimal-digit floats.  If
you have a language which supports exact arithmetic on decimal fixed point
numbers (COBOL, PL/I, Ada 95) there's not the least reason for anyone to
force their numbers into integer form.

This of course is where Smalltalk ScaledDecimal comes in; why force your
data into Integer format when there is an existing class that lets you
say what you mean?  Should I understand you as saying that Smalltalk
programmers who have a working ScaledDecimal should _still_ use integers
for all 'financial' calculations?

There are plenty of FINANCIAL applications (market analysis, forecasting,
your imagination is the limit) where floating-point is exactly right even
though it's approximate.

Basically, people who don't know what they are doing and have to use
a language that doesn't directly support what they need should be
asking for help, not given advice 'always use integers' that makes them
_think_ they know what they are doing.

Floating-point arithmetic may be inexact, but at least unlike most
implementations of C it's less likely to quietly give you results that
are off by 2**32.
	
If you want to argue that you meant 'Integer' not 'integer', why yes,
which is why it's such a pity that Java doesn't integrate BigInteger
and BigDecimal into the language.

	Such people *can* use floating point, but it is unlikely to help
	them, and it has gotchas involved.
	
	Heheh, reminds me of my favorite exception to the rule "just don't use
	floating point": graphics.  The generalization is: "if you don't really
	care what the answer comes out to, then floating point is fine."
	
That's hardly fair.  (Especially now that Fortran includes the INTERVAL
types, and now that the Fortran compiler I use supports this.)
	
	I would pick 10 digits or so as the default.  Then, newbies who are just
	screwing around will get what they expect.  People who want IEEE
	floating-point should have to do something a little different.
	
Yike.  You must _really_ hate beginners who try to use floats.
I've known a program be completely thrown off by the fact that the
floating-point numbers and library it used were 96-bit (SANE on a Mac)
but the version of pi that had been compiled in was 64 bit.  This
kind of mismatch does no-one any favours.

	"Float pi" is a disturbing example at first: should it return
	pi-for-newbies or pi-as-float ?

Well, Float pi must *surely* return pi-as-Float, because that's what you
asked for.  Float pi should be the best approximation to pi you can fit
in a Float.  Float pi should only return pi-for-newbies if Float is
Float-for-newbies.

Give someone some kind of ScaledDecimal by default, and they will _still_
trip over the fact that (2 sqrt) is not exact.  Or, for that matter, the
fact that '7.5% compound interest per year' does not have an exact equivalent
per month.  (Aren't calculations involving compound interest 'financial'?)