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.


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.




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to