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