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

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

Tim Nikias v2.0 wrote:

> 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")
> 

To me it looks like you're trying to calculate a fractional power of a
negative number... what do you expect to get as result?


-- 
POV-Ray Objects Collection: http://objects.povworld.org

Post a reply to this message

Hm. Didn't notice that one... Fumbling with
all kinds of stuff and overseeing the obvious!
I'm a little stressed, that's all I have to say for
an excuse.
Easiest method to solve the problem:
pow( abs(_light), int(_Pow)).

Got a little stuck with my thoughts somehow. :-/


-- 
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")
> >
>
> To me it looks like you're trying to calculate a fractional power of a
> negative number... what do you expect to get as result?
>
>
> -- 
> POV-Ray Objects Collection: http://objects.povworld.org

Post a reply to this message

Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> pow( abs(_light), int(_Pow)).

  There's no need to convert _Pow to an integer. There's absolutely
nothing problematic with rational exponents as long as the base is
positive.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Well, I'd be making sure then, won't I? In this
case, the exponents are rather big anyway (like
around 30 or such). But again, haven't thought
of that, and you're right.
Docs say: non-integer results might differ
for platforms. So this just makes sure that doesn't
happen.

Well. I guess everyone reading this will wonder
how I actually managed to write the LSSM... :-)

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

> > pow( abs(_light), int(_Pow)).
>
>   There's no need to convert _Pow to an integer. There's absolutely
> nothing problematic with rational exponents as long as the base is
> positive.
>
> -- 
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> Docs say: non-integer results might differ
> for platforms. So this just makes sure that doesn't
> happen.

  Non-integer results may differ even if the exponent is rounded to integer.
Rounding it doesn't really "fix" anything.
  We are talking about differences in the 15th most significant digit or
whatever. Nothing really important.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

>   Non-integer results may differ even if the exponent is rounded to
integer.
> Rounding it doesn't really "fix" anything.
>   We are talking about differences in the 15th most significant digit or
> whatever. Nothing really important.

Hm. So I should better use floor() or ceil()? These should
clip to the same values for different platforms, right? And
why doesn't int() do that?

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

> > Docs say: non-integer results might differ
> > for platforms. So this just makes sure that doesn't
> > happen.
>
>   Non-integer results may differ even if the exponent is rounded to
integer.
> Rounding it doesn't really "fix" anything.
>   We are talking about differences in the 15th most significant digit or
> whatever. Nothing really important.
>
> -- 
> #macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb
M()}}
> N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
> N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  -
Warp -

Post a reply to this message

Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> Hm. So I should better use floor() or ceil()? These should
> clip to the same values for different platforms, right? And
> why doesn't int() do that?

  Hmm, you didn't seem to understand what I meant.

  "1.1^30" can give and probably gives a slightly different result
depending on the FPU used. However, the difference is in the very lowest
digits of the result. It doesn't really matter.
  The exact same thing happens with "1.1^30.1". The result is not inherently
wrong, it just isn't exact to the last digit because of the inaccuracy of
floating point numbers.

  For instance, even though mathematically "x^3*x^4" equals to "x^7",
a typical FPU will give you a slightly different result for them for
almost any value of x.
  But this isn't an important error because the difference happens
in the 15th or even higher most important digit.

  Different FPUs can use different algorithms for calculating pow and
thus give a slightly different result.

-- 
#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

That I understood. What I was referring to is the
int() inside the pow(). You mentioned that it might
still yield different results, that's what I was asking
about. It's funny how writing can sometimes screw
things up a little, eh? :-)

Rereading the posts with your last statement also
clears things up a little. For clarity's sake, lets just
stick to
pow( abs(X), int(Y))

I thought that it would solve most problems (like the
doc-mentioned non-integer usage for exponents), and
you replied that it wouldn't necessarily "fix" anything.
What I want to avoid is the platform-specific handling
of non-integer exponents. I assume int() would be the
way to go.
So, am I right about that?

PS: If I sound like I'm a know-better, sorry, not intended.

we're actually talking about... :-)

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

> > Hm. So I should better use floor() or ceil()? These should
> > clip to the same values for different platforms, right? And
> > why doesn't int() do that?
>
>   Hmm, you didn't seem to understand what I meant.
>
>   "1.1^30" can give and probably gives a slightly different result
> depending on the FPU used. However, the difference is in the very lowest
> digits of the result. It doesn't really matter.
>   The exact same thing happens with "1.1^30.1". The result is not
inherently
> wrong, it just isn't exact to the last digit because of the inaccuracy of
> floating point numbers.
>
>   For instance, even though mathematically "x^3*x^4" equals to "x^7",
> a typical FPU will give you a slightly different result for them for
> almost any value of x.
>   But this isn't an important error because the difference happens
> in the 15th or even higher most important digit.
>
>   Different FPUs can use different algorithms for calculating pow and
> thus give a slightly different result.
>
> -- 
> #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