J.Pietschmann wrote:
Mark R. Diggory wrote:
(1) It is very important to also use ((double)x)*x instead of
(double)(x*x), as the loss of precision starts to occur at far
greater values than overflow occurs if one were doing integer arithmetic
IIRC Java shares also the C behaviour in that n*n b
J.Pietschmann wrote:
Mark R. Diggory wrote:
J.Pietschmann wrote:
No. If you cast the base into a double there is not much risk of
overflow: double x = n; y=x*x; or y=((double)n)*((double)n);
or even y=n*(double)n; (but avoid y=(double)n*n).
Double mantissa has IIRC 52 bits, this should be good
Mark R. Diggory wrote:
(1) It is very important to also use ((double)x)*x instead of
(double)(x*x), as the loss of precision starts to occur at far greater
values than overflow occurs if one were doing integer arithmetic
IIRC Java shares also the C behaviour in that n*n becomes
negative instead o
Mark R. Diggory wrote:
J.Pietschmann wrote:
No. If you cast the base into a double there is not much risk of
overflow: double x = n; y=x*x; or y=((double)n)*((double)n);
or even y=n*(double)n; (but avoid y=(double)n*n).
Double mantissa has IIRC 52 bits, this should be good for integers
up to 2^26
Phil Steitz wrote:
I am also a little confused by J's analysis. Do we know definitively that using
J2SE, there is precision loss in Math.pow(x,n) vs x*x*...*x (n terms) for small
integer n?
Actually no. I didn't know they use a specific library routine
which is stunningly good. Some tests showed d*
Phil Steitz wrote:
--- Brent Worden <[EMAIL PROTECTED]> wrote:
I am also a little confused by J's analysis. Do we know
definitively that using
J2SE, there is precision loss in Math.pow(x,n) vs x*x*...*x (n
terms) for small
integer n? If the answer is yes, we should establish the
guideline that
--- Brent Worden <[EMAIL PROTECTED]> wrote:
> >
> > I am also a little confused by J's analysis. Do we know
> > definitively that using
> > J2SE, there is precision loss in Math.pow(x,n) vs x*x*...*x (n
> > terms) for small
> > integer n? If the answer is yes, we should establish the
> > guidelin
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
> Thanks for entertaining my sometimes naive questioning,
>
> J.Pietschmann 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
Thanks for entertaining my sometimes naive questioning,
J.Pietschmann 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
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 whi
--- "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
(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 num
accum += Math.pow(values[i], 2.0);
I think Math.pow should not be used for small integer exponents,
in particular 2,3 and perhaps 5. You could do this in FORTRAN or
other languages with a built-in power operator, because the compiler
will optimize it, but languages without that usually rewrite
pos(
13 matches
Mail list logo
