This is my opinion. I think the class should have a very general
structure. Depending on the assay, users may be particularly interested in
the original case described by Herve (alignments on opposite strands, same
chromosome), but I dont think it should be enforced.
We have first(), last(), sec
Thanks for the clarification , Hervé!
That makes sense to me! I prefer option b and c.
Best,
Julie
> On Jul 5, 2016, at 6:05 PM, Hervé Pagès wrote:
>
> Hi Julie,
>
>> On 07/05/2016 01:03 PM, Zhu, Lihua (Julie) wrote:
>> Dear Herve,
>>
>> Thank you so much for the detailed explanation and qu
Hi Julie,
On 07/05/2016 01:03 PM, Zhu, Lihua (Julie) wrote:
Dear Herve,
Thank you so much for the detailed explanation and quick fix!
When fusion occurs, the 2 alignments in a pair could be on different
chromosomes. Not sure what is the best way to handle this situation. If
set seqnames to *,
Dear Herve,
Thank you so much for the detailed explanation and quick fix!
When fusion occurs, the 2 alignments in a pair could be on different
chromosomes. Not sure what is the best way to handle this situation. If
set seqnames to *, then the mapping location is lost. Maybe set seqnames
to one of
Hi Julie,
The GAlignmentPairs container didn't support discordant strand until
BioC 3.4 (current devel). In the current release (and in previous
versions of BioC) strand discordance was not supported. I recently
fixed a bug in the released version of GenomicAlignments where the
strand() getter wa
Hi,
I just noticed that the released version of GUIDEseq failed at build stage,
which did not occur previously and I did not make any change to the release
version.
The error points to the GAlignmentPairs container. Is this an intended change
and should I modify my code to accommodate the chan