commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat StatUtils.java
Date Wed, 18 Jun 2003 12:29:50 GMT


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     
>>
> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message