Increment bug in repeat loops

[DunbarX at aol.com]

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