LOGO-L> Re: floating point errors in MSWLogo

Quote:

>......

>Adding a delta_t of 0.02 to a time of 0 1640 times gave me a

>value of time that was 32.7799999999995 , that is a small error but

>an error none the less. The problem is that with more iterations of the

>program the error grows exponential and after a hour or so

>of running the simulations the values walk straight into the

>ether.

> This poses a severe limitations on the type

>and scale of models that can be constructed in LOGO. I realize that

>I'm probably pushing LOGO beyond it intended domain but you except

>the correct answer from a computer

> As a test of this error, I wrote the following program

>to atest

>(local "times "number)

>make "number 0

>for [j 1 6 1 ]~

> [ make "times power 10 :j

> type [times -> ]

> print :times

> for[i 1 :times 1]~

> [make "number sum :number 0.01]

> type [result -> ]

> print :number

> make "number 0

> ]

>end

> Running the program produces the same wrong results on two different

>machines (one WIN95, the other WINNT).

Tony,

The problem you are describing is not directly related to Logo. It is a

well known problem of computer arithmetic in general: 0.01 cannot be

expressed exactly in binary representation (it is a periodic number in

binary system) therefore it contains a small error and adding this error

many times produces your incorrect results.

The known rule is not to use in such situations a cumulative addition in a

loop, but compute the value directly in each step using multiplication:

I.e. instead of this:

make "s 0

for [i 1 10000 1] ~

[ dosomething ~

make "s sum :s 0.01]

you should use this:

for [i 1 10000 1] ~

[ make "s 0.01 * (:i - 1)~

dosomething]

or (saving one addition in the loop):

make "s 0

for [i 1 10000 1] ~

[ dosomething ~

make "s 0.01 * :i]

the multiplication is usually considered to be a 'more expensive'

operation, but for modern computers with floating point units it is usually

not true, so using the multiplication needs not slow down the program at all.

You would get similar results also in other programming languages. It only

depends on the accuracy of the number representation how quickly the

problem appears.

You are right that Logo is not suited for long numerical computations, but

on the other hand I tried another logo (Comenius Logo) ant it ran your test

correctly.

-----------------------------------

As this is my first message posted to Logo-l, I would like to give a few

informations about my person:

I am Peter Tomcsanyi, living in Bratislava, Slovakia, Europe.

One day a week I teach System programming and Operating systems at the

Department of Informatics Education of Comenius University in Bratislava, see:

http://www.*-*-*.com/ ~kvi/slo/index.htm

In the rest of my time I am a self-employed computer programmer. Among

other software projects I developed together with my colleagues a Logo

implementation for Windows 3.1 and 95 called Comenius Logo, which is being

sold in several (mostly European) countries under several names, for more

information, see

http://www.*-*-*.com/

or (for the English version called SuperLogo):

http://www.*-*-*.com/

Peter Tomcsanyi

---------------------------------------------------------------