[BioC] ChIPpeakAnno: Question about strand conversion in BED2RangedData()

[Zhu, Lihua (Julie)]

Ying,

I modified BED2RangedData and GFF2RangedData per your suggestions. The
Version is devel 2.5.1 with revision 64831. Thanks again for your great
suggestions!

Best regards,

Julie


On 4/3/12 9:34 AM, "Julie Zhu" <julie.zhu at umassmed.edu> wrote:

> Ying,
> 
> Thanks so much for willing to share the code! We would be happy to
> incorporate your code in makeVenndiagram.
> 
> Sorry that I missed your earlier email regarding strand conversion. The
> reason I convert it to 1/-1 is to be compatible with other functions. It is
> for the best to convert it to +/- in all functions. We will do.
> 
> Thanks again for your constructive suggestions and willing to share your
> code!
> 
> Best regards,
> 
> Julie 
> 
> 
> On 4/2/12 6:16 PM, "Ying Wu" <daiyingw at usc.edu> wrote:
> 
>> Hi Dr Zhu,
>> I am writing to you again to ask you about the reasons why you convert
>> strand +/- to 1/-1 in this BED2RangedData(). I was hoping you could
>> instead keep it as +/-/* because you cannot change RangedData objects
>> generated by this function into GRanges object unless the strand is
>> +/-/*. The code in question can be found on line 38-39 in
>> BED2RangedData.R example code follows:
>> g1 = read.table("my.bed", sep="\t")
>> g1.r = BED2RangedData(g1)
>> g1.g = as(g1.r, "GRanges")
>> 
>> I use GRanges object instead of RData since I find it easier to have
>> things not arranged by space (though less efficient). On the topic of
>> efficiency, I was wondering if you've looked into Michael Lawrence's
>> method here:
>> https://stat.ethz.ch/pipermail/bioc-sig-sequencing/2010-March/001035.html
>> I do not subscribe to this list but I found this thread while looking
>> for a way to speed up the findOverlappingPeaks comparison in
>> makeVennDIagram. I have implemented this method for a 3-way venn diagram
>> and it is quite a bit faster than makeVennDiagram(). Digging into your
>> code on bioconductor, I believe the time bottleneck is in lapply
>> statement of findOverlappingPeaks (I am probably wrong about this since
>> I did not test things thoroughly). However, if you are interested, I
>> could send you the code I wrote to implement what Michael mentioned in
>> that thread.
>> 
>> Best,
>> Ying Wu
>