[BioC] no summary of GOHyperGResult
James W. MacDonald
jmacdon at med.umich.edu
Fri Jul 9 17:14:34 CEST 2010
Hi Robert,
On 7/9/2010 10:36 AM, Robert M. Flight wrote:
> Thanks to both Martin and James for the suggestions, but I give up.
> I've tried adding the stuff to the NAMESPACE file that Martin
> suggested, and that doesn't seem to work. However, I can't figure out
> where or how I would add the kluge that James suggests, as this isn't
> required in GOstats and it figures it out fine.
No it doesn't. Martin may be correct that the problem finding summary
methods might have been fixed, but as it stands with the GOstats
package, the same kludge still exists for finding the correct summary
method from within a function.
As you have already noted, *from within a function* there is some
problem dispatching on the correct summary method (i.e., finding the
summary method for a GOHyperGResults object). I thought what I gave you
yesterday was pretty explicit, but maybe I can make it more so.
If we look at the code for probeSetSummary, we get to a point where we
are going to want to call the summary method on a GOHyperGResults
object. However, knowing that the correct dispatch isn't going to
happen, Seth adds in a kludgetastic little function to go out and get
the correct summary function first (which he has named in such a manner
that nobody in their right mind will ever mistakenly call it).
summary <- Category:::XXX_getSummaryGeneric_XXX()
This step ensures that the summary function called within the
probeSetSummary() function will be the correct one. In the next step, we
go ahead and call the summary function, knowing now that we have the
right one
goids <- summary(result, pvalue, categorySize)[, 1]
So for this to work with your package, you will need to add an
import(Category)
to your NAMESPACE file, and then in your function that is attempting to
use the summary function, you will need to do step number one above
first, and then you will be able to call summary correctly.
>
> I know I can access what I need using the slots of the object, I just
> figured that I would use the methods already available.
>
> For the record, determining how to go from a simple function with
> "require" to a package that has access to the right functions and
> methods is a real pain, and the documentation is none too stupendous
> on how to do that.
As with most R documentation, everything you need is there, but it has
been boiled down to the epitome of terseness. See
http://cran.r-project.org/doc/manuals/R-exts.html#Package-name-spaces
And even more enlightening, see just about any of the 'base' packages in
BioC. For instance, the NAMESPACE file for GOstats, which shows you how
to do just about any import or export directive.
Note that they are really simple in structure:
import(foo)
gets all exported functions from a package called foo.
importFrom(foo,
bar,
bas)
imports just two functions, bar and bas, from package foo, etc, etc.
Best,
Jim
>
> Thanks,
>
> -Robert
>
> Robert M. Flight, Ph.D.
> Bioinformatics and Biomedical Computing Laboratory
> University of Louisville
> Louisville, KY
>
> PH 502-852-0467
> EM robert.flight at louisville.edu
> EM rflight79 at gmail.com
>
> Williams and Holland's Law:
> If enough data is collected, anything may be proven by
> statistical methods.
I'm not sure either Williams nor Holland can be trusted to make any such
statement if they don't know that data is the plural of datum. ;-D
>
>
>
> On Thu, Jul 8, 2010 at 18:42, Martin Morgan<mtmorgan at fhcrc.org> wrote:
>> On 07/08/2010 01:56 PM, Robert M. Flight wrote:
>>> This strikes me as really weird (and annoying) behavior.
>>>
>>> I have a GOHyperGResult, calculated using GOstats and Category from
>>> which I want to obtain a summary. This summary call is within a
>>> function, that I tested time and time again to verify that it was
>>> working (worked yesterday, haven't changed my setup). However, now,
>>> whenever I call summary on the GOHyperGResult in my function, I get
>>> this (via browser(expr=TRUE) just before where I would actually use
>>> it):
>>>
>>> R> summary(GOHyperGResultObject)
>>>
>>> Length Class Mode
>>> 1 GOHyperGResult S4
>>>
>>> However, showMethods("summary") gives the following:
>>>
>>> Function: summary (package base)
>>> object="AnnDbBimap"
>>> object="ANY"
>>> object="Bimap"
>>> object="DBIObject"
>>> object="GOHyperGResult"
>>> object="HyperGResultBase"
>>> object="KEGGHyperGResult"
>>> object="LinearMResultBase"
>>> object="PFAMHyperGResult"
>>> object="SQLiteConnection"
>>> object="SQLiteDriver"
>>> object="SQLiteResult"
>>>
>>> When outside the function (in the base workspace), I get the actual
>>> summary I am after. However, when I check if there is a difference in
>>> showMethods("summary"), I see the same list:
>>> Function: summary (package base)
>>> object="AnnDbBimap"
>>> object="ANY"
>>> object="Bimap"
>>> object="DBIObject"
>>> object="GOHyperGResult"
>>> object="HyperGResultBase"
>>> object="KEGGHyperGResult"
>>> object="LinearMResultBase"
>>> object="PFAMHyperGResult"
>>> object="SQLiteConnection"
>>> object="SQLiteDriver"
>>> object="SQLiteResult"
>>>
>>> The object in the base workspace is a save of the object being
>>> generated in my function, so I know it is not because they are
>>> different objects. I thought this might due to installing a new
>>> package (KEGGgraph was the last one I installed), but even after
>>> removing and restarting the same behavior continues.
>>>
>>> If anyone could shed some light on this behavior, I would really,
>>> really appreciate it, because I can't see why this is happening. My
>>> function is in a package, do I need to explicitly import the "summary"
>>> method from GOstats in the NAMESPACE? I already have GOstats in the
>>> require, and it loads the package.
>>
>> If your function is in a package, then yes, you should in the
>> DESCRIPTION file
>>
>> Imports: GOstats
>>
>> and
>>
>> importClassesFrom(GOstats, GOHyperGResult)
>> importMethodsFrom(GOstats, summary)
>>
>> It sounds like your package has code
>>
>> require(GOstats)
>>
>> but that's not what you want to do -- it'll attach GOstats to the search
>> path, but you want GOstats, or at least the summary methods defined in
>> GOstats, available to your package without relying on the structure of
>> the (user modifiable) search path.
>>
>> I don't know the details behind Jim's suggestion, but a certain amount
>> of water has passed under the bridge since then and I'd be interested in
>> knowing whether those contortions are actually necessary in an
>> appropriately structured package.
>>
>> Martin
>>
>>
>>>
>>> Cheers,
>>>
>>> -Robert
>>>
>>> R version 2.11.1 (2010-05-31)
>>> i386-pc-mingw32
>>>
>>> locale:
>>> [1] LC_COLLATE=English_United States.1252
>>> [2] LC_CTYPE=English_United States.1252
>>> [3] LC_MONETARY=English_United States.1252
>>> [4] LC_NUMERIC=C
>>> [5] LC_TIME=English_United States.1252
>>>
>>> attached base packages:
>>> [1] grid stats graphics grDevices utils datasets methods
>>> [8] base
>>>
>>> other attached packages:
>>> [1] org.Mm.eg.db_2.4.1 GO.db_2.4.1 categoryCompare_0.1-1
>>> [4] biocGraph_1.10.0 Rgraphviz_1.26.0 hwriter_1.2
>>> [7] GOstats_2.14.0 RSQLite_0.9-1 DBI_0.2-5
>>> [10] graph_1.26.0 Category_2.14.0 AnnotationDbi_1.10.1
>>> [13] Biobase_2.8.0
>>>
>>> loaded via a namespace (and not attached):
>>> [1] annotate_1.26.0 genefilter_1.30.0 geneplotter_1.26.0 GSEABase_1.10.0
>>> [5] RBGL_1.24.0 RColorBrewer_1.0-2 splines_2.11.1 survival_2.35-8
>>> [9] tools_2.11.1 XML_3.1-0 xtable_1.5-6
>>>
>>> Robert M. Flight, Ph.D.
>>> Bioinformatics and Biomedical Computing Laboratory
>>> University of Louisville
>>> Louisville, KY
>>>
>>> PH 502-852-0467
>>> EM robert.flight at louisville.edu
>>> EM rflight79 at gmail.com
>>>
>>> Williams and Holland's Law:
>>> If enough data is collected, anything may be proven by
>>> statistical methods.
>>>
>>> _______________________________________________
>>> Bioconductor mailing list
>>> Bioconductor at stat.math.ethz.ch
>>> https://stat.ethz.ch/mailman/listinfo/bioconductor
>>> Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor
>>
>>
>> --
>> Martin Morgan
>> 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
>>
--
James W. MacDonald, M.S.
Biostatistician
Douglas Lab
University of Michigan
Department of Human Genetics
5912 Buhl
1241 E. Catherine St.
Ann Arbor MI 48109-5618
734-615-7826
**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
More information about the Bioconductor
mailing list