Andreo Beck | 1 Aug 04:59 2006
Picon

$hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

  Hi,

  Can $hit_object->frac_aligned_hit or $hit_object->frac_aligned_query give outputs > 1 ?
  I get some > 1 values. Does using  the parentheses (e.g. $hit_object->frac_aligned_hit()) make any difference?

  Thanks,
  Andy

 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1ยข/min.
Sendu Bala | 1 Aug 08:49 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Andreo Beck wrote:
>   Hi,
>    
>   Can $hit_object->frac_aligned_hit or $hit_object->frac_aligned_query give outputs > 1 ?
>   I get some > 1 values. 

That might depend on what $hit_object is (Bio::Search::Hit::GenericHit 
?), but I'd say it's probably a bug if you get over 1. Can you give an 
example where you got over 1? Provide the code and the input data.

> Does using  the parentheses (e.g. $hit_object->frac_aligned_hit()) make any difference?

No, empty parentheses are only needed to make it clear to the perl 
interpreter you are calling a subroutine in ambiguous cases; 
$obj->method isn't ambiguous.
Sendu Bala | 2 Aug 13:23 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Andreo Beck wrote:
> Can $hit_object->frac_aligned_hit or $hit_object->frac_aligned_query
> give outputs > 1 ? I get some > 1 values.

This should now be fixed in CVS. You should be able to grab just 
Bio/Search/SearchUtils.pm if you don't want to install all of bioperl-live.

