Re: Significative numbers - possible solution


[Prev][Next][Index][Thread]

Re: Significative numbers - possible solution



There has been a fair bit of pointless discussion here on the topic of
significant digits due to some confusion between this topic and the topic of
_precision_.  Really two different things.  The number 473.1 is stated to the
nearest tenth, but is given to four significant figures.  The number 0.02 is
stated to the nearest hundredth (and thus is stated more precisely), but is
only given to one significant digit.

When adding and subtracting approximate numbers, precision is the key
consideration.  There are fairly straightforward "rules of thumb" that allow
you to state an appropriate result when operating with written figures -- in
general the result should be stated with no more precision than the _least_
precise number entering into the calculation.  This idea is usually applied
only to numbers stated in decimal form, but it applies equally well to
operations with common fractions. Sometimes applying this rule strictly means
you cannot state a result at all. So be it!

When multiplying and dividing approximate numbers, what you need to watch
instead are the number of significant digits to which the numbers entering into
the calculation are stated, and the result should not be stated with any more
significant digits than the least of these.  But this is also a rule of thumb,
and there are exceptions, as I noted in a post a few days ago.  The sensible
way to state the result of multiplying 1.03 by 9.8, for example, is 10.1 (even
though you seem to have three significant figures).

The real problem that people have been butting up against when trying to
automate sig-dig calculations is not anything mentioned above, but instead a
question of _representation_, namely the fact that expressing a number in
standard decimal notation does not always communicate the number of significant
digits.  The fact that this works _most_ of the time, and that people just sort
of live with the imperfection, and sort of half-fix it with various notational
devices like preserving trailing zeros or writing a decimal point after the
expression 10 to show that the 0 is _meant_ to be considered significant, and
so on, is not good enough to allow calculator implementation.  We need
non-ambiguity!  How can we communicate a number that, to three significant
digits, is 2000?  (This might be, for example, the result of rounding off 1997
or 2002 to the nearest ten).

The written system of scientific notation provides one answer.  In this case we
we just write 2.00E3, for example.  But this still doesn't do it for calculator
use!  Floating point routines do not take note of such niceties as trailing
zeros, and the calculator stores entries of 2.00E3 and 2E3 in exactly the same
way.

To develop a program that wrestles with and applies the rules of thumb
regarding significant digits, a notational device must be developed to
_communicate explicitly_ to the calculator the nature of the numbers that the
program will be working with, both their magnitudes and the associated
precision that is intended.  In a conversational program, this information
could be asked for with two separate questions when input is requested.  A more
compact way to enter the information (and a way for the calculator to _store_
the information) might be as a _pair_ {Val,n} where Val is an (evaluated)
numeric expression and n is the number of significant digits.  It then would be
fairly easy to develop routines that would find a pair that appropriately
represents the sum, product, etc of two such input pairs, using the ideas
about formal analysis of uncertainty that have been posted here. It should also
be possible to develop a way to display the result on the screen so that it
makes visual sense to the human observer.

You still are going to have to deal with all of those special cases and
paradoxes, however. That's what makes human-computer communication such a
fascinating topic!

RWW Taylor
National Technical Institute for the Deaf
Rochester Institute of Technology
Rochester NY 14623

>>>> The plural of mongoose begins with p. <<<<