commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36215] - [Math] HypergeometricDistributionImpl cumulativeProbability calculation overflown
Date Wed, 24 Aug 2005 22:45:10 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36215>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36215


microarray@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Additional Comments From microarray@gmail.com  2005-08-25 00:45 -------
I really hate to post this but I think this bug is somewhat hard to catch:
evolution somehow kicks in......

check this out: 
before I used the new jar I coded a loop to calculate all the probabilities of
the upper tail and sum them to get the upper cumPro, just like textbook
definition, but of course, slow. 
I used the new upperCumulativeProbability method to calculate my example, 5000
200 100 50. used my old looping way calculation and a perl script to cross
check. I got exactly the same answer: upper cumPro = 4.407167010070517E-45. Great!!!
but, as I used it more, ugly bugs showed up: when I calculate 26896 895 55 19,
the new jar with the fix gave me 3.40373618E-10, my old looping way and the perl
script says 6.2588249E-15 is right, and the probability(19)= 5.8805728E-15,
which is a good comfirmation that the second answer is right, because you can
imagine something with a tail of even smaller than E-15 won't accumulate to E-10. 

I have absolutely no idea where this comes from now: the fixed jar can calculate
something as small as 4E-45, as we saw in the first example, which indicates
accumulation of numeric error is not happening here; without any knowledge of
the source code (not that I can't get it, but I won't be able to understand it
at all, as a newbie), I have no idea why it would calculate the second case
wrong. you guys might think "hey, these are values small enough to be taken as
zero, what's the difference?!" I guess mathematicall precision is what we're
after here. my looping code can do the job, but it's gonna be tooo slow imagine
you do this over and over. 

Thanks for everyone's patience and effort in solving this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
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