Thanks so much for your efforts, Val. This sounds great.
Michael
On Wed, May 29, 2013 at 4:20 PM, Valerie Obenchain <voben...@fhcrc.org>wrote:
> Hi all,
>
> keepSeqlevels(), dropSeqlevels(), renameSeqlevels() and the new
> restoreSeqlevels() are in GenomicRanges 1.13.16.
>
> Major changes:
>
> - These are high-level functions that wrap seqlevels(), not generics with
> methods.
>
> - All except restoreSeqlevels accept a named or unnamed character vector.
>
> - restoreSeqlevels is built on the new low-level seqlevels0() and
> currently applies only to TranscriptDb. (We plan to support this for
> BSgenome and SNPLocs as well.) The issue is that when seqlevels are changed
> directly on the TranscriptDb (reference class) it is difficult for the user
> to get back to the original names if they want them. Simply reloading the
> package doesn't do it. There is an example of this on the man page. The
> seqlevels0,TranscriptDb-method is in GenomicFeatures 1.13.11.
>
> Let me know if you have problems / questions.
>
> Val
>
>
> On 05/18/2013 05:18 PM, Michael Lawrence wrote:
>
>> Hi guys,
>>
>> Just wondering about the rationale of deprecating keepSeqlevels and
>> renameSeqlevels. Sure, it's possible to do those things with seqlevels,
>> somehow, but those functions make the high-level operation fairly obvious.
>> They're very well named, and correspond to typical operations. I don't
>> think we should deprecate functions just because they are simple wrappers
>> on top of lower level functions. I might even suggest adding a
>> dropSeqlevels(), e.g. dropSeqlevels("chrM").
>>
>> As I understand it, instead of:
>> keepSeqlevels(x, "chr1")
>>
>> We need to do something like:
>> seqlevels(x, new2old = 1, force = TRUE) <- "chr1"
>> But to be more careful it would be:
>> seqlevels(x, new2old = match("chr1", seqlevels(x)), force = TRUE) <-
>> "chr1"
>>
>> This seqlevels stuff is already confusing to people and the above lines
>> are
>> regular visitors on my office white-board. These changes will probably
>> cause me to sacrifice yet more of my white-board.
>>
>> In the future, perhaps we should propose these deprecations on the mailing
>> list for discussion, before any code changes.
>>
>> Michael
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________**_________________
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/**listinfo/bioc-devel<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>
>>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
