Re: [Algorithms] approximation to pow(n,x)?

[Robin G. <rob...@gm...>]

Your real problem is that the range of x is unconstrained. Looking at
how pow() is calculated:

   pow(n,x) = exp(log(x)*n)

You've simplified the exponent to exp(y+0) .. exp(y+1), but as y is
unconstrained you've really gained nothing. The main problem with
implementing pow() is that naive code can lose many digits of
significance during the calculation if you don't calculate the log and
multiply using extended precision, e.g. if you want a 24-bit result
you'll need to calculate the intermediate values to 30 or more bits of
accuracy. This is done by splitting the problem into a high part and a
low part and combining the two at the reconstruction phase. For
example, here's an implementation of powf():

   http://www.koders.com/c/fidF4B379CC08D80BEE9CD9B65E01302343E03BF4A7.aspx?s=Chebyshev

The exp() is a great function to minimax as it only requires a few
terms to approach 24-bit accuracy, but log() is a painfully different
story often requiring table lookups (memory hits) to function well
across the full number range.

What are you using this for? If it's lighting or shading, there's no
real reason to use a power function on the cosine term to get tighter
specular highlights. It's just a shaping function that people use
because it's easy to control and AFAICT it has no physical basis in
defining a BRDF from the micropolygon point of view.

- Robin Green.

On Tue, Nov 3, 2009 at 7:45 PM, Juan Linietsky <re...@gm...> wrote:
> Hi guys! I was wondering if there are fast ways to approximate the
> curve resulting from pow(n,x) where n is in range [0..1] and x > 0
> using only floating point (without strange pointer casts/etc)..
>
> Cheers
>
> Juan Linietsky