Dear Georg,
Thanks for your email and noticing the error. A parameter of the
glmnb.fit function (statmod package) changed recently from "start" to
"coef.start". That was making some problems in DEXSeq, but I adapted
the
DEXSeq code to it. Could you try to update to the last version of the
svn (1.3.16)?
Best wishes,
Alejandro
ps. I added copy to the Bioconductor mailing list in case someone is
interested, could be helpful for people having the same error message
> Dear Alejandro,
>
> some time ago you helped me to solve a problem with
> estimateDispersions() in the DEXSeq package. I had to interrupt
working
> on these data, but now I picked it up again and there seems to be
> another problem. This time estimateDispersins does not generate any
> results (as fa as I can tell), but without an error message. I
attached
> my example data, the script and the messages to this mail. It would
> extremely nice of you, if you could have a look into it and give me
a
> hint about what is going on.
>
> Best wishes,
>
> Georg
>
Thanks a lot! Now unfortunately I get a problem at the the size factor
estimation step:
> bat.counts <- estimateSizeFactors(bat.counts)
Error in validObject(cds) :
invalid class ?ExonCountSet? object: The featureNames do not match
with
the geneIDs:exonIDs
Are there incompatibilities with the ExonCountSet object and the new
version of DEXSeq? Do I have to generate the ExonCountSet again with
the
new version?
Cheers,
Georg
On 07/08/12 23:06, Alejandro Reyes wrote:
> Dear Georg,
>
> Thanks for your email and noticing the error. A parameter of the
> glmnb.fit function (statmod package) changed recently from "start"
to
> "coef.start". That was making some problems in DEXSeq, but I adapted
> the DEXSeq code to it. Could you try to update to the last version
of
> the svn (1.3.16)?
>
> Best wishes,
> Alejandro
>
> ps. I added copy to the Bioconductor mailing list in case someone is
> interested, could be helpful for people having the same error
message
>
>> Dear Alejandro,
>>
>> some time ago you helped me to solve a problem with
>> estimateDispersions() in the DEXSeq package. I had to interrupt
working
>> on these data, but now I picked it up again and there seems to be
>> another problem. This time estimateDispersins does not generate any
>> results (as fa as I can tell), but without an error message. I
attached
>> my example data, the script and the messages to this mail. It would
>> extremely nice of you, if you could have a look into it and give me
a
>> hint about what is going on.
>>
>> Best wishes,
>>
>> Georg
>>
Dear Georg,
Sorry for the delay of my answer.
But yes, you have to generate the new ExonCountSet with the new
version,
or alternatively just do:
featureNames(ecs) <- paste(geneIDs, exonIDs, sep = ":")
rownames(counts(ecs)) <- featureNames(ecs)
Best wishes,
Alejandro
> Thanks a lot! Now unfortunately I get a problem at the the size
factor
> estimation step:
>
> > bat.counts <- estimateSizeFactors(bat.counts)
> Error in validObject(cds) :
> invalid class ?ExonCountSet? object: The featureNames do not match
> with the geneIDs:exonIDs
>
> Are there incompatibilities with the ExonCountSet object and the new
> version of DEXSeq? Do I have to generate the ExonCountSet again with
> the new version?
>
> Cheers,
>
> Georg
>
>
> On 07/08/12 23:06, Alejandro Reyes wrote:
>> Dear Georg,
>>
>> Thanks for your email and noticing the error. A parameter of the
>> glmnb.fit function (statmod package) changed recently from "start"
to
>> "coef.start". That was making some problems in DEXSeq, but I
adapted
>> the DEXSeq code to it. Could you try to update to the last version
of
>> the svn (1.3.16)?
>>
>> Best wishes,
>> Alejandro
>>
>> ps. I added copy to the Bioconductor mailing list in case someone
is
>> interested, could be helpful for people having the same error
message
>>
>>> Dear Alejandro,
>>>
>>> some time ago you helped me to solve a problem with
>>> estimateDispersions() in the DEXSeq package. I had to interrupt
working
>>> on these data, but now I picked it up again and there seems to be
>>> another problem. This time estimateDispersins does not generate
any
>>> results (as fa as I can tell), but without an error message. I
attached
>>> my example data, the script and the messages to this mail. It
would
>>> extremely nice of you, if you could have a look into it and give
me a
>>> hint about what is going on.
>>>
>>> Best wishes,
>>>
>>> Georg
>>>
>
Alejandro Reyes scripsit 08/13/2012 01:12 PM:
> Dear Georg,
>
> Sorry for the delay of my answer.
> But yes, you have to generate the new ExonCountSet with the new
version,
> or alternatively just do:
This raises the general question of 'can saved serialised (stored to
disk) versions of Bioconductor objects be used across different
versions
of the software'?
The general answer is "no", since anything else would be impractical.
In
particular, package authors may provide facilities for that (e.g. via
providing a method for the 'updateObject' function in BiocGenerics).
In general, thus, it is good practice to keep the input data in a
sufficiently persistent format (e.g. text files) and the code to
create
the objects.
Others might have further views on this...
Best wishes
Wolfgang
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber
On 08/13/2012 05:57 AM, Wolfgang Huber wrote:
> Alejandro Reyes scripsit 08/13/2012 01:12 PM:
>> Dear Georg,
>>
>> Sorry for the delay of my answer.
>> But yes, you have to generate the new ExonCountSet with the new
version,
>> or alternatively just do:
>
> This raises the general question of 'can saved serialised (stored to
> disk) versions of Bioconductor objects be used across different
versions
> of the software'?
>
> The general answer is "no", since anything else would be
impractical. In
> particular, package authors may provide facilities for that (e.g.
via
> providing a method for the 'updateObject' function in BiocGenerics).
>
> In general, thus, it is good practice to keep the input data in a
> sufficiently persistent format (e.g. text files) and the code to
create
> the objects.
>
> Others might have further views on this...
Perhaps the best strategy depends on purpose and time scale.
For active research in rapidly changing fields and over 0-2 years it
seems like portable representation of the original data is best, as
Wolfgang suggests.
For reproducibility of research in the 1-5 year time span, it seems
like
one would like to archive or retain access to the original software
and
processing scripts, in addition to the data.
Over longer periods it's difficult to find hardware, compilers, etc to
make use of old software, and perhaps the best bet is archived,
updated
objects like the ALL data set that represent a snapshot of partially
processed data. This implies that someone with sufficient familiarity
with the software has been conscientious enough to provide facilities
for updating objects to work with current implementations, or
alternatively conservative enough (perhaps because something close
enough to the 'right' representation has been identified) not to
modify
the underlying data representation.
Martin
>
> Best wishes
> Wolfgang
>
> Wolfgang Huber
> EMBL
> http://www.embl.de/research/units/genome_biology/huber
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor at r-project.org
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives:
> http://news.gmane.org/gmane.science.biology.informatics.conductor
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
