Doh! Stupid me. There's a note in the Docs about
non-integer values leading to platform specific returns...

Well. So then just tell me if anyone has an idea how I
could circumvent the problem properly (because the
script I'm working on does require non-integer exponents).
Perhaps someone has some C++ Code which I could
implement to simulate my own running pow()-function
for like, ten digits?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

> My Specs:
> Win2000, Athlon XP2400+, 786MB DDR
>
> So, here goes minimum code:
>
>  #local _Light=-0.47443615353120855;
> // <- Replace latest 7 with 69 or with 71 to see change
>  #local _Pow=1/0.49999999999999997227;
> #local C_Spec=pow( _Light, _Pow );
>  #debug concat(str(abs(C_Spec),1,20),"\n")
>
>
> Just paste it into an empty scene file and render.
>  As mentioned in comment above, when exchanging the
> latest 7 with a slightly smaller value like 69, it'll give
> a proper result, as does 71. The value above will yield
> 1.#QNAN00000000 for the debug stream.
>
> The actual impact it had on my scene was that all calculation
> involving trace() onto a superellipsoid wouldn't calculate
> properly, even though trace() worked fine (was able to
> place cones with it). Anyways, I guess the error doesn't
> have to do with trace() at all, but, as did vnormalize(<0,0,0>)
> before final POV-Ray 3.5, the error has some sideeffects
> which disrupt some internal algorithms. Note though that
> thats my personal guess.
> The strange thing though is that the above error doesn't
> occur at all times with low values, which is why I tested
> 69 and 71. Some smaller values work, while others don't.
> Haven't gone to larger values for testing, as I'm not sure
> what to test for. The above example shows the unpredictability
> good enough IMHO. Since it's stripped down to the minimum
> possible, should be a good start for tracking the problem (but
> again, I'm no expert on that).
>
> Hope this is enough information for the POV-Team to figure
> what to do. If anyone else has an idea how I could circumvent
> the problem so that my script runs properly, I'd be happy
> to hear about it! :-)
>
> Oh, and some confirmations for different systems are considered
> appropriate.
>
> Regards,
> Tim
>
> -- 
> Tim Nikias v2.0
> Homepage: http://www.digitaltwilight.de/no_lights
> Email: Tim### [at] gmxde
>
>

Post a reply to this message