(1) Does it seem logical that when working with "n" (or values.length)
to use Math.pow(n, x), as positive integers, the risk is actually
'integer overflow' when the array representing the number of cases gets
very large, for which the log implementation of Math.pow would help
retain greater numerical accuracy?
.
(2) In the opposite case from below, where values[i] are very large,
doesn't the log based Math.pow(values[i], 2.0) again work in our favor
to reduce overflow? Seems a catch22.
More than anyone really ever wanted to know about Math.pow's implementation:
http://www.netlib.org/fdlibm/e_pow.c
-Mark
,J.Pietschmann wrote:
>> accum += Math.pow(values[i], 2.0);
>
>
> I think Math.pow should not be used for small integer exponents,
> in particular 2,3 and perhaps 5. You could do this in FORTRAN or
> other languages with a built-in power operator, because the compiler
> will optimize it, but languages without that usually rewrite
> pos(x,y) as exp(y*log(x)). This is bad for precision, in particular
> if x is very small, and somewhat bad for performance (taking time of
> one multiplication and two divisions, typically costing 3 to 20 times
> as much as a multiplication each).
> I'm not sure how Java handles it, but the loss of precision may
> be responsible for the unexpected negative values.
>
> I'd recommend to replace pow(x,2) by x*x, pow(x,3) by x*x*x and
> pow(x,4) by a=x*x, y=a*a. It doesn't matter much whether x is an
> expression because the compiler will take care of it and eliminate
> redundant computation, however code may be more redable if a
> temporary variable is used. If x is an integer, an explicit cast
> to double may be necessary to avoid integer overflow.
>
> Math.pow should only be used if the exponent is larger, not an
> integer, or not a constant.
>
> J.Pietschmann
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org