"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> 	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. 
> 
> C'mon, "what floating-point is" is NOT one of those things you are entitled
> to be ignorant of and still call yourself a programmer.  Everyone who leaves
> this department with a BSc or BAppSci has met floating-point and its dangers
> (but not numerical analysis) in 2nd year.

I fear we thave to agree to disagree at that point.  I would estimate it
takes a year's moderate study (like, 3-5 hours a week) to get decent
with floating point, and longer to get really good at it.  This estimate
is based on my experience taking a one-semester 3-hour class at a good
university and with a good professor, and on my talking with various
well-educated computer scientists who are not very good with floating
point.  

So, I think you can very well be a programmer, and even a computer
scientist, without being good with floating point.  You should simply
know that you suck at it.



> 	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.
> 
> "The time required to really learn it" is a straw man.
> What's at issue is "the time required to learn about it well enough to know
> that it isn't decimal and it isn't real arithmetic, that it's finite and
> approximate."  Two lectures to do a good job, one if pressed for time.

It's important, because if you can convince me that two days is all you
need, then I will retract my rule of thumb.



	

> If you don't care what the answer comes out to, there is no point in
> running a program, you might as well throw yarrow sticks.
> That's very difference from tolerating a *limited* amount of approximation.

Actually, there are a lot of programs where you don't really care what
the answers are.  Textbook examples come to mind, where you are trying
to make a point and not necessarily make a useful program.  Graphics is
my favorite example:  In graphics you often want it to look right, not
to be "accurate" in most senses of the word.  Yet another example is the
enemy strategy in a computer game.  Do you really care if a zombie
occasionally moves right when it is "supposed" to move left?  In such
cases there often isn't a "correct" answer at all.

Throwing yarrow sticks, whatever those are, would be fine for these,
too, but sounds more tiring than using a computer.

I agree in principle with the second part.  Note, though, that for
limited accuracy to be useful, you probably need to have some idea of
how accurate you are.  Finding a bound on the error requires a lot of
skill.


> So if you
> want to know the per capita GNP, you have to start with numbers only known
> to about 1 part in 1**4.  The calculation
> 
>     GNP_per_capita = 8.508e10 / 3.8e6 = 22.4e3
> 	
> is as good as makes any sense at all.  It doesn't take one or two years of
> university to be able to make this calculation.

Yes, that one calculation is fine, but it doesn't generalize.  Put some
+ and -'s in there and the story changes.  Put in a loop and things get
really hairy.  Calculating a simple integral is already enough to screw
you up, if your calculation of (f(x+d) - f(x)) can involve a
catastrophic cancelation.

And that's the problem.  Some simple calculations are safe and
convenient with floating point, but how do you know which ones, and what
are the odds that a complex calculation will only involve safe
operations?



>  If you represent that as a whole number of
> cents, or a whole number of mills, or even a whole number of hundredths
> of a cent, then guess what?  You just approximated the answer.  (In fact
> you just got a *worse* approximation than Float would give you...)

Yes, but now the approximation mechanism is very easy to understand. 
Contrast "round to the nearest integer" to "use all the digits you can,
computer".  And to get back to the original topic, imagine when someone
tries to represent one penny as 0.01 dollars, or if they try to round
down to a number of pennies.  They're approximating, and probably in an
unsuitable way.


> 	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.
> 
> No, floating-point arithmetic does NOT add a new issue here.
> If you have a financial calculation that involves division, roots, or
> compound interest, you *have* to understand the concept of approximation,
> and you *have* to figure out how good an approximation you need and how
> to scale &c so as to get the right answer.

Yes, the programmer must learn these things.  However, they only need
learn about approximation in general.  If they use floating point, then
they must additionally understand how *floating point* handles
approximation.

It seems to me that if you are rounding things off yourself, then any
programmer will have a good handle on what is going on.  If they use
floating point, then they will likely get version 1 of the program
completed sooner, but they won't have any idea how accurate it is -- and
it may well not be accurate at all.


-Lex