|
|
Hi all,
POV-Ray for Windows version 3.6.1a.icl8.win32
Windows XP sp2
I believe I have discovered a bug with #while loop processing when
comparing conditional values that are less than one. When checking
the "Loop" variable for less than one, the #while block is still
processed when the value one is reached.
The bug can be best explained and reproduced with the following code.
>>> snip >>>
// demonstration of possible bug in POV-Ray for Windows
// Version 3.6.1a.icl8.win32
camera {
location <0, 0.5, -2>
look_at <0, 0.5, 0>
}
// bug - should not enter while block when "Loop" = 1
#declare Loop = 0.0;
#while ( Loop < 1 )
sphere {
<-0.1, Loop, 0>, 0.05
pigment { rgb <1, 0, 0> }
finish { ambient 1 }
}
#declare Loop = Loop + 0.1;
#end
// example for comparison
#declare Loop = 0.0;
#while ( Loop < 0.99 )
sphere {
<0.1, Loop, 0>, 0.05
pigment { rgb <0, 1, 0> }
finish { ambient 1 }
}
#declare Loop = Loop + 0.1;
#end
>>> snip >>>
The #while loop that produces the red spheres is executed for the
"Loop" value of one when it should stop at 0.90, similar to "Loop <=
1". The #while loop that produces the green spheres is there for
comparison.
The #while loop processes properly if the comparison is changed to a
higher value, such as "Loop < 10". It also fails for lower values,
such as "Loop < 0.90", so the problem seems to be for values of one or
less.
Unless I'm really missing something obvious, this seems to be a bug.
Thanks to everyone involved for such a great product!
Best Regards,
Kyle Johnson
Post a reply to this message
|
|
|
|
hob### [at] gatenet wrote:
> #declare Loop = Loop + 0.1;
Not a bug. A limitation of floating point numbers.
The number 0.1 is pathological in that it cannot be represented
accurately in the base-2 floating point format of the FPU (for the
same reason that for example 1/3 cannot be represented accurately
with a base-10 floating point representation).
When you add 0.1 like this, the error caused by this accumulates
in such way that after you have added it ten times the result is
not 1 but a tiny fraction less.
If you use integers only (ie. "#declare Loop = Loop + 1;") then
there's no such problem (because floating point numbers can
represent integers accurately up to a quite big value).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
|
|
Thanks to Warp and Tom. This clears things up quite a bit. The link
was very helpful.
Kyle
On Wed, 13 Apr 2005 09:46:15 +0100, "Tom Melly"
<pov### [at] tomandlucouk> wrote:
>"Warp" <war### [at] tagpovrayorg> wrote in message
>news:425c5415@news.povray.org...
>> hob### [at] gatenet wrote:
>> > #declare Loop = Loop + 0.1;
>>
>> Not a bug. A limitation of floating point numbers.
>>
>
>The following link may be of interest
>
>http://tinyurl.com/272fa
>
Post a reply to this message
|
|