POV-Ray : Newsgroups : povray.pov4.discussion.general : floating point precision Server Time: 16 Jun 2019 07:04:41 GMT
 floating point precision (Message 1 to 3 of 3)
 From: Woody Subject: floating point precision Date: 12 Oct 2009 23:20:00 Message:
```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
```
 From: clipka Subject: Re: floating point precision Date: 13 Oct 2009 01:19:50 Message: <4ad3d5b6@news.povray.org>
```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;

#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").
```
 From: alexandre bidaud649 Subject: Re: floating point precision Date: 28 Mar 2011 20:29:03 Message: <4d90ef8f@news.povray.org>
```you sipmly use a bad way to increment especially if your incrementation is
regular
inc

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

"Woody" <nomail@nomail> a écrit dans le message de news:
>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
>
```