commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: Math.pow usage was: Re: cvs commit: ...
Date Wed, 18 Jun 2003 19:50:29 GMT
Al Chou wrote:

>--- "Mark R. Diggory" <> 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:
>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....

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message