LOGO-L> Re: floating point errors in MSWLogo 
Author Message
 LOGO-L> Re: floating point errors in MSWLogo

>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
> 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
>  ]  

>  Running the program produces the same wrong results on two different
>machines (one WIN95, the other WINNT).


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)~

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


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
or (for the English version called SuperLogo):

Peter Tomcsanyi


Thu, 11 May 2000 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. LOGO-L> floating point errors in MSWLogo

2. LOGO-L> Floating point errors

3. LOGO-L> Floating point trick once more

4. LOGO-L> Re - floating point errors in MSWLogo

5. LOGO-L> PC-LOGO syntax in MSWLogo

6. An alternative to floating point (was Re: Floating point non-exactness)

7. IBM 370 Floating point to IEEE floating point

8. Runtime Error M6104, Floating point error:overflow

9. LOGO-L> Re: MSWLogo

10. LOGO-L> MSWlogo for D. Barnett

11. LOGO-L> Web page + MSWLogo GUI Builder

12. LOGO-L> Bola magica (MSWLogo)


Powered by phpBB® Forum Software