Chronology Current Month Current Thread Current Date
[Year List] [Month List (current year)] [Date Index] [Thread Index] [Thread Prev] [Thread Next] [Date Prev] [Date Next]

Re: numerical methods (was: banning calculators)



"QUIST, OREN" wrote:
...
I can't think of any real use of such a calculation other than to show
students that their calculators cannot do everything for them.

That's not phrased as a question, but I'll take it
as a question anyway. The uses of my numerical methods
exercise, and exercises like it, include teaching the
following points:

1) There are things your calculator can do, and things
that it can't.

2) You need to be able to tell the difference.

3) As a contribution toward item (2), every calculator
will overflow and underflow at some point. Find out
where yours does.

4) Also as a contribution toward item (2), whenever you
get a small difference between large numbers, you
will get loss of significance. This is true whether
you use a calculator or not. It is _less_ true if
you use the calculator cleverly, using the memory-
store and memory-get functions to handle intermediate
values in the calculation, as opposed to writing down
intermediate values on paper, because it (usually)
keeps more precision than you (usually) would write
on paper.

5) Algebraic simplfication of the expressions you
are given may avoid the necessity of taking the small
difference between large numbers.

6) It would be nice if calculators had alarms that
went off whenever you subtracted two nearly-equal
numbers... but they don't. You'll have to notice
on your own. If you ever get two intermediate
results that cancel, or nearly cancel, you need to
go back and see if there is an algebraic reason why
the cancellation was foreordained -- in which case
you can reformulate the calculation so that doing the
subtraction is unnecessary. If it wasn't foreordained,
you need to go back and do the calculation with
roughly TWICE AS MANY sig digs as you otherwise
would have needed.

7) Actually, routinely keeping twice as many sig
digs as you think you need is a good practice, if
you can do it without serious burden.

At the very least, keep at least one guard digit in
all intermediate calculations. If you need to round
off the final answer, round off the final answer and
nothing before that. Better yet, state the final answer
to an extra digit and then state what the uncertainty
is; it's OK to have an uncertainty of more than 9 in
the last place. That's how the professionals do it.
For example, the number I used earlier today
http://physics.nist.gov/cgi-bin/cuu/Value?eqbohrrada0
has an uncertainty of 19 counts in the last digit,
when stated in this form.

8) Precision issues like this crop up in real-world physics
with some regularity. For example, consider a diffraction
problem. To calculate the intensity in the intense
places, you are adding large numbers, no problem. But
if you want to know how dark it is in the dark places,
you have lots and lots of cancellations, and it is
quite easy to get into trouble if you're not careful.

There are also situations where you can have a
combinatorially-large number of possibilities, each
of which is exponentially unlikely, all adding up to
a result that is nontrivial (neither zero nor huge).
Ordinary evaporation (far below boiling temperature)
is an example of this.

Other examples abound.

9) Addition of small numbers to large numbers causes
loss of precision, although it won't be super-serious
unless you do it repeatedly, in a program with loops
(or unless it leads into a subtraction situation as
previously discussed).

10) You won't always have a calculator with you. If
you are clever, you can calculate 24/25 - 23/24 in
your head more quickly and more accurately than the
numbskull can calculate it with a calculator.