Al Chou wrote:
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
(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?
values.length would have to be > sqrt( Integer.MAX_VALUE ) ~ 46340 in order to
run into that overflow, but I can imagine some users blithely using a
64k-element array.
Or in UnivariateImpl's memoryless Inifinite window case, based on the
number of times addValue(...) has been called.
(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
I notice that java.lang.StrictMath explicitly mentions fdlibm. Does
java.lang.Math also use fdlibm's routines?
Yes, Math deligates to StrictMath in many cases, which then uses native
methods to call fdlibm. Math.pow is one of these cases.
Maybe we should just trust Math.pow (or StrictMath.pow?) by default until we
create some test cases that give us cause to doubt it....
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
