At the least, I will add the use of droplevels on colData to the vignette.
On Mar 12, 2014 7:28 PM, "Steve Lianoglou" wrote:
> On Wed, Mar 12, 2014 at 3:52 PM, Michael Lawrence
> wrote:
> > On Wed, Mar 12, 2014 at 3:45 PM, Martin Morgan
> wrote:
> >
> >> On 03/12/2014 03:02 PM, Wolfgang Huber w
On Wed, Mar 12, 2014 at 3:52 PM, Michael Lawrence
wrote:
> On Wed, Mar 12, 2014 at 3:45 PM, Martin Morgan wrote:
>
>> On 03/12/2014 03:02 PM, Wolfgang Huber wrote:
>>
>>> Hi Martin, Mike
>>>
>>> a DESeq2 user brought up the observation that when he subsets a
>>> 'DESeqDataSet' object (the class i
On Wed, Mar 12, 2014 at 3:45 PM, Martin Morgan wrote:
> On 03/12/2014 03:02 PM, Wolfgang Huber wrote:
>
>> Hi Martin, Mike
>>
>> a DESeq2 user brought up the observation that when he subsets a
>> 'DESeqDataSet' object (the class inherits from 'SummarizedExperiment') by
>> samples, he often ends u
On 03/12/2014 03:02 PM, Wolfgang Huber wrote:
Hi Martin, Mike
a DESeq2 user brought up the observation that when he subsets a ‘DESeqDataSet’
object (the class inherits from ‘SummarizedExperiment’) by samples, he often
ends up with unused factor levels in the colData. (Esp. since the subsetting
I would prefer the droplevels method for SummarizedExperiment, since
this is consistent with the use of droplevels on data.frame objects.
On Wed 12 Mar 2014 03:02:37 PM PDT, Wolfgang Huber wrote:
Hi Martin, Mike
a DESeq2 user brought up the observation that when he subsets a ‘DESeqDataSet’
ob
Also,
There is nothing wrong with using GENEID the way that you initially
did. It was just a small bug that prevented some internal subsetting
from working properly and that is now fixed.
It just happened that GENEID was equivalent to ENTREZID in this case.
And that ends up making it a slo
Hi Martin, Mike
a DESeq2 user brought up the observation that when he subsets a ‘DESeqDataSet’
object (the class inherits from ‘SummarizedExperiment’) by samples, he often
ends up with unused factor levels in the colData. (Esp. since the subsetting is
often to select certain subgroups). Would e
I just checked a fix in for this bug to GenomicFeatures (which happens
to be where the problem was). It should percolate out to the build
system soon.
Marc
On 03/12/2014 02:19 PM, Servant Nicolas wrote:
Hi guys,
Thanks for your feedbacks.
Indeed I put GENEID because it is used in the txdb
Hi guys,
Thanks for your feedbacks.
Indeed I put GENEID because it is used in the txdb database.
> library(TxDb.Hsapiens.UCSC.hg19.knownGene)
> txdb <- TxDb.Hsapiens.UCSC.hg19.knownGene
> columns(txdb)
[1] "CDSID" "CDSNAME""CDSCHROM" "CDSSTRAND" "CDSSTART"
[6] "CDSEND" "EXONID"
Thanks Nicolaus! That's a good bug. I will work on a fix. The reason
why James work-around here functions is because the number of databases
that it has to query is fewer by one. It is also faster for this
reason. So when you say GENEID you mean the ids used in the associated
txdb database
Hi Nicolas,
On 3/12/2014 12:39 PM, Servant Nicolas wrote:
Dear all,
I have an error using the select function from the AnnotationDbi package.
I try to convert some geneID into Symbol, but for some strange reasons it
crashed.
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
txdb <- TxDb.Hsapiens.UC
Dear all,
I have an error using the select function from the AnnotationDbi package.
I try to convert some geneID into Symbol, but for some strange reasons it
crashed.
library(TxDb.Hsapiens.UCSC.hg19.knownGene)
txdb <- TxDb.Hsapiens.UCSC.hg19.knownGene
isActiveSeq(txdb)[seqlevels(txdb)] <- FALSE
Done!
On Wed, Mar 12, 2014 at 5:01 PM, Martin Morgan wrote:
> On 03/12/2014 08:18 AM, Laurent Gatto wrote:
>>
>>
>>> Should we then just drop \RequirePackage{helvet} from BiocStyle?
>>
>>
>> That seems a reasonable solution to me.
>
>
> yep! Martin
>
>>
>> Laurent
>>
>>> Cheers,
>>> Andrzej
>>
>>
On 03/12/2014 08:18 AM, Laurent Gatto wrote:
Should we then just drop \RequirePackage{helvet} from BiocStyle?
That seems a reasonable solution to me.
yep! Martin
Laurent
Cheers,
Andrzej
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box
> Should we then just drop \RequirePackage{helvet} from BiocStyle?
That seems a reasonable solution to me.
Laurent
> Cheers,
> Andrzej
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Should we then just drop \RequirePackage{helvet} from BiocStyle?
Cheers,
Andrzej
On Wed, Mar 12, 2014 at 3:27 PM, Kasper Daniel Hansen
wrote:
> Whatever we choose, we should discourage the use of other fonts: one of the
> advantages of bioc style is to make it easy to compiler on other computers
Whatever we choose, we should discourage the use of other fonts: one of the
advantages of bioc style is to make it easy to compiler on other computers.
Fonts can be hard to deal with on some tex systems, especially if you
don't have root access. Having a "nice" font is not worth the added
complex
On Tue, Mar 11, 2014 at 11:29 PM, Hervé Pagès wrote:
> Hi Val,
>
>
> On 03/11/2014 08:57 PM, Valerie Obenchain wrote:
>
>> Hi,
>>
>> On 03/11/14 15:33, Hervé Pagès wrote:
>>
>>> On 03/11/2014 02:52 PM, Hervé Pagès wrote:
>>>
On 03/11/2014 09:57 AM, Valerie Obenchain wrote:
> Hi Herv
> Hi Laurent, Martin,
>
> thank you for bringing this up! As pointed out by Martin, currently
> the 'helvet' package gets overridden by Sweave, so this setting
> affects only the knitr output.
>
> My feeling is that the default font style should be the same
> regardless of the engine used. Too kee
Hi Laurent, Martin,
thank you for bringing this up! As pointed out by Martin, currently
the 'helvet' package gets overridden by Sweave, so this setting
affects only the knitr output.
My feeling is that the default font style should be the same
regardless of the engine used. Too keep thing simple,
20 matches
Mail list logo
