On Tue, 24 Oct 2017 13:27:17 -0700 (MST)

AG <

[hidden email]> 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

_______________________________________________

Help-octave mailing list

[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave