 "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.
> (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?
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
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.MacMgrs.org/ .
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL  Now only $29.95 per month!
http://sbc.yahoo.com

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
