Re: [Rd] 'load' does not properly add 'show' methods for classes extending 'list'
I am not sure why you expected this to work: I did not expect it to and
could not find relevant documentation to suggest it should.
Loading an object created from a non-attached package does not in general
attach that package and make the methods for the class of 'x' available.
We have talked about attaching the package defining the class when an S4
object is loaded, and that is probably possible now S4 objects can be
unambiguously distinguished (although I still worry about multiple
packages with the same generic and their order on the search path).
In your example there is no specific 'show' method on the search path when
'show' is called via autoprinting in the second session, so 'showDefault'
is called. Package GSEABase gets attached as an (undocumented) side
effect of calling 'getClassDef' from 'showDefault'. I can see no
documentation (and in particular not in ?showDefault) that 'showDefault'
is supposed to attach the package defining the class and re-dispatch to a
'show' method that package contains. Since attaching packages behind the
user's back can have nasty side effects (the order of the search path does
mattter), I think the pros and cons need careful consideration: a warning
along the lines of
'object 'x' is of class "GeneSetCollection" from package 'GSEABase'
which is not on the search path
might be more appropriate. Things would potentially be a lot smoother if
namespaces could be assumed, as loading a namespace has few side effects
(and if loading a namespace registered methods for visible S4 generics
smoothly).
Until I see documentation otherwise, I will continue to assume that I do
need to attach the class-defining package(s) for things to work correctly.
On Mon, 24 Sep 2007, Martin Morgan wrote:
> The GeneSetCollection class in the Bioconductor package GSEABase
> extends 'list'
>
>> library(GSEABase)
>> showClass("GeneSetCollection")
>
> Slots:
>
> Name: .Data
> Class: list
>
> Extends:
> Class "list", from data part
> Class "vector", by class "list", distance 2
> Class "AssayData", by class "list", distance 2
>
> If I create an instance of this class and serialize it
>
>> x <- GeneSetCollection(GeneSet("X"))
>> x
> GeneSetCollection
> names: NA (1 total)
>> save(x, file="/tmp/x.rda")
>
> and then start a new R session and load the data object (without first
> library(GSEABase)), the 'show' method is not added to the appropriate
> method table.
>
>> load("/tmp/x.Rda")
>> x
> Loading required package: GSEABase
> Loading required package: Biobase
> Loading required package: tools
>
> Welcome to Bioconductor
>
> Vignettes contain introductory material. To view, type
> 'openVignette()'. To cite Bioconductor, see
> 'citation("Biobase")' and for packages 'citation(pkgname)'.
>
> Loading required package: AnnotationDbi
> Loading required package: DBI
> Loading required package: RSQLite
> An object of class "GeneSetCollection"
> [[1]]
> setName: NA
> geneIds: X (total: 1)
> geneIdType: Null
> collectionType: Null
> details: use 'details(object)'
>
> Actually, the behavior is more complicate than appears; in a new R
> session after loading /tmp/x.Rda, if I immediately do x[[1]] I get the
> show,GeneSetCollection-method but not show,GeneSet-method.
>
> Sorry for the somewhat obscure example.
>
> Martin
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] contributed CRAN packages / Windows binaries for R-2.6.0
To all CRAN package maintainers: package maintainers might want to inspect the check summary provided on CRAN (CRAN/src/contrib/checkSummary.html) in order to clean up and fix packages that result in WARNINGs or ERRORs under some operating systems. I will trigger to send out messages to those maintainers whose packages fail under today's R-2.6.0 beta for Windows. So don't be surprised. Best wishes, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] non-linear fitting (nls) and confidence limits
dear list members, my question concerns computation of confidence intervals in nonlinear fits with `nls' when weigthing the fit. the seemingly correct procedure does not work as (I) expected. I'm posting this here since: (A) the problem might suggest a modification to the `m' component in the return argument of `nls' (making this post formally OK for this list) and (B) I got no response on r-help (my "secret" motivation for posting here, hoping for some clarifications...): for _unweighted_ fits using `nls' one can compute confidence intervals for the fitted model function via #--- se.fit <- sqrt(apply(res$m$gradient(), 1, function(x) sum(vcov(res)*outer(x,x luconf <- yfit + outer(se.fit, qnorm(c(probex, 1 - probex))) #--- where `res' contains an `nls' object, `x' is the independent variable vector, `yfit' the corresponding model prediction (`fitted(res)'), `se.fit' the corresponding standard error and `luconf' the lower and upper confidence limits at some level specified by `probex'. when using the same approach with _weighted_ fits (even if all weights are equal (but not equal to one)), I noted that the confidence limits depend on the weights in an counter-intuitive, probably erroneous way. I have tracked my problem down to the fact that `res$m$gradient()' does _not_ contain the actual gradients w.r.t. the parameters but rather the gradients multiplied by the sqrt of the weights. question 1: is the fact that `m$gradient' in an `nls' object does compute the "scaled" gradients documented somewhere (I did'nt find any remark)? if no, can someone please give me a hint what the rationale behind this approach is? question 2: am I right to understand, that the above approach to compute `se.fit' (in this compact form proposed by p. daalgaard on r-help some time ago) is erroneous (for weighted nls) that I have to undo the multiplication by sqrt(weights) which is included in `m$gradient' (or compute the true gradients of my model function otherwise, e.g. with `deriv')? here is a simple example demonstrating the problem (yes, I know that this actually is a linar model :-)): #--- probex <- 0.05 x <- 1:10 y <- rnorm(x, x, .8) w1 <- rep(1, 10) w2 <- w1; w2[7:10] <- 0.01 * w2[7:10] res1 <- nls(y ~ a*x + b, data = list(x = x, y = y), start = list(a = 1, b = 0), weights = w1) res2 <- nls(y ~ a*x + b, data = list(x = x, y = y), start = list(a = 1, b = 0), weights = w2) yfit1 <- fitted(res1) yfit2 <- fitted(res2) se.fit1 <- sqrt(apply(res1$m$gradient(), 1, function(x) sum(vcov(res1)*outer(x,x luconf1 <- yfit1 + outer(se.fit1, qnorm(c(probex, 1 - probex))) se.fit2 <- sqrt(apply(res2$m$gradient(), 1, function(x) sum(vcov(res2)*outer(x,x luconf2 <- yfit2 + outer(se.fit2, qnorm(c(probex, 1 - probex))) op <- par(mfrow = c(2,1)) matplot(x, cbind(y, yfit1,luconf1), type = 'blll', pch = 1, col = c(1,2,4,4), lty = 1) matplot(x, cbind(y, yfit2,luconf2), type = 'blll', pch = 1, col = c(1,2,4,4), lty = 1) par(op, no.readonly = T) #--- the first fit uses unit weights for all data points (i.e. effectively is unweighted) and yields reasonable confidence limits. the second fit uses unequal weights (where the last 4 points have very small weights and are next to irrelevant for the fit result). the computed confidence intervals in this case are only fine up to point no. 6, but nonsense afterwards. question 3: computing confidence limits for the fitted model is a rather frequent requirement (and it occures by and then on r-help). would it not be a reasonable (and small) modification to `nls' to add a further argument "conf = NA" so that if `nls' is called, e.g. with "conflim = 0.95", the confidence limits are computed and are returned in a new component `res$m$conf' of the `m' component of an nls object? (alternatively, computation of `se.fit' (in the notation used above) would suffice. this could also be achieved by making the `se.fit' flag in `predict.nls' operational. either way would seem a valuable improvement to the nls functionality, I believe.) any feedback appreciated. thanks, joerg __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'load' does not properly add 'show' methods for classes extending 'list'
I think that it would be best then, not to load the package, as loading
it in this way, means that it is almost impossible to get the methods
registered correctly. That does seem to be a bug, or at least a major
inconvenience. And one might wonder at the purpose of attaching if not
to make methods available.
That said the documentation, indeed does not state that anything good
will happen. It also does not state that something bad will happen either.
best wishes
Robert
Prof Brian Ripley wrote:
> I am not sure why you expected this to work: I did not expect it to and
> could not find relevant documentation to suggest it should.
>
> Loading an object created from a non-attached package does not in general
> attach that package and make the methods for the class of 'x' available.
> We have talked about attaching the package defining the class when an S4
> object is loaded, and that is probably possible now S4 objects can be
> unambiguously distinguished (although I still worry about multiple
> packages with the same generic and their order on the search path).
>
> In your example there is no specific 'show' method on the search path when
> 'show' is called via autoprinting in the second session, so 'showDefault'
> is called. Package GSEABase gets attached as an (undocumented) side
> effect of calling 'getClassDef' from 'showDefault'. I can see no
> documentation (and in particular not in ?showDefault) that 'showDefault'
> is supposed to attach the package defining the class and re-dispatch to a
> 'show' method that package contains. Since attaching packages behind the
> user's back can have nasty side effects (the order of the search path does
> mattter), I think the pros and cons need careful consideration: a warning
> along the lines of
>
>'object 'x' is of class "GeneSetCollection" from package 'GSEABase'
>which is not on the search path
>
> might be more appropriate. Things would potentially be a lot smoother if
> namespaces could be assumed, as loading a namespace has few side effects
> (and if loading a namespace registered methods for visible S4 generics
> smoothly).
>
> Until I see documentation otherwise, I will continue to assume that I do
> need to attach the class-defining package(s) for things to work correctly.
>
>
> On Mon, 24 Sep 2007, Martin Morgan wrote:
>
>> The GeneSetCollection class in the Bioconductor package GSEABase
>> extends 'list'
>>
>>> library(GSEABase)
>>> showClass("GeneSetCollection")
>> Slots:
>>
>> Name: .Data
>> Class: list
>>
>> Extends:
>> Class "list", from data part
>> Class "vector", by class "list", distance 2
>> Class "AssayData", by class "list", distance 2
>>
>> If I create an instance of this class and serialize it
>>
>>> x <- GeneSetCollection(GeneSet("X"))
>>> x
>> GeneSetCollection
>> names: NA (1 total)
>>> save(x, file="/tmp/x.rda")
>> and then start a new R session and load the data object (without first
>> library(GSEABase)), the 'show' method is not added to the appropriate
>> method table.
>>
>>> load("/tmp/x.Rda")
>>> x
>> Loading required package: GSEABase
>> Loading required package: Biobase
>> Loading required package: tools
>>
>> Welcome to Bioconductor
>>
>> Vignettes contain introductory material. To view, type
>> 'openVignette()'. To cite Bioconductor, see
>> 'citation("Biobase")' and for packages 'citation(pkgname)'.
>>
>> Loading required package: AnnotationDbi
>> Loading required package: DBI
>> Loading required package: RSQLite
>> An object of class "GeneSetCollection"
>> [[1]]
>> setName: NA
>> geneIds: X (total: 1)
>> geneIdType: Null
>> collectionType: Null
>> details: use 'details(object)'
>>
>> Actually, the behavior is more complicate than appears; in a new R
>> session after loading /tmp/x.Rda, if I immediately do x[[1]] I get the
>> show,GeneSetCollection-method but not show,GeneSet-method.
>>
>> Sorry for the somewhat obscure example.
>>
>> Martin
>>
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
Hi, R-2.6 + install.packages() doesn't find rggobi on Mac OS X. The .tgz file is here: http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ but it is not listed in the PACKAGES file: http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES Any idea why? Thanks! H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
On Sep 25, 2007, at 12:58 PM, Herve Pages wrote: > Hi, > > R-2.6 + install.packages() doesn't find rggobi on Mac OS X. > The .tgz file is here: > > http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ > > but it is not listed in the PACKAGES file: > > http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES > > Any idea why? > Yes, because it doesn't work - please see the check results: http://cran.r-project.org/src/contrib/checkSummary.html I have verified it today and the ggobi binary from the ggobi pages is still not fixed. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
Actually, the fact that the tar ball is there must be a mirroring problem, because it's not on the master CRAN server. You should fix your mirror - objects may appear closer ... ;) Cheers, Simon On Sep 25, 2007, at 4:28 PM, Simon Urbanek wrote: > > On Sep 25, 2007, at 12:58 PM, Herve Pages wrote: > >> Hi, >> >> R-2.6 + install.packages() doesn't find rggobi on Mac OS X. >> The .tgz file is here: >> >> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ >> >> but it is not listed in the PACKAGES file: >> >> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES >> >> Any idea why? >> > > Yes, because it doesn't work - please see the check results: > http://cran.r-project.org/src/contrib/checkSummary.html > > I have verified it today and the ggobi binary from the ggobi pages > is still not fixed. > > Cheers, > Simon > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
On 9/25/07, Simon Urbanek <[EMAIL PROTECTED]> wrote: > > On Sep 25, 2007, at 12:58 PM, Herve Pages wrote: > > > Hi, > > > > R-2.6 + install.packages() doesn't find rggobi on Mac OS X. > > The .tgz file is here: > > > > http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ > > > > but it is not listed in the PACKAGES file: > > > > http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES > > > > Any idea why? > > > > Yes, because it doesn't work - please see the check results: > http://cran.r-project.org/src/contrib/checkSummary.html > > I have verified it today and the ggobi binary from the ggobi pages is > still not fixed. What's wrong with it? We haven't any problems reported. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
On Sep 25, 2007, at 4:33 PM, hadley wickham wrote: > On 9/25/07, Simon Urbanek <[EMAIL PROTECTED]> wrote: >> >> On Sep 25, 2007, at 12:58 PM, Herve Pages wrote: >> >>> Hi, >>> >>> R-2.6 + install.packages() doesn't find rggobi on Mac OS X. >>> The .tgz file is here: >>> >>> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ >>> >>> but it is not listed in the PACKAGES file: >>> >>> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES >>> >>> Any idea why? >>> >> >> Yes, because it doesn't work - please see the check results: >> http://cran.r-project.org/src/contrib/checkSummary.html >> >> I have verified it today and the ggobi binary from the ggobi pages is >> still not fixed. > > What's wrong with it? We haven't any problems reported. > It's linking to a non-existent libfreetype (see the output of the make check) and it got reported to me a month ago by Heike. At that time we also discussed the fix and I was assuming that you were in the loop (I guess you have a dynamic freetype masking the static one in /usr/local/lib). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rggobi not in bin/macosx/universal/contrib/2.6/PACKAGES on CRAN
On 9/25/07, Simon Urbanek <[EMAIL PROTECTED]> wrote: > > On Sep 25, 2007, at 4:33 PM, hadley wickham wrote: > > > On 9/25/07, Simon Urbanek <[EMAIL PROTECTED]> wrote: > >> > >> On Sep 25, 2007, at 12:58 PM, Herve Pages wrote: > >> > >>> Hi, > >>> > >>> R-2.6 + install.packages() doesn't find rggobi on Mac OS X. > >>> The .tgz file is here: > >>> > >>> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/ > >>> > >>> but it is not listed in the PACKAGES file: > >>> > >>> http://cran.fhcrc.org/bin/macosx/universal/contrib/2.6/PACKAGES > >>> > >>> Any idea why? > >>> > >> > >> Yes, because it doesn't work - please see the check results: > >> http://cran.r-project.org/src/contrib/checkSummary.html > >> > >> I have verified it today and the ggobi binary from the ggobi pages is > >> still not fixed. > > > > What's wrong with it? We haven't any problems reported. > > > > It's linking to a non-existent libfreetype (see the output of the > make check) and it got reported to me a month ago by Heike. At that > time we also discussed the fix and I was assuming that you were in > the loop (I guess you have a dynamic freetype masking the static one > in /usr/local/lib). I thought I had fixed that - are you sure you have downloaded recently? Another guy reported the problem and the updated version worked for him. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
