A few weeks ago I was doing a

#while(inc<=1)
#local inc=inc+some_small_increment
#end

loop for an animation in which I was making loops from 0 to 1.0. where 1 is
evenly divisible by some_small_increment divide

I spent about two hours trying to figure out why my loop was coming up one item
short.

I realize now that it was coming up short since inc never actually equals 1, but
somethine closer to 0.9999999999.

I eventually solved my probelem by scaling everything by 1,000 and changin the
#while(inc<=1)

to

#while(inc<=1000)
#local inc=inc+some_other_larger_increment
#end

I'm assuming there is a perfectly legit reason as to why this was happening
(having to do whith floating point precision) but Is there anyway to get around
this?

If this does not seem legit please let me know, and I will upload source into
someother forum for explanation or bug-fixing purposes.

-Jeff

Post a reply to this message

Woody schrieb:
> 
> I realize now that it was coming up short since inc never actually equals 1, but
> somethine closer to 0.9999999999.

> I'm assuming there is a perfectly legit reason as to why this was happening
> (having to do whith floating point precision) but Is there anyway to get around
> this?

The underlying problem is the same as if you'd try to compute 1/3 + 1/3 
+ 1/3 + ... using decimal numbers with a certain limit in precision; as 
you can't exactly represent 1/3 this way, you'd get e.g.:

   0.33 + 0.33 = 0.66
   0.66 + 0.33 = 0.99
   0.99 + 0.33 = 1.32
   ...

In practice, if you have a fixed value to add, you can usually 
"re-normalize" the whole problem to use integers for your loop variable; 
e.g. instead of:

   #local Foo = 0.0;
   #while (Foo <= 1.0)
     ...
     #local Foo = Foo + MySmallValue
   #end

you can use:

   #local Bar = 0.0;
   #while (Bar * MySmallValue <= 1.0)
     #local Foo = Bar * MySmallValue;
     ...
     #local Bar = Bar + 1.0;
   #end

Somewhat more generally, any integer divided by any power of 2 is safe 
to add (unless it's extremely small compared to the "target value").

Post a reply to this message

you sipmly use a bad way to increment especially if your incrementation is 
regular
cause your add each time a precision error, to a precession error of your 
inc

instead of using addition, use multiplication

in fact your code acts like this:
inc(1) = inc(0) + (e + de)            (de is error precision)
inc(2) = inc(1) + (e + de) = inc(0) + 2*e + 2*de (you error precision is 2 
times higher that normal at maximum)

etc
your way to calculate your inc, is what we call an arithmetique serie
hence this can be simplified by

inc(n) = inc(n0) + some_small_increment (n-n0), where n is the total number 
of frame, n0 the first frame, inc(n0) the first value of inc










web.4ad3b95a1e85221ac41e4df50@news.povray.org...
>A few weeks ago I was doing a
>
> #while(inc<=1)
> #local inc=inc+some_small_increment
> #end
>
> loop for an animation in which I was making loops from 0 to 1.0. where 1 
> is
> evenly divisible by some_small_increment divide
>
> I spent about two hours trying to figure out why my loop was coming up one 
> item
> short.
>
> I realize now that it was coming up short since inc never actually equals 
> 1, but
> somethine closer to 0.9999999999.
>
> I eventually solved my probelem by scaling everything by 1,000 and changin 
> the
> #while(inc<=1)
>
> to
>
> #while(inc<=1000)
> #local inc=inc+some_other_larger_increment
> #end
>
> I'm assuming there is a perfectly legit reason as to why this was 
> happening
> (having to do whith floating point precision) but Is there anyway to get 
> around
> this?
>
> If this does not seem legit please let me know, and I will upload source 
> into
> someother forum for explanation or bug-fixing purposes.
>
> -Jeff
>

Post a reply to this message