Al Chou wrote:
> "Mark R. Diggory" <mdiggory@latte.harvard.edu> 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
>64kelement 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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
