[TR-141] 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 TREC-131, we are using the WikipediaGammaFunction. This is insufficient (IIRC, it doesnt handle non-integer 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 log-based 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.

Generated at Wed Dec 13 08:53:52 GMT 2017 using JIRA 7.1.1#71004-sha1:d6b2c0d9b7051e9fb5e4eb8ce177ca56d91d7bd8.