Re: Bio.motifs.matrix.PositionSpecificScoringMatrix.calculate - scoring ambiguous sequences

Peter Cock <[email protected]>
Newsgroups gmane.comp.python.bio.devel
Message-ID <CAKVJ-_550EcbfMHzzO2B=kWV4VyVCZmbRB53vVEPM3EUwO0tOw@mail.gmail.com>
Thanks Bartek - very useful comments!

I was also worried about changing the default - making this into
a separate method would be even more explicit than the optional
argument I was suggesting.

(Apologies, I had a typo in Michiel's email address.)

Peter

On Wed, Jun 22, 2016 at 10:08 AM, Bartek Wilczynski <[email protected]>
wrote:

> Dear Peter and Sefa,
>
> I was involved in Bio.Motif, but not so much in Bio.motifs anymore. Since
> you ask me personally, and I think this is an important issue, I can
> certainly give you comments, and you can make decisions accordingly.
>
> This is a big change in  the sense, that it can potentially:
> - give surprising results to some people (the semantic you suggest is by
> no means standard, and the usual interpretation of this score is log-odds,
> so taking arithmetic mean of log odds is questionable, however arguably
> natural to some users)
> - allow for some errors (using DNA motif on protein sequence, etc) that
> are currently prevented by strict checking
> - slow things down when people are actually searching for unambiguous DNA
> motifs
>
> If you think this functionality is important (I can see many places where
> it would come in handy), I'd suggest considering writing a new function.
> like "calculate_ambiguous" or something similar, that would be slower and
> have a certain semantic (potentially, user selected - I could see people
> interested in min and max semantic in addition to average proposed by Sefa).
>
> That's pretty much my 2 cents
> B
>
> On Wed, Jun 22, 2016 at 10:56 AM, Peter Cock <[email protected]>
> wrote:
>
>> Hi Sefa,
>>
>> It looks like Michiel is extra busy at the moment, but in the absence
>> of his input, perhaps Bartek has some thoughts (he was the original
>> author of the motif module)?
>>
>> I would suggest the new mode might need to be an option, e.g.
>> default to the current NaN results, but easy to pick your proposed
>> mean scoring. Might the minimum or maximum ever be useful?
>>
>> If you (Sefa) want to go ahead and fork the repository and explore
>> this on a branch leading to a potential pull request that seems sensible.
>>
>> Note we define the IUPAC ambiguity codes centrally in Python in
>> Bio/Data/IUPACData.py which you can import for the new Python
>> code. I can see arguments for and against having them hard coded
>> in the proposed new C code.
>>
>> Thanks,
>>
>> Peter
>>
>> On Wed, Jun 22, 2016 at 2:37 AM, Sefa Kilic <[email protected]> wrote:
>>
>>> Any thoughts?
>>>
>>> On Mon, Jun 13, 2016 at 10:58 AM, Peter Cock <[email protected]>
>>> wrote:
>>>
>>>> What do you think Michiel?
>>>>
>>>> Also related, earlier today I filed this issue:
>>>> https://github.com/biopython/biopython/issues/851
>>>>
>>>> Peter
>>>>
>>>> On Mon, Jun 13, 2016 at 3:26 PM, Sefa Kilic <[email protected]> wrote:
>>>> > Hello all,
>>>> >
>>>> > I have been using the Bio.motifs PSSM search for a long time.
>>>> Occasionally,
>>>> > I work with genome sequences containing ambiguous bases. Biopython
>>>> currently
>>>> > does not support scoring sequences with ambiguous bases and I would
>>>> like to
>>>> > propose a change to fix that.
>>>> >
>>>> > Currently, the "calculate" function in PositionSpecificScoringMatrix
>>>> class
>>>> > checks if alphabets of both motif and sequence are
>>>> > IUPAC.IUPACUnambiguousDNA. If they are not, a ValueError exception is
>>>> > raised.
>>>> >
>>>> > The code itself, however, tolerates ambiguous bases on the sequence
>>>> as NaN.
>>>> > That is, given a PSSM of length L, all L-mer subsequences of the given
>>>> > sequence are scored as NaN. I would like to extend it and do the
>>>> scoring
>>>> > properly for ambiguous sequences. For instance, if the base is Y (C
>>>> or T),
>>>> > it should be scored as the average of scoring it as C and as T. If
>>>> the base
>>>> > is N, it should be scored as the average of all bases [S(A) + S(T) +
>>>> S(C) +
>>>> > S(G)] / 4.
>>>> >
>>>> > The change needs to be done on both Python and C (_pwm.c) sides. What
>>>> do you
>>>> > think? If you agree, I can implement it and send a pull request.
>>>> >
>>>> > Cheers,
>>>> >
>>>> > _______________________________________________
>>>> > Biopython-dev mailing list
>>>> > [email protected]
>>>> > http://mailman.open-bio.org/mailman/listinfo/biopython-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> Biopython-dev mailing list
>>> [email protected]
>>> http://mailman.open-bio.org/mailman/listinfo/biopython-dev
>>>
>>
>>
>
>
> --
> Bartek Wilczynski
> ==================
> Institute of Informatics
> University of Warsaw
> http://www.mimuw.edu.pl/~bartek
>

_______________________________________________
Biopython-dev mailing list
[email protected]
http://mailman.open-bio.org/mailman/listinfo/biopython-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.