Hi Scott,
On Thu, Sep 04, 2014 at 05:12:50PM -0500, Scott Christley wrote:
> 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.
Ahhh, I think RTFM would have enlightened me. ;-)
> 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.
Sounds like we could go with the changed order than.
> 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.
I think so. As I wrote also the current bowtie in Debian has the same
result as my proposed change.
> 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.
This makes me even more convinced to add the build time test and build
the package on all architectures. So we get a better image about the
behavour of the algorithm under different circumstances. In any case
I'll add this conversation to README.Debian to have some record of the
issue.
Thanks a lot for your helpful explanation
Andreas.
> On Sep 3, 2014, at 5:27 AM, Andreas Tille <[email protected]> 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>
>
>
> --
> To UNSUBSCRIBE, email to [email protected]
> with a subject of "unsubscribe". Trouble? Contact [email protected]
> Archive: https://lists.debian.org/[email protected]
>
>
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
