Increment bug in repeat loops

[Jacques Hausser]

Craig,

"Revolution does not use decimal numbers for its internal calculations (for reasons of speed), the decimal representation of a number is sometimes slightly off the correct number." (the dictionnary)

A "repeat with" loop with a fractional increment implies additions and comparison of decimal numbers. If you try:

on mouseUp
   set the numberformat to "#.##################"
   put 0 into j
   repeat with i = 0 to 11 -- for demonstration
      add 0.1 to j
      put i & " : " & j & return after fld "SoAndSo"
   end repeat
end mouseUp

you obtain:

0 : 0.111111
1 : 0.100000000000000006
2 : 0.200000000000000011
3 : 0.300000000000000044
4 : 0.400000000000000022
5 : 0.5
6 : 0.599999999999999978
7 : 0.699999999999999956
8 : 0.799999999999999933
9 : 0.899999999999999911
10 : 0.999999999999999889  < 10, so your loop "with i = 0 to 10 step 0.1" will continue for one more step !
11 : 1.099999999999999867  here it will stop, too late...

It's not a bug, it's a feature...
Better not to use decimal increments in loops !

All the best

Jacques


Le 21 nov. 2009 à 00:13, DunbarX at aol.com a écrit :

> For the following handler:
> 
> on mouseUp
>    repeat with y = 1 to 2 step 0.1   --startValue is 1
>       put "," after loopCounter
>    end repeat
>    put the number of items of loopCounter -- 11, which is correct
> end mouseUp
> 
> I tested all loops where the range was 1, with a startValue from 0 on up to 
> 500 (like 2 to 3 or 57 to 58). The startValue matters big time, and it has 
> nothing to do with 0. 
> 
> The startValue 0   contains an extra loop. (12)
> A startValue from 1 to 3 contains the right number of loops (11).
> A startValue from 4 to 15 contains an extra loop (12).
> A startValue from 16 to 63 contains the right number of loops (11).
> A startValue from 64 to 255 contains an extra loop (12).
> 
> 2^0 to (2^2 - 1) is OK (startValue is 1 to 3)
> 2^2 to (2^4 - 1) is wrong (startValue is 4 to 15)
> 2^4 to (2^6 - 1) is OK (startValue is 16 to 63)
> 2^6 to (2^8 - 1) is wrong (startValue is 64 to 255)
> 
> etc., I assume.
> 
> This very binary-like pattern runs alternately as 2^y to 2^(y + 2) - 1, 
> incrementing y by 2.
> 
> Loop ranges larger than 1 are also at risk, depending on how they overlap 
> the transition numbers. 14 to 16 gives an extra loop (22), but 15 to 17 gives 
> the correct number (21). Both ranges straddle the transition "15:16".
> 
> Gotta be a bug, and could really matter. This was started by jschwart.
> 
> Craig Newman
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

******************************************
Prof. Jacques Hausser
Department of Ecology and Evolution
Biophore / Sorge
University of Lausanne
CH 1015 Lausanne
please use my private address:
6 route de Burtigny
CH-1269 Bassins
tel/fax: 	++ 41 22 366 19 40
mobile:	++ 41 79 757 05 24
E-Mail:	jacques.hausser at unil.ch
*******************************************