Hi Vasili,

>        Are most other biohaskell members interested in your suggested
>    functionality regarding the bowtie implementation?

I think Olaf is more interested in the sequence formats that are in use
in bowtie, than in bowtie itself. Having efficient (en|de)-coding of all
kinds of bio-formats is quite useful for many of us.

Particular algorithms (like bowtie) however, are probably of interest
only to 1-2 people, if they happen to work on such a problem at the
time.

However, such things should *not* deter you, it makes for a good
learning experience to build things up, especially if there is something
like a reference implementation to compare to.

Viele Gruesse,
Christian



* Vasili I. Galchin <vigalc...@gmail.com> [04.02.2016 06:12]:
>    Olaf,
>        Are most other biohaskell members interested in your suggested
>    functionality regarding the bowtie implementation?
> 
>        I looked a little at the bowtie c++ source. Mounds of code :-)
> 
>       Ok ... we need to look for "invariants" (not exactly like in pure
>    maths .. but something like IMO) between different software architectures.
>    Sorry .. I know very hard to understand my thoughts. In software the
>    notion of "invariant" is very loose. I am thinking "out loud"., i.e.
>    .thinking as I  am writing. OK .. the Johns Hopkins' writer made
>    architectural decisions that are linked to  1) his language choice i.e.
>    the C++ language and also to his personal ideas in a language independent
>    way. I am thinking. We have to try to decouple 1) and 2) to derive the
>    invariant by throwing away pieces of 1) that are totally language
>    dependent  .. hence have no bearing on what is the "target" language,
>    e.g. Haskell. E.g. the C++ implementation uses a "thread driver" to move
>    the segment processing forward over time. Is this part of 1) or 2) ( I am
>    assuming that 1) and 2) are disjoint)? Answer: I don't know. i am sorry
>    for all of the tortured thinking. Bottom line: need to understand globally
>    the C++ software architecture to understand what is language dependent(and
>    can be thrown away) and independent part that is I think language
>    invariant. then use the language invariant part to design and implement in
>    Haskell. Shields up: i anticipate flames in my lower parts .. :-(
> 
>    Vasyl 
>     
>    On Tuesday, February 2, 2016, Olaf Klinke <o...@aatal-apotheke.de> wrote:
> 
>      One is on GitHub, one is on sourceforge. Google
> 
>      bwa site:github.com
> 
>      or go to
> 
>      http://sourceforge.net/projects/bowtie-bio/files/bowtie2/2.2.6/
> 
>      Olaf
> 
>      > Am 02.02.2016 um 01:33 schrieb Vasili I. Galchin
>      <vigalc...@gmail.com>:
>      >
>      > No promises. I have done a lot of reverse engineering in C/C++. So
>      > where is the extant C/C++ source??
>      >
>      > On Mon, Feb 1, 2016 at 5:21 PM, Olaf Klinke <o...@aatal-apotheke.de>
>      wrote:
>      >> Yes, there is a TODO: Get rid of the "cheap watches" spam sent to
>      this list. In fact the signal/noise ratio makes we want to unsubscribe.
>      >>
>      >> Other than that, I'd like to see someone reverse-engineer one of the
>      major sequence index formats and provide a Haskell interface, so that we
>      can design our own functional alignment algorithms instead of building
>      shell scripts around bowtie or bwa.
>      >> By reverse-engineer I mean look at the source code. It's all there,
>      but poorly documented. I understand too little C/C++ to make sense of
>      how precisely these index structures are stored. But if one could write
>      a Data.Binary instance, that'd be awesome.
>      >> Meanwhile I implemented a Lempel-Ziv together with full-text search
>      on the compressed data (not my idea). This is possible if one uses one
>      trie for the entire text. However, full-text search only succeeds if the
>      match overlaps a block boundary. That should be fine for sufficiently
>      long queries.
>      >>
>      >> --Olaf

Reply via email to