You are mostly agreeing with me, so this was a weird email to read.

Just to try and make some sense of the thread, I will admit that I was
not thinking of people doing CPU-heavy financial forecasts when I
recomended that they use integers.  CPU-straining applications are ever
more infrequent in these days of gigahertz desktop machines, but for
those rare cases they exist, I'm sure floating point is a godsend.  In
that case, though, you probably won't be relying on the fact that your
floats are giving you exact scaled integer operations.  Instead, you are
going down the rathole of floating point algorithms and numeric
analysis.  Expect to spend a lot of human time getting it right.

Also, if someone is lucky enough to have a ScaledDecimal class around,
then yes, they may as well use that instead of integers.  What I object
to is people using Float's as a substitute for ScaledDecimal.



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

If they use integers, then what they know will remain true.  All the
usual mathematical identities for integers are also true for computer
integers.  Do you have any gotchas in mind?

Overflow is a potential issue if you are using C, but come on, why use
C??  I thought this thread was about good programming practices.  :)

Finally, I agree that it is great for people to learn ever more, but it
is also good if they can get by without *having* to know as much. 
Floating point arithmetic has some interest, but for the time required
to really learn it, I'm not sure it's worth it for many people.  I've
taken one college class on it at this point and would still be extremely
wary of doing anything with it where the results matter.

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

It seems exactly on target.  You keep saying that I am assuming too
quickly that people want accurate answers.  Fine, I admit it: if you
don't want accurate answers, then by all means use floating point.  This
seems exceptional, though.  How often do people compute something and
not care whether the answer is correct?

Anyway, I'm happy to include a second exception, for people who have
spent a year or more studying floating point algorithms.


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

You are agreeing with me.  All I am saying is that the IEEE stuff does
not need to be what you get by default.  In fact, if you really care
about the fiddly details, then it is probably better that the code be
explicit anyway and not simply accept the defaults.




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

Yes, I am glad you agree.


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

Yes, but these are issues irrespective of the implementation.  You
probably have to understand that some square roots are not integers, if
you are going to be doing computations involving square roots.  Likewise
for the interest calculation.  It is nice if, once you understand the
issues, your implementation technique does not add any *new* issues. 
Floating point both adds new issues--understanding how the roundoffs are
working--and tempts you to implement things badly by just ignoring the
roundoffs.


-Lex