Al Chou wrote:
>  mdiggory@apache.org 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
>>
>
> jakartacommonssandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
>
>>
>> Index: StatUtils.java
>> ===================================================================
>> RCS file:
>>
>
> /home/cvs/jakartacommonssandbox/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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
