--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
> Al Chou wrote:
> > --- [EMAIL PROTECTED] wrote:
> >
> >>mdiggory 2003/06/17 20:05:45
> >>
> >> Modified: math/src/java/org/apache/commons/math/stat StatUtils.java
> >> Log:
> >> Simplified calculation, removing extra division.
> >>
> >> Revision Changes Path
> >> 1.6 +2 -1
> >>
> >
> >
>
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
> >
> >>
> >> Index: StatUtils.java
> >> ===================================================================
> >> RCS file:
> >>
> >
> >
>
/home/cvs/jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java,v
> >
> >> retrieving revision 1.5
> >> retrieving revision 1.6
> >> diff -u -r1.5 -r1.6
> >> --- StatUtils.java 18 Jun 2003 03:01:28 -0000 1.5
> >> +++ StatUtils.java 18 Jun 2003 03:05:45 -0000 1.6
> >> @@ -180,7 +180,8 @@
> >> accum += Math.pow((values[i] - mean), 2.0);
> >> accum2 += (values[i] - mean);
> >> }
> >> - variance = (accum -
> >> (Math.pow(accum2,2)/(double)values.length)) /
> >>(double)(values.length - 1);
> >> + variance = ((accum*(double)values.length) -
> >> Math.pow(accum2,2)) /
> >> + (double)(values.length*(values.length - 1));
> >> }
> >> return variance;
> >> }
> >
> >
> > More nitpicking. I don't see that multiplying top and bottom by
> values.length
> > makes things better. In fact, it could reduce precision by inflating the
> > magnitude of the first term before subtracting from it and dividing it.
> >
>
> hmm, good points. this may be an example of where "consolidating
> division operations" to limit the amount of division going on does not
> necessarily lead to a better algorithm. Its general practice to
> consolidate division operations to produce a more efficient algorithm
> where ever possible. Now I have my doubts that its proper to do from
> what you've suggested. Yes, its optimized an will be a faster
> calculation ("values.length" fewer expensive divisions) , but it will be
> less accurate as you've suggested. Accuracy should probably be weighted
> of greater importance than efficiency in much of our work.
We definitely need to keep accuracy and precision in mind more than most
projects do, and find an appropriate balance between them and efficiency. Like
optimization for efficiency, we really should put our money where our mouths
are regarding optimization for accuracy by writing explicit tests to
demonstrate whether an optimization actually does what we intended.
> > Also, do we really need the explicit casts to double? It seems to me that
> the
> > numerators are doubles, so the whole calculation will be double.
> >
>
> It may be an artifact from learning to program in other languages and
> not truly understanding type conversion in java arithmetic. Is it the
> case that in double/int --> double the int is converted to a double
> *prior* to the division occurring. I remember a discussion where it was
> recommended by others in the group to explicitly cast int's to double's
> in algorithms as a best practice.
Yeah, I do sort of remember the discussion about casting. I suppose the
compiler will cast anyway. I know it's not great practice to rely on one's
knowledge of a language's automatic type conversion semantics (specifically
that of C/C++) especially in its more obscure regions. I guess I'm revealing
my non-comprehension of why integer division ever makes sense unless you
explicitly ask for it. I would prefer 5/8 to always yield 0.625 unless I
explicitly say Math.floor( 5/8 ).
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]
