search

reage / interproscan

Automatically exported from code.google.com/p/interproscan
0 stars 0 forks source link

FingerPrint match evalues appear to be incorrectly allocated for filtered results #2

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Taking the Swiss-Prot sequence P51493 as an example, the FPScan binary gives 
maches to the following fingerprints at the E-values indicated:

INTRLEUKIN1B  (PR01359)   3.130760e-118
INTRLEUKN1AB  (PR01357)   1.463628e-49
INTERLEUKIN1  (PR00264)   7.086978e-22
IL1HBGF       (PR00262)   8.924590e-08

+ a match to INTRLEUKIN1X (PR01360), which will be/is being correctly filtered 
out by InterPro's hierarchy-based post-pocessing system.

Looking at the E-value output you sent me for the test set, the E-values for 
the individual models seem to be jumbled up. In fact, some models have 2 
different E-values, which is a definite indicator that something is going 
wrong! So, taking P51493 as an example again, we have:

PR00264 INTERLEUKIN1 1.5000000000000004E-49
PR00264 INTERLEUKIN1 8.90000000000001E-8
PR01359 INTRLEUKIN1B 1.5000000000000004E-49
PR00262 IL1HBGF 3.100000000000041E-118
PR01357 INTRLEUKN1AB 7.099999999999989E-22
PR01357 INTRLEUKN1AB 1.5000000000000004E-49
PR00262 IL1HBGF 1.5000000000000004E-49

Original issue reported on code.google.com by philip.j...@gmail.com on 12 Jul 2010 at 12:47

GoogleCodeExporter commented 9 years ago 
Initial examination shows that the raw matches have the correct evalues.  So, 
problem narrowed down to one of:
* raw match retrieval (from database)
* post processing
* filtered match persistence.

Next step is to find the problem - additional junit testing?

Original comment by philip.j...@gmail.com on 12 Jul 2010 at 12:53

GoogleCodeExporter commented 9 years ago 
Raw match retrieval now fully junit tested - no errors, so ruled out.

Original comment by philip.j...@gmail.com on 13 Jul 2010 at 10:05

GoogleCodeExporter commented 9 years ago 
Post processing is now fully Junit tested - again no errors, so ruled out.

Now to look at filtered match persistence...

Original comment by philip.j...@gmail.com on 13 Jul 2010 at 4:49

GoogleCodeExporter commented 9 years ago 
Fixed - logic error found in the filtered match DAO.  The evalue etc. from the 
previous result was being stored, hence the scrambled evalues.

Original comment by philip.j...@gmail.com on 14 Jul 2010 at 5:14