Rounding it must be. But the error is related to the startValue. I would have thought that it did not matter, when incrementing by 0.1, say, what the StartValue was. In other words, I would have thought that incrementing like this:
repeat with y = 1 to 2 step 0.1 would have the same rounding error progression as: repeat with y = 3 to 4 step 0.1 Half the possible startValues (up to infinity?) round down at the nominal last step, and therefore force an addiional unwanted loop, and half must round up, and act properly. There is a precise method to the error, since it falls within the odd binary sequence I posted yesterday. It is a real shame that setting the numberformat (per Jacques Hausser) does not seem to affect step increments. That would be a logical workaround that forgives digital hardware limitations in a sensible way. As has been suggested, I suppose one could always just normalize to integers, though the startValue and increments usually driectly relate to the thinking behind process we are working with: repeat with y = 10 to 20 step 1 Not the same, is it? Craig Newman In a message dated 11/21/09 6:20:50 AM, [email protected] writes: > Rounding error. On the second-to-last iteration, Rev doesn't think it's > quite reached "1" yet, so it goes through the loop one more time. > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
