Re: Help for preparing bowtie upload
Hello Andreas,
Don’t take my opinion as absolute, but I have used bowtie quite a bit in the past. According to the manual, for that specific example:
Example 5: -a —best
"Specifying -a results in the same alignments being printed as if just -a had been specified, but they are guaranteed to be reported in best-to-worst order"
This would imply that the test failed, as the order of the output matters. BUT, and this is where it is unclear, what would be order for “ties”? The “best-to-worst” order is based upon the number of mismatches and line 2-5 all have 2 mismatches (line 1 has 1 mismatch, the 8:T>A, and thus is the best), i.e. they are all a tie.
From looking at the bowtie output you provided, the content is the same. The sequence id names, position and mismatches are identical in both outputs, the only difference is the order. That may not even be bowtie’s fault, it may be using some system or other library which does sorting slightly differently, and most specifically handling ties differently.
My opinion, especially if you tried the other examples in the manual, and those are okay, then you are okay with this fix, because it is seems to be an arch-specific difference in sorting, whereby sorting is only triggered with the —best option.
Scott
On Sep 3, 2014, at 5:27 AM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi,
>
> as you might know bowtie fails to build on several architectures
> #756780. As I said in my previous mail to this list (and upstream) this
> is caused by using an outdated arch-specific copy of an internal gcc
> header file. To be sure that my fix really works I added a test suite
> which is oriented at the upstream manual and reproduces the output given
> there.
>
> This was possible with the exception of one example:
>
> $ bowtie -a --best -v 2 e_coli --suppress 1,5,6,7 -c ATGCATCATGCGCCAT
>
> is supposed to have the output
>
> - gi|110640213|ref|NC_008253.1| 2852852 8:T>A
> + gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T
> - gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T
> - gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G
> - gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
>
> according to the manual but produces with the current arch-amd64
> specific build in unstable as well as with the new build
>
> - gi|110640213|ref|NC_008253.1| 2852852 8:T>A
> - gi|110640213|ref|NC_008253.1| 148810 10:A>G,13:C>G
> + gi|110640213|ref|NC_008253.1| 1093035 2:T>G,15:A>T
> - gi|110640213|ref|NC_008253.1| 905664 6:A>G,7:G>T
> - gi|110640213|ref|NC_008253.1| 4930433 4:G>T,6:C>G
>
> which has the only difference that the original line 4 went to line 2
> now (all output files and the diff attached).
>
> As a proof of my terribly poor knowledge in this field I wonder whether
> this is an issue or not. I guess I could simply use the current output
> as comparison template but I's like to hear some confirmation. If you
> confirm so I'd plan to upload and see what happens on all the other
> architectures.
>
> Kind regards and thanks for your insight
>
> Andreas.
>
> --
> http://fam-tille.de
> <example5.out.orig><example5.out><example5.out.diff>
Reply to: