--- "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. > (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.Mac-Mgrs.org/ . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
