[TR141] GammaFunction in core is not good enough for proximity Created: 19/Sep/10 Updated: 05/Apr/11 Resolved: 01/Apr/11 

Status:  Resolved 
Project:  Terrier Core 
Component/s:  None 
Affects Version/s:  3.0 
Fix Version/s:  3.5 
Type:  Bug  Priority:  Major 
Reporter:  Craig Macdonald  Assignee:  Rodrygo L. T. Santos 
Resolution:  Fixed  
Labels:  None 
Description 
After TREC131, we are using the WikipediaGammaFunction. This is insufficient (IIRC, it doesnt handle noninteger input). We need to find a better one before releasing 3.1. 
Comments 
Comment by Rodrygo L. T. Santos [ 01/Apr/11 ] 
Current implementation overflows for large input values. I have fixed it by replacing raw computations with logbased computations. Test cases for large input values have been added. The documentation was updated to reflect that all GammaFunction implementations assume a positive input value, so as to avoid the issue of logarithms of negative values. 
Comment by Craig Macdonald [ 01/Apr/11 ] 
Here is a class I used while debugging the Gamma Function static class DebuggingGammaFunction extends GammaFunction { GammaFunction parent; DebuggingGammaFunction(GammaFunction p) { parent = p; } @Override public double compute(double number) { double rtr = parent.compute(number); System.err.println("compute("+number +")="+rtr); return rtr; } @Override public double compute_log(double number) { double rtr = parent.compute_log(number); System.err.println("compute_log("+number +")="+rtr); return rtr; } } 
Comment by Craig Macdonald [ 01/Apr/11 ] 
I verified that DFR proximity now behaves properly. Well done Rodrygo for reworking the Wikipedia implementation. 