Order of precedence in screen.seqs

Feature requests
#1

I debated whether to submit this to the “bug” or “wish” forum.

Consider the following toy example alignment:

>test1
.....NGAATTCTTTTTTTT.....
>test2
.....-GAATTC--------.....

Consider the output of the following two commands:

screen.seqs(fasta=test.align,maxambig=0,start=6,end=20)

and

screen.seqs(fasta=test.align,start=6,end=20)

In the first run, the first sequence is ejected, presumably because of the single ambiguity. In the second run, it survives.

BUT.

The ambiguity is outside the core region of alignment and therefore not something I care about. I want to keep this sequence “in play.” I would like to see the screen.seqs command process the start and end options before the ambiguities, homopolymers or whathaveyou. Does this make sense? I appreciate that you can run the command multiple times and set whatever precedence you desire, but that’s a kludge, and the current order of precedence doesn’t match my intuition.

Robin

#2

the current workaround is to run screen.seqs, then filter.seqs, then screen.seqs again:

screen.seqs(fasta=test.align,start=6,end=20)
filter.seqs(fasta=test.align,trump=.)
screen.seqs(fasta=test.good.align,maxambig=0)
#3

I guess the title of the thread is misleading. screen.seqs will reject a sequence if ANY of the options is true so there really isn’t an order of precedence. My workaround is the only way to go. Still – it’s something of a pitfall and could be added to the wiki if you like.

#4

ok, now i get it. the actual order of precedence is start, end, maxambig, but it’s an “or” combination, not an “and” so it doesn’t really matter. i think we’ll leave it the way it is and if you’d like to post your workaround as a way to use screen.seqs, go for it.

pat