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

Tim Nikias v2.0 <tim### [at] gmxde> wrote:
> What I want to avoid is the platform-specific handling
> of non-integer exponents.

  What do you mean by "platform-specific handling"?

  I see absolutely no reason for using int().

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3eeb73c1$1@news.povray.org>,
 "Tim Nikias v2.0" <tim### [at] gmxde> wrote:

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

It is really very simple: as the manual says, the result of a negative 
base raised to a non-integer exponent is undefined. Non-integer 
exponents with positive bases are perfectly acceptable. Using both abs() 
on the base and int() on the exponent is unnecessary, and pretty much 
useless...the int() doesn't avoid any problems. The issue has nothing to 
do with int() vs. floor() or ceil().

The only platform-dependence is the return value of pow(): because of 
the different methods platforms use for performing math and calculating 
the power, they will often come up with slightly different results, and 
they may have different ways of handling undefined "values". There is 
nothing you can do about this, but it is extremely rare for it to be at 
all relevant.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff explained it pretty well.
I think we both got sidetracked in our ways of
thinking, and were both unable to grasp what
the other was referring to. But its settled now, I've
misinterpreted the sentence in the docs.

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

> > What I want to avoid is the platform-specific handling
> > of non-integer exponents.
>
>   What do you mean by "platform-specific handling"?
>
>   I see absolutely no reason for using int().
>
> -- 
> plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
> sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
> density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
> <1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Ah, now I get what I misinterpreted: I somehow
expected that pow() wouldn't work properly
when using either a negative base OR a non-integer
exponent (and both combined would obviously be
desastrous). Don't ask me why, perhaps I encircled
the idea that I'm pulling some sort of root from the
base, and that this required an integer. Can't tell for
sure. Now that I understand where I was wrong,
I can't make any sense of my former thoughts anymore.

I guess you guys had this feeling (me not making
sense) all along. :-)

And now I fully understand what Warp meant about
int() being useless here etc.

Ah well. Sorry for any inconvenience I caused...

Regards,
Tim

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

>
> > 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.
>
> It is really very simple: as the manual says, the result of a negative
> base raised to a non-integer exponent is undefined. Non-integer
> exponents with positive bases are perfectly acceptable. Using both abs()
> on the base and int() on the exponent is unnecessary, and pretty much
> useless...the int() doesn't avoid any problems. The issue has nothing to
> do with int() vs. floor() or ceil().
>
> The only platform-dependence is the return value of pow(): because of
> the different methods platforms use for performing math and calculating
> the power, they will often come up with slightly different results, and
> they may have different ways of handling undefined "values". There is
> nothing you can do about this, but it is extremely rare for it to be at
> all relevant.
>
> -- 
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Post a reply to this message