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