( http://code.open-bio.org/cgi/viewcvs.cgi/bioperl-live/ )

It should be noted that all frac_* statistics and probably others from 
hit objects have had a high chance of being wrong in the past, and 
frac_identical and frac_conserved can still be very wrong*. It would be 
a good idea if someone were to make these methods return slightly more 
sane numbers.

[*] which is to say, more wrong than you might reasonably expect, given 
the limitations with gapped or alignment-free blasts
Hilmar Lapp | 2 Aug 14:32 2006
Picon
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query


On Aug 2, 2006, at 7:23 AM, Sendu Bala wrote:

> It should be noted that all frac_* statistics and probably others from
> hit objects have had a high chance of being wrong in the past, and
> frac_identical and frac_conserved can still be very wrong*. It  
> would be
> a good idea if someone were to make these methods return slightly more
> sane numbers.
>
> [*] which is to say, more wrong than you might reasonably expect,  
> given
> the limitations with gapped or alignment-free blasts

Can you elaborate? Specifically, can you put in tests that show the  
wrong results?

	-hilmar
--

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================
Sendu Bala | 2 Aug 15:03 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Hilmar Lapp wrote:
> 
> On Aug 2, 2006, at 7:23 AM, Sendu Bala wrote:
> 
>> It should be noted that all frac_* statistics and probably others from
>> hit objects have had a high chance of being wrong in the past, and
>> frac_identical and frac_conserved can still be very wrong*. It would be
>> a good idea if someone were to make these methods return slightly more
>> sane numbers.
>>
>> [*] which is to say, more wrong than you might reasonably expect, given
>> the limitations with gapped or alignment-free blasts
> 
> Can you elaborate? Specifically, can you put in tests that show the 
> wrong results?

I've added some new tests based on Andreo's blast result, but atm I've 
left the tests commented out. See line 882 of t/SearchIO.t revision 1.94 
- a sane result would be less than 1.

I think it ought to be possible to get better answers, but I got the 
feeling the fix wouldn't be completely trivial so I let it go, not 
having the time to spare right now.

The reason I don't just call this a bug and make a bug report is that 
the documentation acknowledges that you won't always get a good answer, 
so it needs to be investigated if the current answer really is the best 
that can reasonably be given, or if there is some bug making the answer 
worse than it needs to be (as was the case with frac_aligned_hit and 
frac_aligned_query).
(Continue reading)

Bernd Brandt | 2 Aug 20:49 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Hi,

"frac_identical and frac_conserved can still be very wrong"
They were wrong with hmm report parsing (hmmsearch). The  bioperl-live
(CVS 14 July 2006) returned 0 for both fracions. I will check it with
the newest CVS and send a small test script.

Regards,
Bernd

On 8/2/06, Sendu Bala <bix <at> sendu.me.uk> wrote:
> Hilmar Lapp wrote:
> >
> > On Aug 2, 2006, at 7:23 AM, Sendu Bala wrote:
> >
> >> It should be noted that all frac_* statistics and probably others from
> >> hit objects have had a high chance of being wrong in the past, and
> >> frac_identical and frac_conserved can still be very wrong*. It would be
> >> a good idea if someone were to make these methods return slightly more
> >> sane numbers.
> >>
> >> [*] which is to say, more wrong than you might reasonably expect, given
> >> the limitations with gapped or alignment-free blasts
> >
> > Can you elaborate? Specifically, can you put in tests that show the
> > wrong results?
>
> I've added some new tests based on Andreo's blast result, but atm I've
> left the tests commented out. See line 882 of t/SearchIO.t revision 1.94
> - a sane result would be less than 1.
(Continue reading)

Sendu Bala | 9 Aug 10:43 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Bernd Brandt wrote:
> Hi,
> 
> "frac_identical and frac_conserved can still be very wrong"
> They were wrong with hmm report parsing (hmmsearch). The  bioperl-live
> (CVS 14 July 2006) returned 0 for both fracions. I will check it with
> the newest CVS and send a small test script.

For both hmmsearch and hmmpfam parsing, those are deliberately set to 0. 
They needn't be; there is a midline to the hsp-like-thing that shows 
identical and conserved positions. I suppose the reason they're set to 0 
currently is that its not a real alignment against a set sequence, but 
against a model. Still, I think it's reasonable to give an answer in 
both cases if you can get an answer from the original output files.

I'm in the process of writing new hmmer parsers, and will allow non-0 
answers for those methods.

(Its not really possible to alter the existing parser because it only 
allows one hsp per hit, preventing a correct answer even if it didn't 
set to 0)
Andreo Beck | 3 Aug 20:14 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

It still gives more than 1. Can you tell me how good approximation it does? I mean if its 1.3 can I assume it 1 or
something like that?

Sendu Bala <bix <at> sendu.me.uk> wrote: Andreo Beck wrote:
> Can $hit_object->frac_aligned_hit or $hit_object->frac_aligned_query
> give outputs > 1 ? I get some > 1 values.

This should now be fixed in CVS. You should be able to grab just 
Bio/Search/SearchUtils.pm if you don't want to install all of bioperl-live.

( http://code.open-bio.org/cgi/viewcvs.cgi/bioperl-live/ )

It should be noted that all frac_* statistics and probably others from 
hit objects have had a high chance of being wrong in the past, and 
frac_identical and frac_conserved can still be very wrong*. It would be 
a good idea if someone were to make these methods return slightly more 
sane numbers.

[*] which is to say, more wrong than you might reasonably expect, given 
the limitations with gapped or alignment-free blasts

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
Sendu Bala | 3 Aug 20:34 2006
Picon

Re: $hit_object->frac_aligned_hit/$hit_object->frac_aligned_query

Andreo Beck wrote:
[re: frac_aligned_query, frac_aligned_hit]
> It still gives more than 1. Can you tell me how good approximation it 
> does? I mean if its 1.3 can I assume it 1 or something like that?

The only 'approximation' is to assume that none of the hsp alignments 
have gaps. It is still impossible for it to get more than 1. When you 
have gaps these methods are still useful because they give you a good 
idea of how much of the hit/query was involved in the alignment - not 
base for base but in terms of sequence coverage. So when they are 
working without any bug, the number returned is valid and correct from a 
certain viewpoint and shouldn't be 'fudged' like you suggest (treating 
one number as another (1.3 != 1)).

If it still does get more than 1 it is a bug that needs to be fixed. For 
the test data you sent me I get less than 1 now. Are you sure you 
managed to get and install v.1.16 or higher of 
Bio::Search::SearchUtils.pm ? Are you sure you are actually using the 
new module when you run your script?

Gmane