PDA

View Full Version : Mathematical flaw in maxscript loop testing expressions?


googlo
11-12-2002, 04:05 PM
I've been learning Maxscript recently and started a little project but noticed that with certain values entered my script wasn't behaving predictably.

For some reason during loop expression testing, for certain values, the loop will exit out prematurely with certain step values, almost as if internally Max is rounding wrong or something.

Here's an example:

when I test this script

(
local umin=0.0
local umax=4.0;
local udiv=10.0;
local ustep=umax/udiv;
local uloopmax=0;

for u=umin to umax by ustep do
(
uloopmax+=1; print ("u=" + (u as string));
)

print ("uloopmax=" + (uloopmax as string));
)

Max gives me this:

"u=0.0"
"u=0.4"
"u=0.8"
"u=1.2"
"u=1.6"
"u=2.0"
"u=2.4"
"u=2.8"
"u=3.2"
"u=3.6"
"uloopmax=10"
"uloopmax=10"
OK

notice how 'u' doesn't complete it's iteration to 4.0?

now, when I substitute 5.0 in place of 4.0 for the variable umax, it does iterate all the way through! see..

"u=0.0"
"u=0.5"
"u=1.0"
"u=1.5"
"u=2.0"
"u=2.5"
"u=3.0"
"u=3.5"
"u=4.0"
"u=4.5"
"u=5.0"
"uloopmax=11"
"uloopmax=11"
OK

This kind of thing will happen with different numbers for umax, sometimes it works other times it doesn't. At first I though that maybe it was a rounding problem, but that can't be the case because like the values used above, they aren't repeating decimals. They are perfect.

So I wonder what is going on? I can't complete my script with this kind of behaviour. And it makes me want to give up scripting really if maxsccript is this buggy or unpredictable. How is anyone supposed to work with that? I hope I'm missing something!

LFShade
11-13-2002, 01:44 AM
I can't say for certain, but this looks to be the result of floating-point (im)precision. Even though the numbers you're using appear to be perfect, their precision might be ever-so-slightly off after the division operation. Through a number of iterations of adding the slightly imprecise floats together, it can add up to just enough to throw the whole thing off.

I'm afraid I can't explain it any better than that; it's just something I've learned to take as gospel in programming: never trust a floating-point number. It's best to try to use integers where possible. It's okay if the result of operating on integers produces a float, but try to be aware of the hazard of operating on floats directly.

BTW, this isn't something that's exclusive to MAXScript. You'll run into floating-point precision "gotchas" in any programming language.

BrandonD
11-13-2002, 05:17 AM
Part of it could also be that MAXscript by default makes lots of assumptions about variables. You can often avoid these assumptions by declaring them by type such as:

a = 7 as float

Most variables are "type free" in MAXscript by default. Check it out in the MXS help file.

CGTalk Moderation
01-13-2006, 10:00 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.