Re: floating point arithmetic problems

[Gordon Haverland]

On Tue, 24 Oct 2017 13:27:17 -0700 (MST)
AG <address@hidden> wrote:

> I thought I understood floating point problems but I guess I don't
> and now I have a lot of code that is acting strangely given my
> understanding. EG.
> 0.2-0.1==0.1

We are preconditioned to understand base 10.  Computers don't work in
base 10.

But, even with this, we can look at the problem of:

 (1 / 3) * 3

In base 10, 1/3 is 0.333333333333333....  If we multiply that by 3, we
are going to get 0.99999999999....  We do _NOT_ get 1.0.

If we could choose bases to work in, base 12 might be reasonable.  Lots
of repeating fractions in base 10 become finite fractions in base 12.

But for computers, we are more or less working in base 2.  And you get
many more endless repeating fractions converting integer ratios into
"real numbers" than in base 10.


The first thing to consider, is the number we want to work with,
actually known?  The numbers e and pi cannot be represented exactly in a
finite number of bits.  If the number you want to use is not possible
to write in some kind of base 2 floating point representation exactly,
you will have error.

As hinted at above, base 2 leads to many more numbers which cannot be
represented exactly in some word size, than base 10.

In base 10 arithmetic, 1/7 is
 0.124857 124857 124857 124857 124857 ...

I like this as an example, as the other 7'ths fall out of the same
sequence.
 2/7 = 0.24857  124857 124857 124857 ...
 3/7 = 0.4857   124857 124857 124857 ...
 4/7 = 0.57     124857 124857 124857 ...
 5/7 = 0.724867 124857 124857 124857 ...
 6/7 = 0.85     124857 124857 124857 ...

Regardless of what precision you can use, integers divided by 7 will
typically end up with error as the fractions usually end going on
forever.  You have to round or chop someplace, and that is where your
error starts.


If you solve a problem in single precision arithmetic and then solve it
in double precision arithmetic and you get substantially the same
solution, it means your answer _MIGHT_ be accurate.  With 64 bit
processors, adding on quad precision arithmetic and getting the same
answer adds further weight to the suggestion that the answer _MIGHT_ be
accurate.

Some problems are easy to solve.  Some problems are easy to solve by
good algorithms.  Some problems are difficult to solve by any means
available.

You need to know something about the problem you are trying to solve.

But just writing a bit of code (be it in octave or anything else) and
expecting you are getting "_THE ANSWER_" is naive.

Way back when, if you were doing linear systems type problems, you
could choose from some fast solvers (scale as N^2) or doing things by
SVD (scale as N^3).  If N is big, using SVD made for long computation
times.  But SVD allows one to remove/reduce the effects of error.

Do you want the wrong answer quickly, or a more correct answer more
slowly?  Being correct enough is another problem.

-- 

Gord