[Rd] conflict between lme4 and RMySQL packages (PR#9753)
Full_Name: Dale Barr Version: 2.5.1 (patched) OS: Ubuntu linux x86_64 Submission from: (NULL) (138.23.70.108) When RMySQL is loaded in before lme4, the summary() function for lmer objects in the lme4 packages produces the following error: Error in printMer(object) : no slot of name "status" for this object of class "table" When RMySQL is loaded AFTER lme4, however, no such error arises. For example, the following code gives the error: > library(RMySQL) Loading required package: DBI > library(lme4) Loading required package: Matrix Loading required package: lattice > data(sleepstudy) > fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) > summary(fm1) Error in printMer(object) : no slot of name "status" for this object of class "table" Now, here is the exact same code except that lme4 is loaded before RMySQL. The summary function works properly. > library(lme4) Loading required package: Matrix Loading required package: lattice library(RMySQL)> library(RMySQL) Loading required package: DBI > data(sleepstudy) > fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) > summary(fm1) Linear mixed-effects model fit by REML Formula: Reaction ~ Days + (Days | Subject) Data: sleepstudy AIC BIC logLik MLdeviance REMLdeviance 1754 1770 -871.8 1752 1744 Random effects: Groups NameVariance Std.Dev. Corr Subject (Intercept) 610.835 24.7151 Days 35.056 5.9208 0.067 Residual 655.066 25.5943 number of obs: 180, groups: Subject, 18 Fixed effects: Estimate Std. Error t value (Intercept) 251.405 6.820 36.86 Days 10.467 1.5466.77 Correlation of Fixed Effects: (Intr) Days -0.137 MY SESSION INFO: R version 2.5.1 RC (2007-06-22 r42030) x86_64-unknown-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" [7] "base" other attached packages: RMySQL DBIlme4 Matrix lattice "0.6-0" "0.2-3" "0.99875-2" "0.99875-2" "0.15-11" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R routine standalone
I'm writing a C program and I'd like to include in it some R routine (quantile functions, typically). I found the functions I have to use (qnorm.c qbeta.c ecc) e some include (nmath.h rmath.h ecc). But I can't compile the project, I receive linker error. Somebody can help me? I say, if I want to include qbeta (for example) in a project of mine, what should I do? ___ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in getVarCov.gls method (PR#9752)
Hello,
I am using R2.5 under Windows.
Looks like the following statement
vars <- (obj$sigma^2)*vw
in getVarCov.gls method (nlme package) needs to be replaced with:
vars <- (obj$sigma*vw)^2
With best regards
Andrzej Galecki
Douglas Bates wrote:
>I'm not sure when the getVarCov.gls method was written or by whom. To
>tell the truth I'm not really sure what it should do.
>
>Does anyone have recommendations about what to do? The simplest
>thing, if the method is giving incorrect results, is to eliminate the
>method entirely. Any objections to my doing that?
>
>The method is currently defined as
>
>getVarCov.gls <-
>function(obj, individual = 1, ...)
>{
>S <- corMatrix(obj$modelStruct$corStruct)[[individual]]
>if (!is.null( obj$modelStruct$varStruct))
>{
>ind <- obj$groups==individual
>vw <- 1/varWeights(obj$modelStruct$varStruct)[ind]
>}
>else vw <- rep(1,nrow(S))
>vars <- (obj$sigma^2)*vw
>result <- t(S * sqrt(vars))*sqrt(vars)
>class(result) <- c("marginal","VarCov")
>attr(result,"group.levels") <- names(obj$groups)
>result
>}
>
>
>On 2/23/06, Mary Lindstrom <[EMAIL PROTECTED]> wrote:
>
>
>>Sounds like the documentation should be changed. Doug? Jose?
>>
>>- Mary
>>
>>Andrzej Galecki ([EMAIL PROTECTED]) writes:
>> > Hi Mary,
>> >
>> > Thank you for your response. Note that we followed R documentation,
>> > which states that getVarCov() can be used with gls() objects.
>> >
>> > Thanks again.
>> >
>> > Andrzej
>> >
>> > Mary Lindstrom wrote:
>> >
>> > >Sorry once again for the slow response. When I wrote getVarCov I was
>> > >not thinking of using it for gls objects. Sounds like it doesn't work
>> > >for them. Either the code should be changed to reject the request when
>> > >the object has class gls or it should be rewritten to work correctly.
>> > >
>> > >- Mary
>> > >
>> > >Andrzej Galecki ([EMAIL PROTECTED]) writes:
>> > > > Hi Mary,
>> > > >
>> > > > Our question is about variance-covariance matrix, hat(sigma_i),
>> > > > returned by getVarCov() function when applied to model fit generated by
>> > > > gls( ) function. It appears that at least in our example the returned
>> > > > matrix was incorrect. Are you aware of any problem with getVarCov ()
>> > > > when applied to an object generated by gls()?
>> > > >
>> > > > To be more specific our impression is that getVarCov() expects to get
>> > > > variances as an input
>> > > > and instead it gets standard deviations and corresponding ratios.
>> > > >
>> > > > Sorry we did not state our question more precisely.
>> > > >
>> > > > Thank you
>> > > >
>> > > > Andrzej
>> > > >
>> > > > PS. Here is our original question to Jose. His response was that the
>> > > > gls() syntax was correct and he directed us to you or to D.Bates
>> > > >
>> > > > We used gls() to fit a marginal model with unstructured
>> > > > covariance matrix. Could you verify gls() syntax, especially part
>> > > > specifying correlation matrix and variance function? Assuming that our
>> > > > gls() code is correct, we think that getVarCoV() returns incorrect
>> > > > marginal covariance matrix in this example. Are you aware of any
>> > > > problems with getVarCov(), when used with a model fit returned by
>> > > > gls()? If you think that getVarCov() should work fine in the context
>> > > > of
>> > > > this model we are ready to send you a relevant code, in which we
>> > > > extract
>> > > > information from gls() fit and 'manualy' calculate marginal
>> > > > variance-covariance matrix and cross-check it with the output from SAS.
>> > > > Our impression is that getVarCov() expects to get variances as an input
>> > > > and instead it gets standard deviations and corresponding ratios. We
>> > > > would really like to get to the bottom of this issue.
>> > > >
>> > > >
>> > > > Mary Lindstrom wrote:
>> > > >
>> > > > >Hi Andrzej
>> > > > >
>> > > > > > Original Message
>> > > > > > Subject: Re: [Fwd: Mixed Models book.]
>> > > > > > Date:Thu, 19 Jan 2006 13:06:09 -0500
>> > > > > > From:[EMAIL PROTECTED]
>> > > > > > To: Andrzej Galecki <[EMAIL PROTECTED]>
>> > > > > >
>> > > > > > The getVarCov function was actually written by Mary Lindstrom and,
>> > > > > > as a
>> > > > > > far as I know, adapted to R
>> > > > > > by Douglas Bates. I did think about including it in the S-PLUS
>> > > > > > version
>> > > > > > as well, but never got around
>> > > > > > to it. My understanding is that it should also work with gls
>> > > > > > objects,
>> > > > > > but I believe the main motivation
>> > > > > > was to have it for lme objects. I am not sure if the example is
>> > > > > > triggering some possible bug in the
>> > > > > > code, but perhaps you can ask Mary or Douglas if an updated
>> > > > > > version may
>> > > > > > be available. I will not have
>> > > > > > time to look at the code and get back to you before the deadlines
>> > > > > > you
>> > > > > > ha
Re: [Rd] R routine standalone
You have not told us your OS nor version of R. The file src/nmath/standalone/README in the R sources will either tell you how to do this or point you to the current documentation (depending on the R version). At a guess (since you use 'project' and don't have the correct case on your file names) you are working with Visual Studio or similar under Windows. In that case you are on your own: the R developers only support the use of MinGW on Windows (but see README.packages for some hints which you should be able to adapt to link to Rmath.dll). On Mon, 25 Jun 2007, Gatsu wrote: > I'm writing a C program and I'd like to include in it > some R routine (quantile functions, typically). > > I found the functions I have to use (qnorm.c qbeta.c > ecc) e some include (nmath.h rmath.h ecc). > > But I can't compile the project, I receive linker > error. > > Somebody can help me? > > I say, if I want to include qbeta (for example) in a > project of mine, what should I do? > > > ___ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- 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
Re: [Rd] Bug in getVarCov.gls method (PR#9752)
On Mon, 25 Jun 2007, [EMAIL PROTECTED] wrote: > I am using R2.5 under Windows. I presume you mean 2.5.0 (there is no R2.5: see the posting guide). But which version of nlme, which is the relevant fact here? The R posting guide suggests showing the output of sessionInfo() to establish the environment used. > Looks like the following statement > > vars <- (obj$sigma^2)*vw > > in getVarCov.gls method (nlme package) needs to be replaced with: > > vars <- (obj$sigma*vw)^2 We need some evidence! Please supply a reproducible example and give your reasoning. For example, the FAQ says The most important principle in reporting a bug is to report _facts_, not hypotheses or categorizations. It is always easier to report the facts, but people seem to prefer to strain to posit explanations and report them instead. If the explanations are based on guesses about how R is implemented, they will be useless; others will have to try to figure out what the facts must have been to lead to such speculations. Sometimes this is impossible. But in any case, it is unnecessary work for the ones trying to fix the problem. It is very useful to try and find simple examples that produce apparently the same bug, and somewhat useful to find simple examples that might be expected to produce the bug but actually do not. If you want to debug the problem and find exactly what caused it, that is wonderful. You should still report the facts as well as any explanations or solutions. Please include an example that reproduces the problem, preferably the simplest one you have found. It should be easily possible to cross-check an example with one of the many other ways available to do GLS fits in R. [...] -- 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
Re: [Rd] conflict between lme4 and RMySQL packages (PR#9753)
Thank you, Dale. I think you've revealed a bug in the method dispatch mechanism. I'm adding here a script which confirms your finding and add slightly more insight: library(RMySQL) library(lme4) data(sleepstudy) fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) ## MM: First save, then print -- the error is in "print" i.e. show() : s1 <- summary(fm1) s1 #-> error in printMer() which is hidden : debug(lme4:::printMer) s1 # --> printMer(x, ..) calls so <- summary(x) at the very beginning ## and indeed, summary(x) -- *inside* printMer() dispatches wrongly ## whereas top-level, there is no problem : ## maybe here, or then later undebug(lme4:::printMer) ## This works fine top-level, but gives non-sense when inside printMer() !! ## so <- summary(s1) ## does nothing, since s1 *is* already summary.lmer : stopifnot(identical(so, s1)) # ok ## one other symptom of the same problem: showMethods(summary) ## is fine top-level ## whereas it does not see the correct methods when used from inside printMer() ## i.e., also when debugging > "db" == dale barr <[EMAIL PROTECTED]> > on Tue, 26 Jun 2007 00:57:22 +0200 (CEST) writes: db> Full_Name: Dale Barr db> Version: 2.5.1 (patched) db> OS: Ubuntu linux x86_64 db> Submission from: (NULL) (138.23.70.108) db> When RMySQL is loaded in before lme4, the summary() function for lmer objects in db> the lme4 packages produces the following error: db> Error in printMer(object) : no slot of name "status" for this object of class db> "table" db> When RMySQL is loaded AFTER lme4, however, no such error arises. For example, db> the following code gives the error: >> library(RMySQL) db> Loading required package: DBI >> library(lme4) db> Loading required package: Matrix db> Loading required package: lattice >> data(sleepstudy) >> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) >> summary(fm1) db> Error in printMer(object) : no slot of name "status" for this object of class db> "table" db> Now, here is the exact same code except that lme4 is loaded before RMySQL. The db> summary function works properly. >> library(lme4) db> Loading required package: Matrix db> Loading required package: lattice db> library(RMySQL)> library(RMySQL) db> Loading required package: DBI >> data(sleepstudy) >> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy) >> summary(fm1) db> Linear mixed-effects model fit by REML db> Formula: Reaction ~ Days + (Days | Subject) db> Data: sleepstudy db> AIC BIC logLik MLdeviance REMLdeviance db> 1754 1770 -871.8 1752 1744 db> Random effects: db> Groups NameVariance Std.Dev. Corr db> Subject (Intercept) 610.835 24.7151 db> Days 35.056 5.9208 0.067 db> Residual 655.066 25.5943 db> number of obs: 180, groups: Subject, 18 db> Fixed effects: db> Estimate Std. Error t value db> (Intercept) 251.405 6.820 36.86 db> Days 10.467 1.5466.77 db> Correlation of Fixed Effects: db> (Intr) db> Days -0.137 db> MY SESSION INFO: db> R version 2.5.1 RC (2007-06-22 r42030) db> x86_64-unknown-linux-gnu db> locale: db> LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C db> attached base packages: db> [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" db> [7] "base" db> other attached packages: db> RMySQL DBIlme4 Matrix lattice db> "0.6-0" "0.2-3" "0.99875-2" "0.99875-2" "0.15-11" db> __ db> R-devel@r-project.org mailing list db> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conflict between lme4 and RMySQL packages (PR#9753)
You have three summary() functions here:
> library(RMySQL)
Loading required package: DBI
> library(lme4)
Loading required package: Matrix
Loading required package: lattice
> find("summary")
[1] "package:Matrix" "package:DBI""package:base"
and this is simply a namespace issue (note the environments):
> summary
standardGeneric for "summary" defined from package "base"
function (object, ...)
standardGeneric("summary")
Methods may be defined for arguments: object
> Matrix:::summary
standardGeneric for "summary" defined from package "base"
function (object, ...)
standardGeneric("summary")
Methods may be defined for arguments: object
> DBI:::summary
standardGeneric for "summary" defined from package "base"
function (object, ...)
standardGeneric("summary")
Methods may be defined for arguments: object
so the visible summary() from package:Matrix is a copy of that in the DBI
namespace, not that in the Matrix namespace. Since lme4 imports all of
Matrix, it imports its take-over of summary. So the issue is not *S4*
dispatch per se, but how the 'methods' package copes with two or more
packages presenting the same generic.
If you dig a bit deeper,
> ls(environment(summary)$".AllMTable")
[1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
[5] "MySQLResult" "lmer2" "mer" "sparseMatrix"
[9] "summary.lmer2" "summary.mer"
> ls(environment(summary)$".AllMTable")
[1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
[5] "MySQLResult" "lmer2" "mer" "sparseMatrix"
[9] "summary.lmer2" "summary.mer"
> ls(environment(Matrix:::summary)$".AllMTable")
[1] "ANY" "sparseMatrix"
> ls(environment(DBI:::summary)$".AllMTable")
[1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
[5] "MySQLResult" "lmer2" "mer" "sparseMatrix"
[9] "summary.lmer2" "summary.mer"
shows the issue: the methods do not get stored on the version in the
Matrix namespace, but rather on the version in package:Matrix which was
copied from the existing export and not Matrix:::summary.
Clearly there is going to be a namespace problem one way round: what seems
undocumented is which.
On Tue, 26 Jun 2007, [EMAIL PROTECTED] wrote:
> Thank you, Dale.
>
> I think you've revealed a bug in the method dispatch mechanism.
> I'm adding here a script which confirms your finding and add
> slightly more insight:
>
> library(RMySQL)
> library(lme4)
>
> data(sleepstudy)
> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy)
>
> ## MM: First save, then print -- the error is in "print" i.e. show() :
> s1 <- summary(fm1)
> s1 #-> error in printMer() which is hidden :
>
> debug(lme4:::printMer)
> s1 # --> printMer(x, ..) calls so <- summary(x) at the very beginning
> ## and indeed, summary(x) -- *inside* printMer() dispatches wrongly
> ## whereas top-level, there is no problem :
>
> ## maybe here, or then later
> undebug(lme4:::printMer)
>
> ## This works fine top-level, but gives non-sense when inside printMer() !!
> ##
> so <- summary(s1) ## does nothing, since s1 *is* already summary.lmer :
> stopifnot(identical(so, s1)) # ok
>
> ## one other symptom of the same problem:
> showMethods(summary) ## is fine top-level
>
> ## whereas it does not see the correct methods when used from inside
> printMer()
> ## i.e., also when debugging
>
>
>
>> "db" == dale barr <[EMAIL PROTECTED]>
>> on Tue, 26 Jun 2007 00:57:22 +0200 (CEST) writes:
>
>db> Full_Name: Dale Barr
>db> Version: 2.5.1 (patched)
>db> OS: Ubuntu linux x86_64
>db> Submission from: (NULL) (138.23.70.108)
>
>
>db> When RMySQL is loaded in before lme4, the summary() function for lmer
> objects in
>db> the lme4 packages produces the following error:
>
>db> Error in printMer(object) : no slot of name "status" for this object
> of class
>db> "table"
>
>db> When RMySQL is loaded AFTER lme4, however, no such error arises. For
> example,
>db> the following code gives the error:
>
>>> library(RMySQL)
>db> Loading required package: DBI
>>> library(lme4)
>db> Loading required package: Matrix
>db> Loading required package: lattice
>>> data(sleepstudy)
>>> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy)
>>> summary(fm1)
>db> Error in printMer(object) : no slot of name "status" for this object
> of class
>db> "table"
>
>db> Now, here is the exact same code except that lme4 is loaded before
> RMySQL. The
>db> summary function works properly.
>
>>> library(lme4)
>db> Loading required package: Matrix
>db> Loading required package: lattice
>db> library(RMySQL)> library(RMySQL)
>db> Loading required package: DBI
>>> data(sleepstudy)
>>> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy)
>>> summary(fm1)
>db> Linear mixed-effects model fit by REML
>db> Formula: Reaction ~ Days + (D
[Rd] boxplot and bxp do not respect xlim by default (PR#9754)
Full_Name: Steve Ellison
Version: 2.4.1
OS: Windows, Linux
Submission from: (NULL) (194.73.101.157)
bxp() allows specifcation of box locations with at=, but neither adjusts xlim=
to fit at nor does it respect xlim provided explicitly.
This is because bxp() now includes explicit xlim as c(0.5, n+0.5), without
checking for explicitly supplied xlim (or ylim if horizontal).
This also prevents simple added plots (eg if add=T, with at=(1:n)+0.5, the last
box is partly off the plot.
The 'offending' code is in bxp:
if (!add) {
plot.new()
if (horizontal)
plot.window(ylim = c(0.5, n + 0.5), xlim = ylim,
log = log, xaxs = pars$yaxs)
else plot.window(xlim = c(0.5, n + 0.5), ylim = ylim,
log = log, yaxs = pars$yaxs)
}
Suggested fix:
if (!add) {
plot.new()
bxp.limits <- if(!is.null(at)) {
c(at[1]-(at[2]-at[1])/2, at[n]+(at[n]-at[n-1])/2 )
} else {
c(0.5, n + 0.5)
}
if (horizontal)
plot.window(ylim = if(is.null(pars$xlim)) bxp.limits else
pars$xlim,
xlim = ylim, log = log, xaxs = pars$yaxs)
else plot.window(xlim = if(is.null(pars$xlim)) bxp.limits else
pars$xlim,
ylim = ylim, log = log, yaxs = pars$yaxs)
}
This retains the current defaults for xlim with at unspecified but allows
explicit specification of xlim. (which is the grouping level axis whether
horizontal or vertical).
I've tested the above as far as producing a modified bxp and plotting a boxplot
object, but have not tried calling direct from boxplot. boxplot() should,
however, not need modification as xlim and ylim are, I believe, passed via the
namedargs list in the bxp call.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot and bxp do not respect xlim by default (PR#9754)
On 6/26/2007 8:16 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Steve Ellison
> Version: 2.4.1
> OS: Windows, Linux
> Submission from: (NULL) (194.73.101.157)
That version is obsolete, but this problem is still present in R-devel.
I'll take a look.
Duncan Murdoch
>
>
> bxp() allows specifcation of box locations with at=, but neither adjusts xlim=
> to fit at nor does it respect xlim provided explicitly.
>
> This is because bxp() now includes explicit xlim as c(0.5, n+0.5), without
> checking for explicitly supplied xlim (or ylim if horizontal).
>
> This also prevents simple added plots (eg if add=T, with at=(1:n)+0.5, the
> last
> box is partly off the plot.
>
> The 'offending' code is in bxp:
> if (!add) {
> plot.new()
> if (horizontal)
> plot.window(ylim = c(0.5, n + 0.5), xlim = ylim,
> log = log, xaxs = pars$yaxs)
> else plot.window(xlim = c(0.5, n + 0.5), ylim = ylim,
> log = log, yaxs = pars$yaxs)
> }
>
> Suggested fix:
>if (!add) {
> plot.new()
> bxp.limits <- if(!is.null(at)) {
> c(at[1]-(at[2]-at[1])/2, at[n]+(at[n]-at[n-1])/2 )
>} else {
> c(0.5, n + 0.5)
>}
> if (horizontal)
> plot.window(ylim = if(is.null(pars$xlim)) bxp.limits else
> pars$xlim,
> xlim = ylim, log = log, xaxs = pars$yaxs)
> else plot.window(xlim = if(is.null(pars$xlim)) bxp.limits else
> pars$xlim,
> ylim = ylim, log = log, yaxs = pars$yaxs)
> }
>
>
> This retains the current defaults for xlim with at unspecified but allows
> explicit specification of xlim. (which is the grouping level axis whether
> horizontal or vertical).
>
> I've tested the above as far as producing a modified bxp and plotting a
> boxplot
> object, but have not tried calling direct from boxplot. boxplot() should,
> however, not need modification as xlim and ylim are, I believe, passed via the
> namedargs list in the bxp call.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot and bxp do not respect xlim by default (PR#9754)
On 6/26/2007 8:16 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Steve Ellison
> Version: 2.4.1
> OS: Windows, Linux
> Submission from: (NULL) (194.73.101.157)
>
>
> bxp() allows specifcation of box locations with at=, but neither adjusts xlim=
> to fit at nor does it respect xlim provided explicitly.
>
> This is because bxp() now includes explicit xlim as c(0.5, n+0.5), without
> checking for explicitly supplied xlim (or ylim if horizontal).
>
> This also prevents simple added plots (eg if add=T, with at=(1:n)+0.5, the
> last
> box is partly off the plot.
>
> The 'offending' code is in bxp:
> if (!add) {
> plot.new()
> if (horizontal)
> plot.window(ylim = c(0.5, n + 0.5), xlim = ylim,
> log = log, xaxs = pars$yaxs)
> else plot.window(xlim = c(0.5, n + 0.5), ylim = ylim,
> log = log, yaxs = pars$yaxs)
> }
>
> Suggested fix:
>if (!add) {
> plot.new()
> bxp.limits <- if(!is.null(at)) {
> c(at[1]-(at[2]-at[1])/2, at[n]+(at[n]-at[n-1])/2 )
>} else {
> c(0.5, n + 0.5)
>}
> if (horizontal)
> plot.window(ylim = if(is.null(pars$xlim)) bxp.limits else
> pars$xlim,
> xlim = ylim, log = log, xaxs = pars$yaxs)
> else plot.window(xlim = if(is.null(pars$xlim)) bxp.limits else
> pars$xlim,
> ylim = ylim, log = log, yaxs = pars$yaxs)
> }
>
>
> This retains the current defaults for xlim with at unspecified but allows
> explicit specification of xlim. (which is the grouping level axis whether
> horizontal or vertical).
But it fails in a few other cases: if the user sets the widths, this
doesn't respect that setting; if the user specifies the location of one
boxplot (so length(at) == 1) it fails when it tries to access at[2].
This is a somewhat tricky problem, that needs more careful thought than
I have time for right now, so I'll leave it for someone else (or for
myself in a less busy future, which may exist in some alternate universe).
What I'd suggest you do in the short term is simply to set up the plot
axes the way you want before calling bxp, then call it with add=TRUE.
Duncan Murdoch
>
> I've tested the above as far as producing a modified bxp and plotting a
> boxplot
> object, but have not tried calling direct from boxplot. boxplot() should,
> however, not need modification as xlim and ylim are, I believe, passed via the
> namedargs list in the bxp call.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] boxplot and bxp do not respect xlim by default (PR#9756)
What is mystifying is that the issue was not present in previous versions, =
so appropriate code already existed.
However, I agree that there seem to be a couple of additional issues that =
I had missed. =20
I am perfectly happy to look at this again myself, though, and provide =
extended code; would that help?
S
> This retains the current defaults for xlim with at unspecified but =
allows
> explicit specification of xlim. (which is the grouping level axis =
whether
> horizontal or vertical).
But it fails in a few other cases: if the user sets the widths, this=20
doesn't respect that setting; if the user specifies the location of one=20
boxplot (so length(at) =3D=3D 1) it fails when it tries to access at[2].
This is a somewhat tricky problem, that needs more careful thought than=20
I have time for right now, so I'll leave it for someone else (or for=20
myself in a less busy future, which may exist in some alternate universe).
What I'd suggest you do in the short term is simply to set up the plot=20
axes the way you want before calling bxp, then call it with add=3DTRUE.
Duncan Murdoch
=
***=0D=0A=
This email and any attachments are confidential. Any use, co...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conflict between lme4 and RMySQL packages (PR#9753)
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 26 Jun 2007 10:51:03 +0100 (BST) writes:
BDR> You have three summary() functions here:
>> library(RMySQL)
BDR> Loading required package: DBI
>> library(lme4)
BDR> Loading required package: Matrix
BDR> Loading required package: lattice
>> find("summary")
BDR> [1] "package:Matrix" "package:DBI""package:base"
BDR> and this is simply a namespace issue (note the environments):
>> summary
BDR> standardGeneric for "summary" defined from package "base"
BDR> function (object, ...)
BDR> standardGeneric("summary")
BDR>
BDR> Methods may be defined for arguments: object
>> Matrix:::summary
BDR> standardGeneric for "summary" defined from package "base"
BDR> function (object, ...)
BDR> standardGeneric("summary")
BDR>
BDR> Methods may be defined for arguments: object
>> DBI:::summary
BDR> standardGeneric for "summary" defined from package "base"
BDR> function (object, ...)
BDR> standardGeneric("summary")
BDR>
BDR> Methods may be defined for arguments: object
BDR> so the visible summary() from package:Matrix is a copy of that in the
DBI
BDR> namespace, not that in the Matrix namespace.
BDR> Since lme4 imports all of
BDR> Matrix, it imports its take-over of summary. So the issue is not *S4*
BDR> dispatch per se, but how the 'methods' package copes with two or more
BDR> packages presenting the same generic.
yes. And that's what I meant.
The problem is --- not for the first time ---
that in this case, from an S4 point of view, you would want to
keep only one version of summary(), namely ``the generic'',
and all packages / namespaces loaded and all other
setMethod(summary, ...)
should ``attach'' their methods to that generic.
{and of also get an error or at least a loud warning when
re-setting a method for a signature that already has a method
set ``with the generic''. }
I think we should provide useRs and package writers a way to
achieve that --- which I think is pretty close to having the S4
generic behave as if there were no namespaces.
The other approach, that some of the bioconductor folks
advocate, is for each package to define it's own version of the
generic explicitly, by setGeneric(..).
But that also breaks functionality, namely that of all toplevel calls {of
summary() in this case} apart from the ones of the last package loaded,
where as the namespace-internal calls {e.g., the summary(.)
inside printMer(.) in the given case} will continue to work.
BDR> If you dig a bit deeper,
>> ls(environment(summary)$".AllMTable")
BDR> [1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
BDR> [5] "MySQLResult" "lmer2" "mer"
"sparseMatrix"
BDR> [9] "summary.lmer2" "summary.mer"
>> ls(environment(summary)$".AllMTable")
BDR> [1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
BDR> [5] "MySQLResult" "lmer2" "mer"
"sparseMatrix"
BDR> [9] "summary.lmer2" "summary.mer"
>> ls(environment(Matrix:::summary)$".AllMTable")
BDR> [1] "ANY" "sparseMatrix"
>> ls(environment(DBI:::summary)$".AllMTable")
BDR> [1] "ANY" "DBIObject" "MySQLConnection" "MySQLDriver"
BDR> [5] "MySQLResult" "lmer2" "mer"
"sparseMatrix"
BDR> [9] "summary.lmer2" "summary.mer"
BDR> shows the issue: the methods do not get stored on the version in the
BDR> Matrix namespace, but rather on the version in package:Matrix which
was
BDR> copied from the existing export and not Matrix:::summary.
BDR> Clearly there is going to be a namespace problem one
BDR> way round: what seems undocumented is which.
Hmm, haven't we been "here" before and come to the conclusion
that we'd like a special namespace, ("base4" IIRC ??), for all
those "global S4 generics" ?
Martin
BDR> On Tue, 26 Jun 2007, [EMAIL PROTECTED] wrote:
>> Thank you, Dale.
>>
>> I think you've revealed a bug in the method dispatch mechanism.
>> I'm adding here a script which confirms your finding and add
>> slightly more insight:
>>
>> library(RMySQL)
>> library(lme4)
>>
>> data(sleepstudy)
>> fm1 <- lmer(Reaction ~ Days + (Days|Subject), sleepstudy)
>>
>> ## MM: First save, then print -- the error is in "print" i.e. show() :
>> s1 <- summary(fm1)
>> s1 #-> error in printMer() which is hidden :
>>
>> debug(lme4:::printMer)
>> s1 # --> printMer(x, ..) calls so <- summary(x) at the very beginning
>> ## and indeed, summary(x) -- *inside* printMer() dispatches wrongly
>> ## whereas top-level, there is no problem :
>>
>> ## maybe here, or then later
>> undebug(lme4:::printMer)
>>
>> ## This works fine top-level, but gives non-sense when in
Re: [Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values
I would like to reply to the following email from May in the thread [Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values On Wed, May 23, 2007 at 06:32:36PM +0100, Prof Brian Ripley wrote: > I think this is a bug in the MacOS X runtime. I've checked the C99 > standard, and can see no limits on the precision that you should be able > to specify to printf. > > Not that some protection against such OSes would come amiss. > > However, the C99 standard does make clear that [sf]printf is not required > (even as 'recommended practice') to be accurate to more than *_DIG places, > which as ?as.character has pointed out is 15 on the machines R runs on. Let me use http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf In Section 7.19.6, Recommended practice, paragraph 13, it is specified that rounding to DECIMAL_DIG should be done correctly. In Annex F.5 Binary-decimal conversion, it is explicitly stated that conversion from the widest supported IEC 60559 format to decimal with DECIMAL_DIG digits and back is the identity function. In footnote 305, it is specified that if double (53 bit precision) is the widest format supported, then DECIMAL_DIG >= 17. R uses double precision as default, so I think DECIMAL_DIG = 17 is a reasonable value. This is the minimum number of decimal digits, for which the conversion double -> string -> double is value preserving, if rounding is correct. DBL_DIG = 15 is another constant, which is the maximum number of digits, for which the conversion string -> double -> string may be done value preserving. > It really is the case that writing out a number to > 15 significant digits > and reading it back in again is not required to give exactly the same > IEC60559 (sic) number, and furthermore there are R platforms for which > this does not happen. What Mr Weinberg claimed is 'now impossible' never > was possible in general (and he seems to be berating the R developers for > not striving to do better than the C standard requires of OSes). In fact, > I believe this to be impossible unless you have access to extended > precsion arithmetic, as otherwise printf/scanf have to use the same > arithmetic as the computations. > > This is why R supports transfer of floating-point numbers via readBin and > friends, and uses a binary format itself for save() (by default). > > I should also say that any algorithm that depends on that level of details > in the numbers will depend on the compiler used and optimization level and > so on. Don't expect repeatability to that level even with binary data > unless you (are allowed to) never apply bugfixes to your system. Repeatability can hardly be achieved among different R installations, due to the reasons you explain. However, repeatability of a computation within the same installation may be achieved and may be sometimes useful. For example it may be useful for debugging, similarly as set.seed. Saving the data in binary is a possible approach for this, however, decimal numbers in a text may serve this purpose equally well, if they are precise enough. I would like to ask a question concerning the function scientific in src/main/format.c, which is called from formatReal in the same file. Function scientific, besides other things, determines, whether a smaller number of significant digits than R_print.digits is sufficient to get a decimal number with relative error at most max(10^-R_print.digits,2*DBL_EPSILON), where DBL_EPSILON=2^-52. For simplicity, let me consider only the case, when R_print.digits = DBL_DIG (which is 15). Then the bound for the relative error is 1e-15, since 1e-15 > 2*2^-52. There are two error bounds in consideration: (1) the absolute error of the rounded mantissa (significand) is at most 5e-15, (2) the relative error of the rounded number is at most 1e-15. It is natural to consider also (1), since R_print.digits = 15 and 5e-15 is the maximum absolute error of the mantissa for correct rounding to 15 significant digits. If the mantissa is in [1,5], then (2) => (1). Hence, for these mantissas, function scientific should suggest a smaller number of digits than 15 only if the result is as accurate as rounding to 15 digits. On the other hand, if the mantissa is in (5,10), then (2) does not imply (1). Hence, here we sometimes do not get the full precision 15 digit numbers. Is this behaviour the intention? This has, for example, the following consequence: if a 15-digit number is read into R using read.table and then written back to a text using write.table, we need not get the same result. For testing, I use the following platforms: FLAGS means CFLAGS,FFLAGS,CXXFLAGS,FCFLAGS on Linuxes, R version is 2.5.1 RC (2007-06-23 r42041), on Windows, R version is binary distribution of R-2.5.1 (RC). [1] AMD Athlon(tm) 64 Processor 3500+, SUSE 10.1, gcc 4.1.0, FLAGS = -g -O2 -march=pentium4 -mfpmath=sse [2] AMD Athlon(tm) 64 Processor 3500+, SUSE 10.1,
[Rd] possible bug in 'scan'
R-devel,
When I run the following code on the attached file,
tmp <- scan("C:/temp.csv",
what=list("character","numeric"),
sep=",")
Then tmp[[2]] is a character vector. My impression from the help file
is that it should be a numeric as specified by 'what'
sessionInfo()
R version 2.5.0 (2007-04-23)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
attached base packages:
[1] "stats" "graphics" "grDevices" "utils" "datasets"
"methods" "base"
other attached packages:
latticegdata
"0.15-5" "2.3.1"
My apologies if this is due to my misunderstanding.
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in 'scan'
The what argument looks at what the elements are, not the word they say.
Try this:
> tmp <- scan("C:/temp.csv",
> what=list("",0),
> sep=",")
Hope this helps,
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[EMAIL PROTECTED]
(801) 408-8111
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Tyner
> Sent: Tuesday, June 26, 2007 9:59 AM
> To: r-devel@r-project.org
> Subject: [Rd] possible bug in 'scan'
>
> R-devel,
>
> When I run the following code on the attached file,
>
> tmp <- scan("C:/temp.csv",
> what=list("character","numeric"),
> sep=",")
>
> Then tmp[[2]] is a character vector. My impression from the
> help file is that it should be a numeric as specified by 'what'
>
> > sessionInfo()
> R version 2.5.0 (2007-04-23)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" "base"
>
> other attached packages:
> latticegdata
> "0.15-5" "2.3.1"
>
> My apologies if this is due to my misunderstanding.
> Ben
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Behaviour of mle and environments or calling mle inside a function
Dear all,
I would appreciate some help understanding the following behaviour
when stats4::mle is called inside a function. mle seems to look for
its arguments in R_GlobalEnv and not the environment from which it is
called.
library(stats4)
lkhd <- function(alpha=1, beta=0.1, sigma=0.1)
- sum(dnorm(log(rec), log(alpha*ssb/(beta+ssb)), sqrt(sigma), TRUE))
object <- list(lkhd=lkhd, rec=1:10, ssb=1:10)
foo <- function(x)
{
rec <- x$rec
ssb <- x$ssb
mle(x$lkhd)
}
foo(object)
This fails with
Error in log(rec) : object "rec" not found
rec <- object$rec
ssb <- object$ssb
foo(object)
and this works.
Using R version 2.5.0 (2007-04-23), on Linux (Ubuntu) 2.6.17
Many thanks,
Iago Mosqueira
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in 'scan'
How embarrassing -- works like a charm.
On 6/26/07, Greg Snow <[EMAIL PROTECTED]> wrote:
> The what argument looks at what the elements are, not the word they say.
> Try this:
>
> > tmp <- scan("C:/temp.csv",
> > what=list("",0),
> > sep=",")
>
> Hope this helps,
>
> --
> Gregory (Greg) L. Snow Ph.D.
> Statistical Data Center
> Intermountain Healthcare
> [EMAIL PROTECTED]
> (801) 408-8111
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Tyner
> > Sent: Tuesday, June 26, 2007 9:59 AM
> > To: r-devel@r-project.org
> > Subject: [Rd] possible bug in 'scan'
> >
> > R-devel,
> >
> > When I run the following code on the attached file,
> >
> > tmp <- scan("C:/temp.csv",
> > what=list("character","numeric"),
> > sep=",")
> >
> > Then tmp[[2]] is a character vector. My impression from the
> > help file is that it should be a numeric as specified by 'what'
> >
> > > sessionInfo()
> > R version 2.5.0 (2007-04-23)
> > i386-pc-mingw32
> >
> > locale:
> > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> > States.1252;LC_MONETARY=English_United
> > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
> >
> > attached base packages:
> > [1] "stats" "graphics" "grDevices" "utils" "datasets"
> > "methods" "base"
> >
> > other attached packages:
> > latticegdata
> > "0.15-5" "2.3.1"
> >
> > My apologies if this is due to my misunderstanding.
> > Ben
> >
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in 'scan'
Hi Ben,
On Tue, Jun 26, 2007 at 11:58:35AM -0400, Benjamin Tyner wrote:
> R-devel,
>
> When I run the following code on the attached file,
>
> tmp <- scan("C:/temp.csv",
>what=list("character","numeric"),
>sep=",")
>
> Then tmp[[2]] is a character vector. My impression from the help file
> is that it should be a numeric as specified by 'what'
?scan says
[...]
what: the type of 'what' gives the type of data to be read.
[...]
so for example
what=list(character(), numeric())
would presumably have worked, but not your code, as both of your list elements
are of type character.
Dan
>
> >sessionInfo()
> R version 2.5.0 (2007-04-23)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" "base"
>
> other attached packages:
> latticegdata
> "0.15-5" "2.3.1"
>
> My apologies if this is due to my misunderstanding.
> Ben
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conflict between lme4 and RMySQL packages (PR#9753)
On 6/26/2007 9:07 AM, Martin Maechler wrote:
>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>> on Tue, 26 Jun 2007 10:51:03 +0100 (BST) writes:
>
> BDR> You have three summary() functions here:
> >> library(RMySQL)
> BDR> Loading required package: DBI
> >> library(lme4)
> BDR> Loading required package: Matrix
> BDR> Loading required package: lattice
> >> find("summary")
> BDR> [1] "package:Matrix" "package:DBI""package:base"
>
> BDR> and this is simply a namespace issue (note the environments):
>
> >> summary
> BDR> standardGeneric for "summary" defined from package "base"
>
> BDR> function (object, ...)
> BDR> standardGeneric("summary")
> BDR>
> BDR> Methods may be defined for arguments: object
>
> >> Matrix:::summary
> BDR> standardGeneric for "summary" defined from package "base"
>
> BDR> function (object, ...)
> BDR> standardGeneric("summary")
> BDR>
> BDR> Methods may be defined for arguments: object
>
> >> DBI:::summary
> BDR> standardGeneric for "summary" defined from package "base"
>
> BDR> function (object, ...)
> BDR> standardGeneric("summary")
> BDR>
> BDR> Methods may be defined for arguments: object
>
> BDR> so the visible summary() from package:Matrix is a copy of that in
> the DBI
> BDR> namespace, not that in the Matrix namespace.
>
> BDR> Since lme4 imports all of
> BDR> Matrix, it imports its take-over of summary. So the issue is not
> *S4*
> BDR> dispatch per se, but how the 'methods' package copes with two or
> more
> BDR> packages presenting the same generic.
>
> yes. And that's what I meant.
>
> The problem is --- not for the first time ---
> that in this case, from an S4 point of view, you would want to
> keep only one version of summary(), namely ``the generic'',
> and all packages / namespaces loaded and all other
> setMethod(summary, ...)
> should ``attach'' their methods to that generic.
> {and of also get an error or at least a loud warning when
> re-setting a method for a signature that already has a method
> set ``with the generic''. }
>
> I think we should provide useRs and package writers a way to
> achieve that --- which I think is pretty close to having the S4
> generic behave as if there were no namespaces.
I think a better conceptualization is that when S4 converts a function
or S3 generic into an S4 generic, it does the conversion in place.
The original summary() is an S3 generic living in base, and everyone
imports base, so it's not a good example.
A better example would be one of the S3 generics in the stats namespace,
e.g. start(). If they're importing the generic from stats and
converting it to an S4 generic, then their code should work with anyone
else who did the same. I think the easiest way to do this would be if
we actually replaced the original S3 generic right in the stats
namespace, but there might be other ways to implement it.
On the other hand, I can see someone defining a generic named start()
completely independently of the time series meaning in stats, and
exporting it from their package. In this case it should live in their
namespace, and only people who import that namespace will see it.
Duncan Murdoch
> The other approach, that some of the bioconductor folks
> advocate, is for each package to define it's own version of the
> generic explicitly, by setGeneric(..).
> But that also breaks functionality, namely that of all toplevel calls {of
> summary() in this case} apart from the ones of the last package loaded,
> where as the namespace-internal calls {e.g., the summary(.)
> inside printMer(.) in the given case} will continue to work.
>
> BDR> If you dig a bit deeper,
>
> >> ls(environment(summary)$".AllMTable")
> BDR> [1] "ANY" "DBIObject" "MySQLConnection"
> "MySQLDriver"
> BDR> [5] "MySQLResult" "lmer2" "mer"
> "sparseMatrix"
> BDR> [9] "summary.lmer2" "summary.mer"
> >> ls(environment(summary)$".AllMTable")
> BDR> [1] "ANY" "DBIObject" "MySQLConnection"
> "MySQLDriver"
> BDR> [5] "MySQLResult" "lmer2" "mer"
> "sparseMatrix"
> BDR> [9] "summary.lmer2" "summary.mer"
> >> ls(environment(Matrix:::summary)$".AllMTable")
> BDR> [1] "ANY" "sparseMatrix"
> >> ls(environment(DBI:::summary)$".AllMTable")
> BDR> [1] "ANY" "DBIObject" "MySQLConnection"
> "MySQLDriver"
> BDR> [5] "MySQLResult" "lmer2" "mer"
> "sparseMatrix"
> BDR> [9] "summary.lmer2" "summary.mer"
>
> BDR> shows the issue: the methods do not get stored on the version in the
> BDR> Matrix namespace, but rather on the version in package:Matrix which
> was
> BDR> copied from the existing export and not Matrix:::summary.
>
> BDR> Clearly there is going to be a na
[Rd] "Math" group generics for S4, and a bug
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
{on R-help}
[.]
[.]
>> Duncan Murdoch
DM> You might have better luck with
DM> log1p(tasa)
MM> {very good point, thank you, Duncan!}
DM> if the authors of the Matrix package have written a
DM> method for log1p(); if not, you'll probably have to do
DM> it yourself.
MM> They have not yet.
MM> Note however that this - and expm1() - would
MM> automagically work for sparse matrices if these two
MM> functions were part of the "Math" S4 group generic.
MM> I'd say that there's only historical reason for them
MM> *not* to be part of "Math", and I am likely going to
MM> propose to change this
I'm now going to propose ...
As I found, expm1() and log1p() already *HAVE BEEN*
in the S3 "Math" group generic
``automagically by implementation''.
Just the documentation for this fact has been missing.
Hence, I've added that doc (uncommitted) and I'm about to add
them to the S4 Math group as well. When doing so, I'd like to
add few more functions to make S3 and S4 "Math" a bit more compatible :
Consequently, I'm proposing to add the following functions to the S4 Math
group generic :
- log1p, expm1
- cummax, cummin {S3 has them; cumprod(), cumsum() are already}
- digamma, trigamma{S3 has them; gamma(), lgamma() are already}
When trying to do the above,
I'm pretty quickly successful for cummax & cummin,
most probably because they are primitive functions.
But I currently have problems for the other four,
and in exploring these problems,
I've found that
log10()
does not S4- dispatch on "Math" neither,
which I think is a pretty peculiar bug;
I think if that was fixed, then my code changes would also work
to make log1p(), expm1(), digamma() and trigamma() correctly
part of "S4 - Math Group".
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Math" group generics for S4, and a bug
Remember that you only get S4 dispatch on Math for S4 generics.
log10 is not an S4 generic until you make it one. From the help page
Note: currently those members which are not primitive functions
must have been converted to S4 generic functions (preferably
_before_ setting an S4 group generic method) as it only sets
methods for known S4 generics. This can be done by a call to
'setGeneric', for example 'setGeneric("round", group="Math2")'.
Had you done that (it is not mentioned)?
>From my notes about S4 issues sent to R core a while back:
1) Setting methods on a group generic only sets methods for existing
generics, and only primitives are ab initio generic.
?setGeneric and ?Arith differ as to how other members should be
converted into generics (one arg or two), and the example
(setGeneric("+")) seems pointless as that is already generic.
Whereas all of Ops (and its subgroups) and Complex are ab initio
generic, none of Summary is and log, log10, gamma, lgamma, round,
signif and trunc are not.
The discrepancies between the S3 and S4 group generics are hard to
explain: sign, digamma, trigamma and gammaCody are S3 group generic
but not S4 group generic (and sign is S4 generic). log10 is S4
group generic but log2 is not. This is probably all history, but
not at all obvious to end users.
so the issue has been raised before.
On Tue, 26 Jun 2007, Martin Maechler wrote:
>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
>
> {on R-help}
>
> [.]
> [.]
>
> >> Duncan Murdoch
>
> DM> You might have better luck with
>
> DM> log1p(tasa)
>
>MM> {very good point, thank you, Duncan!}
>
> DM> if the authors of the Matrix package have written a
> DM> method for log1p(); if not, you'll probably have to do
> DM> it yourself.
>
>MM> They have not yet.
>
>MM> Note however that this - and expm1() - would
>MM> automagically work for sparse matrices if these two
>MM> functions were part of the "Math" S4 group generic.
>
>MM> I'd say that there's only historical reason for them
>MM> *not* to be part of "Math", and I am likely going to
>MM> propose to change this
>
> I'm now going to propose ...
>
> As I found, expm1() and log1p() already *HAVE BEEN*
> in the S3 "Math" group generic
> ``automagically by implementation''.
> Just the documentation for this fact has been missing.
>
> Hence, I've added that doc (uncommitted) and I'm about to add
> them to the S4 Math group as well. When doing so, I'd like to
> add few more functions to make S3 and S4 "Math" a bit more compatible :
> Consequently, I'm proposing to add the following functions to the S4 Math
> group generic :
>
> - log1p, expm1
>
> - cummax, cummin {S3 has them; cumprod(), cumsum() are already}
>
> - digamma, trigamma{S3 has them; gamma(), lgamma() are already}
>
>
>
> When trying to do the above,
> I'm pretty quickly successful for cummax & cummin,
> most probably because they are primitive functions.
> But I currently have problems for the other four,
> and in exploring these problems,
> I've found that
>
> log10()
>
> does not S4- dispatch on "Math" neither,
> which I think is a pretty peculiar bug;
> I think if that was fixed, then my code changes would also work
> to make log1p(), expm1(), digamma() and trigamma() correctly
> part of "S4 - Math Group".
>
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
Re: [Rd] Behaviour of mle and environments or calling mle inside a function
On Tue, 26 Jun 2007, Iago Mosqueira wrote:
> Dear all,
>
> I would appreciate some help understanding the following behaviour
> when stats4::mle is called inside a function. mle seems to look for
> its arguments in R_GlobalEnv and not the environment from which it is
> called.
It is your function lkhd() that is doing the looking, and lexical scoping
means that it should be looking in .GlobalEnv (sic), since that is where
you defined it. Try a traceback:
> traceback()
10: log(rec)
9: dnorm(log(rec), log(alpha * ssb/(beta + ssb)), sqrt(sigma), TRUE)
8: sum(dnorm(log(rec), log(alpha * ssb/(beta + ssb)), sqrt(sigma),
TRUE))
7: minuslogl(alpha = 1, beta = 0.1, sigma = 0.1)
6: do.call("minuslogl", l)
5: fn(par, ...)
4: function (par)
fn(par, ...)(c(1, 0.1, 0.1))
3: optim(start, f, method = method, hessian = TRUE, ...)
2: mle(x$lkhd)
1: foo(object)
I am afraid I have no idea why you thought that your function would look
in the body of foo().
>
>
> library(stats4)
>
> lkhd <- function(alpha=1, beta=0.1, sigma=0.1)
> - sum(dnorm(log(rec), log(alpha*ssb/(beta+ssb)), sqrt(sigma), TRUE))
>
> object <- list(lkhd=lkhd, rec=1:10, ssb=1:10)
>
> foo <- function(x)
> {
> rec <- x$rec
> ssb <- x$ssb
>
> mle(x$lkhd)
> }
>
> foo(object)
>
>
> This fails with
>
> Error in log(rec) : object "rec" not found
>
>
> rec <- object$rec
> ssb <- object$ssb
>
> foo(object)
>
> and this works.
>
> Using R version 2.5.0 (2007-04-23), on Linux (Ubuntu) 2.6.17
>
> Many thanks,
>
>
> Iago Mosqueira
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
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
Re: [Rd] "Math" group generics for S4, and a bug
Martin Maechler wrote:
>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
>>
>
> {on R-help}
>
> [.]
> [.]
>
> >> Duncan Murdoch
>
> DM> You might have better luck with
>
> DM> log1p(tasa)
>
> MM> {very good point, thank you, Duncan!}
>
>DM> if the authors of the Matrix package have written a
>DM> method for log1p(); if not, you'll probably have to do
>DM> it yourself.
>
> MM> They have not yet.
>
> MM> Note however that this - and expm1() - would
> MM> automagically work for sparse matrices if these two
> MM> functions were part of the "Math" S4 group generic.
>
> MM> I'd say that there's only historical reason for them
> MM> *not* to be part of "Math", and I am likely going to
> MM> propose to change this
>
> I'm now going to propose ...
>
> As I found, expm1() and log1p() already *HAVE BEEN*
> in the S3 "Math" group generic
>``automagically by implementation''.
> Just the documentation for this fact has been missing.
>
> Hence, I've added that doc (uncommitted) and I'm about to add
> them to the S4 Math group as well. When doing so, I'd like to
> add few more functions to make S3 and S4 "Math" a bit more compatible :
> Consequently, I'm proposing to add the following functions to the S4 Math
> group generic :
>
> - log1p, expm1
>
> - cummax, cummin {S3 has them; cumprod(), cumsum() are already}
>
> - digamma, trigamma{S3 has them; gamma(), lgamma() are already}
>
>
>
> When trying to do the above,
> I'm pretty quickly successful for cummax & cummin,
> most probably because they are primitive functions.
> But I currently have problems for the other four,
> and in exploring these problems,
> I've found that
>
>log10()
>
> does not S4- dispatch on "Math" neither,
> which I think is a pretty peculiar bug;
>
Well, it depends what you mean by "bug"; I would call it a "design
infelicity" (a la Bill Venables), and some might call it a failure to Do
What I Mean. Assuming I understand what you meant (you didn't give an
example) I disagree with the letter but very much agree with the spirit.
In fact, log10 _is_ in the Math group. But the programmer is currently
responsible for creating a suitable generic function (that's the design
infelicity). If that is done correctly, dispatch seems to work fine:
> setGeneric("log10", group = "Math")
[1] "log10"
> setClass("onX", representation(x="numeric", stuff = "character"))
[1] "onX"
> setMethod("Math", "onX", function(x)callGeneric([EMAIL PROTECTED]))
[1] "Math"
> xx = new("onX", x=1:10, stuff = "test")
> log10(xx)
[1] 0.000 0.3010300 0.4771213 0.6020600 0.6989700 0.7781513 0.8450980
[8] 0.9030900 0.9542425 1.000
> showMethods("log10")
Function: log10 (package base)
x="ANY"
x="integer"
(inherited from: x="ANY")
x="onX"
(definition from function "Math")
So unless you mean something different by "does not S4- dispatch", this
is not technically a bug.Your bug presumably came when you either
did not call setGeneric() on log10() or else called it in the simple
setGeneric("log10") form.
But in principle I very much agree that this is not a satisfactory
situation. It should be implicit in the definition of log10() that when
it is made a generic, that generic has group "Math". The reason it must
now be done by the programmer is that log10() is not a primitive, and so
not covered by the automatic definition of a generic that, e.g., applies
to sin().
I have a proposal to fix this, by generalizing the mechanism used for
primitives in base, so that it would allow any function in any package
to have an implicit generic form. When a method is specified for the
function, the implicit generic becomes the actual function. Sometime
after 2.5.1 comes out, this should with luck find its way to r-devel so
we can see if it helps.
> I think if that was fixed, then my code changes would also work
> to make log1p(), expm1(), digamma() and trigamma() correctly
> part of "S4 - Math Group".
>
>
> Martin
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] slight anomaly in formals<- ? (PR#9758)
Hi, The R input/output after the following paragraph is from a session with version.string R version 2.4.0 Patched (2006-11-23 r39958). The last element, x$c, of x has no value and after the assignment of x to the formals of f, x$c does not become a formal argument of f. The second assignment does the job. It seems that x$c actually becomes the body of f after the first assignment. There is no problem if the body of f is not NULL (this probably explains why the second time the assignment to the formals of f works as expected. > x <- alist(a=,b=,c=) > x$b <- 4 > f <- function(x) NULL > f function(x) NULL > formals(f) <- x > f function (a, b = 4) > formals(f) <- x > f function (a, b = 4, c) > body(f) -- Dr Georgi Boshnakov tel: (+44) (0)161 306 3684 School of Mathematics fax: (+44) (0)161 306 3669 The University of Manchester email: [EMAIL PROTECTED] Sackville Street Manchester M60 1QD UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in getVarCov.gls method (PR#9752)
This is a multi-part message in MIME format. --000206090008050103050209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Two attachments: 1. getVarCovBugReport.R - Rcode with an example illustrating the problem and how to fix it 2. getVarCovBugReportSession.txt contains code and R session results. Thank you Andrzej Galecki Prof Brian Ripley wrote: > On Mon, 25 Jun 2007, [EMAIL PROTECTED] wrote: > >> I am using R2.5 under Windows. > > > I presume you mean 2.5.0 (there is no R2.5: see the posting guide). > But which version of nlme, which is the relevant fact here? The R > posting guide suggests showing the output of sessionInfo() to > establish the environment used. > >> Looks like the following statement >> >> vars <- (obj$sigma^2)*vw >> >> in getVarCov.gls method (nlme package) needs to be replaced with: >> >> vars <- (obj$sigma*vw)^2 > > > We need some evidence! Please supply a reproducible example and give > your reasoning. For example, the FAQ says > > The most important principle in reporting a bug is to report _facts_, > not hypotheses or categorizations. It is always easier to report the > facts, but people seem to prefer to strain to posit explanations and > report them instead. If the explanations are based on guesses about > how > R is implemented, they will be useless; others will have to try to > figure > out what the facts must have been to lead to such speculations. > Sometimes this is impossible. But in any case, it is unnecessary work > for the ones trying to fix the problem. > > It is very useful to try and find simple examples that produce > apparently the same bug, and somewhat useful to find simple examples > that might be expected to produce the bug but actually do not. If you > want to debug the problem and find exactly what caused it, that is > wonderful. You should still report the facts as well as any > explanations or solutions. Please include an example that reproduces > the > problem, preferably the simplest one you have found. > > It should be easily possible to cross-check an example with one of the > many other ways available to do GLS fits in R. > > [...] > > --000206090008050103050209 Content-Type: text/plain; name="getVarCovBugReport.R" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getVarCovBugReport.R" ls() require(nlme) sessionInfo() str(Orthodont) formula(Orthodont) # variances of variable at four different ages attach(Orthodont) d8 <- distance[age==8] d10 <- distance[age==10] d12 <- distance[age==12] d14 <- distance[age==14] vars0<- diag(var(cbind(d8,d10,d12,d14))) vars0 detach(Orthodont) # Model with four means and unstructured covariance matrix # to _illustrate_ that getVarCov does not work properly # It is expected that marginal variances from the following model # will be close to . gls.fit <- gls(distance ~ -1 + factor(age), correlation= corSymm(form=~1|Subject), weights=varIdent(form=~1|age), data= Orthodont) # V matrix extracted using getVarCov Vmtx <- getVarCov(gls.fit,individual="M01") vars.incorrect <- diag(Vmtx) # incorrect values on the diagonal vars.incorrect # Manualy calculated variances (correct values) based on gls.fit # Code used here is similar to getVarCov, with one statement corrected obj <- gls.fit ind <- obj$groups == "M01" vw<- 1/varWeights(obj$modelStruct$varStruct)[ind] # from getVarCov vars <- (obj$sigma *vw)^2 # Corrected statement # Please note that vars.corrected is very close to # vars. (difference most likely due to rounding error) vars.corrected <- vars.incorrect * vw vars.corrected --000206090008050103050209 Content-Type: text/plain; name="getVarCovBugReportSession.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="getVarCovBugReportSession.txt" > ls() character(0) > require(nlme) Loading required package: nlme [1] TRUE > sessionInfo() R version 2.5.0 (2007-04-23) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] "stats" "graphics" "grDevices" "utils" "datasets" "methods" [7] "base" other attached packages: nlme "3.1-80" > #str(Orthodont) > #formula(Orthodont) > > # variances of variable at four different ages > attach(Orthodont) > d8 <- distance[age==8] > d10 <- distance[age==10] > d12 <- distance[age==12] > d14 <- distance[age==14] > vars0<- diag(var(cbind(d8,d10,d12,d14))) > vars0 d8 d10 d12 d14 5.925926 4.653846 7.938746 7.654558 > detach(Orthodont) > > > # Model with four means and unstructured covariance matrix > # to _illustrate_ that getVarCov does not work properly > # It is expected that marginal variances from the following model > # will be
Re: [Rd] "Math" group generics for S4, and a bug
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Tue, 26 Jun 2007 18:38:27 +0100 (BST) writes:
BDR> Remember that you only get S4 dispatch on Math for S4
BDR> generics. log10 is not an S4 generic until you make it
BDR> one. From the help page
BDR> Note: currently those members which are not
BDR> primitive functions must have been converted to S4
BDR> generic functions (preferably _before_ setting an S4
BDR> group generic method) as it only sets methods for known
BDR> S4 generics. This can be done by a call to
BDR> 'setGeneric', for example 'setGeneric("round",
BDR> group="Math2")'.
BDR> Had you done that (it is not mentioned)?
no. embarrassing, since I "once" new about it
(had to do that in the Matrix package)...
>> From my notes about S4 issues sent to R core a while
>> back:
BDR> 1) Setting methods on a group generic only sets methods
BDR> for existing generics, and only primitives are ab
BDR> initio generic.
BDR> ?setGeneric and ?Arith differ as to how other
BDR> members should be converted into generics (one arg or
BDR> two), and the example (setGeneric("+")) seems pointless
BDR> as that is already generic.
BDR> Whereas all of Ops (and its subgroups) and Complex
BDR> are ab initio generic, none of Summary is and log,
BDR> log10, gamma, lgamma, round, signif and trunc are not.
BDR> The discrepancies between the S3 and S4 group
BDR> generics are hard to explain: sign, digamma, trigamma
BDR> and gammaCody are S3 group generic but not S4 group
BDR> generic (and sign is S4 generic). log10 is S4 group
BDR> generic but log2 is not. This is probably all history,
BDR> but not at all obvious to end users.
BDR> so the issue has been raised before.
Indeed. Thanks a lot, Brian!
Martin
BDR> On Tue, 26 Jun 2007, Martin Maechler wrote:
>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
>>
>> {on R-help}
>>
>> [.] [.]
>>
>> >> Duncan Murdoch
>>
DM> You might have better luck with
>>
DM> log1p(tasa)
>>
MM> {very good point, thank you, Duncan!}
>>
DM> if the authors of the Matrix package have written a
DM> method for log1p(); if not, you'll probably have to do
DM> it yourself.
>>
MM> They have not yet.
>>
MM> Note however that this - and expm1() - would
MM> automagically work for sparse matrices if these two
MM> functions were part of the "Math" S4 group generic.
>>
MM> I'd say that there's only historical reason for them
MM> *not* to be part of "Math", and I am likely going to
MM> propose to change this
>>
>> I'm now going to propose ...
>>
>> As I found, expm1() and log1p() already *HAVE BEEN* in
>> the S3 "Math" group generic ``automagically by
>> implementation''. Just the documentation for this fact
>> has been missing.
>>
>> Hence, I've added that doc (uncommitted) and I'm about to
>> add them to the S4 Math group as well. When doing so,
>> I'd like to add few more functions to make S3 and S4
>> "Math" a bit more compatible : Consequently, I'm
>> proposing to add the following functions to the S4 Math
>> group generic :
>>
>> - log1p, expm1
>>
>> - cummax, cummin {S3 has them; cumprod(), cumsum() are
>> already}
>>
>> - digamma, trigamma {S3 has them; gamma(), lgamma() are
>> already}
>>
>>
>>
>> When trying to do the above, I'm pretty quickly
>> successful for cummax & cummin, most probably because
>> they are primitive functions. But I currently have
>> problems for the other four, and in exploring these
>> problems, I've found that
>>
>> log10()
>>
>> does not S4- dispatch on "Math" neither, which I think is
>> a pretty peculiar bug; I think if that was fixed, then my
>> code changes would also work to make log1p(), expm1(),
>> digamma() and trigamma() correctly part of "S4 - Math
>> Group".
>>
>>
>> Martin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
--
Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics,
BDR> http://www.stats.ox.ac.uk/~ripley/ University of
BDR> Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road,
BDR> +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865
BDR> 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] "Math" group generics for S4, and a bug
> "JMC" == John Chambers <[EMAIL PROTECTED]>
> on Tue, 26 Jun 2007 14:47:25 -0400 writes:
JMC> Martin Maechler wrote:
>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
>>>
>>
> {on R-help}
>>
>> [.] [.]
>>
>> >> Duncan Murdoch
>>
DM> You might have better luck with
>>
DM> log1p(tasa)
>>
MM> {very good point, thank you, Duncan!}
>>
DM> if the authors of the Matrix package have written a
DM> method for log1p(); if not, you'll probably have to do
DM> it yourself.
>>
MM> They have not yet.
>>
MM> Note however that this - and expm1() - would
MM> automagically work for sparse matrices if these two
MM> functions were part of the "Math" S4 group generic.
>>
MM> I'd say that there's only historical reason for them
MM> *not* to be part of "Math", and I am likely going to
MM> propose to change this
>>
>> I'm now going to propose ...
>>
>> As I found, expm1() and log1p() already *HAVE BEEN* in
>> the S3 "Math" group generic ``automagically by
>> implementation''. Just the documentation for this fact
>> has been missing.
>>
>> Hence, I've added that doc (uncommitted) and I'm about to
>> add them to the S4 Math group as well. When doing so,
>> I'd like to add few more functions to make S3 and S4
>> "Math" a bit more compatible : Consequently, I'm
>> proposing to add the following functions to the S4 Math
>> group generic :
>>
>> - log1p, expm1
>>
>> - cummax, cummin {S3 has them; cumprod(), cumsum() are
>> already}
>>
>> - digamma, trigamma {S3 has them; gamma(), lgamma() are
>> already}
>>
>>
>>
>> When trying to do the above, I'm pretty quickly
>> successful for cummax & cummin, most probably because
>> they are primitive functions. But I currently have
>> problems for the other four, and in exploring these
>> problems, I've found that
>>
>> log10()
>>
>> does not S4- dispatch on "Math" neither, which I think is
>> a pretty peculiar bug;
JMC> Well, it depends what you mean by "bug"; I would call
JMC> it a "design infelicity" (a la Bill Venables), and some
JMC> might call it a failure to Do What I Mean. Assuming I
JMC> understand what you meant (you didn't give an example)
JMC> I disagree with the letter but very much agree with the
JMC> spirit.
JMC> In fact, log10 _is_ in the Math group. But the
JMC> programmer is currently responsible for creating a
JMC> suitable generic function (that's the design
JMC> infelicity). If that is done correctly, dispatch seems
JMC> to work fine:
>> setGeneric("log10", group = "Math")
JMC> [1] "log10"
yes, indeed. Embarrassingly, actually I did know about this,
and indeed, it's not a bug.
>> setClass("onX", representation(x="numeric", stuff =
>> "character"))
JMC> [1] "onX"
>> setMethod("Math", "onX", function(x)callGeneric([EMAIL PROTECTED]))
JMC> [1] "Math"
>> xx = new("onX", x=1:10, stuff = "test") log10(xx)
JMC> [1] 0.000 0.3010300 0.4771213 0.6020600 0.6989700
JMC> 0.7781513 0.8450980 [8] 0.9030900 0.9542425 1.000
>> showMethods("log10")
JMC> Function: log10 (package base) x="ANY" x="integer"
JMC> (inherited from: x="ANY") x="onX" (definition from
JMC> function "Math")
JMC> So unless you mean something different by "does not S4-
JMC> dispatch", this is not technically a bug. Your bug
JMC> presumably came when you either did not call
JMC> setGeneric() on log10() or else called it in the simple
JMC> setGeneric("log10") form.
you are right.
JMC> But in principle I very much agree that this is not a
JMC> satisfactory situation. It should be implicit in the
JMC> definition of log10() that when it is made a generic,
JMC> that generic has group "Math". The reason it must now
JMC> be done by the programmer is that log10() is not a
JMC> primitive, and so not covered by the automatic
JMC> definition of a generic that, e.g., applies to sin().
JMC> I have a proposal to fix this, by generalizing the
JMC> mechanism used for primitives in base, so that it would
JMC> allow any function in any package to have an implicit
JMC> generic form. When a method is specified for the
JMC> function, the implicit generic becomes the actual
JMC> function.
That sounds like a very good idea, allowing the function writer
to specify (if and) how the function should behave as generic.
JMC> Sometime after 2.5.1 comes out, this should
JMC> with luck find its way to r-devel so we can see if it
JMC> helps.
So, I'm hoping for good luck.. ;-) :-)
Thanks a lot, John!
Martin
>> I think if that was fixed, then my co
[Rd] trivial typo in ?ks.test (PR#9759)
In ?ks.test "if the sample size if less than 100 in" should be "if the sample size is less than 100 in" Ben Bolker --please do not edit the information below-- Version: platform = i486-pc-linux-gnu arch = i486 os = linux-gnu system = i486, linux-gnu status = major = 2 minor = 5.0 year = 2007 month = 04 day = 23 svn rev = 41293 language = R version.string = R version 2.5.0 (2007-04-23) Locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C Search Path: .GlobalEnv, package:weaver, package:codetools, package:tools, package:digest, package:ellipse, package:cpcbp, package:lattice, package:MASS, package:fortunes, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in 'scan'
On Tue, 26 Jun 2007, Benjamin Tyner wrote:
> R-devel,
>
> When I run the following code on the attached file,
>
> tmp <- scan("C:/temp.csv",
> what=list("character","numeric"),
> sep=",")
>
> Then tmp[[2]] is a character vector. My impression from the help file
> is that it should be a numeric as specified by 'what'
No, as "numeric" is a character vector.
what: the type of 'what' gives the type of data to be read. The
supported types are 'logical', 'integer', 'numeric',
'complex', 'character', 'raw' and 'list'. If 'what' is a
list, it is assumed that the lines of the data file are
records each containing 'length(what)' items ("fields") and
the list components should have elements which are one of the
first six types listed or 'NULL', see section 'Details'
below.
so you need what = list("", 0), say.
There are even examples in 'An Introduction to R'.
>
>> sessionInfo()
> R version 2.5.0 (2007-04-23)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
> States.1252;LC_MONETARY=English_United
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] "stats" "graphics" "grDevices" "utils" "datasets"
> "methods" "base"
>
> other attached packages:
> latticegdata
> "0.15-5" "2.3.1"
>
> My apologies if this is due to my misunderstanding.
> Ben
>
--
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
Re: [Rd] slight anomaly in formals<- ? (PR#9758)
On Tue, 26 Jun 2007, [EMAIL PROTECTED] wrote:
> Hi,
>
> The R input/output after the following paragraph is from a session with
> version.string R version 2.4.0 Patched (2006-11-23 r39958).
Which is not recent, but this is unchanged since.
The problem is the definition:
> `formals<-`
function (fun, envir = environment(fun), value)
as.function(c(value, body(fun)), envir)
and
> c(x, NULL)
$a
$b
[1] 4
$c
I've fixed this for 2.6.0 (it is not critical enough for 2.5.1 due
tomorrow). If you need the defn for your version, it is
`formals<-` <- function (fun, envir = environment(fun), value)
{
bd <- body(fun)
as.function(c(value, if(is.null(bd)) list(bd) else bd), envir)
}
>
> The last element, x$c, of x has no value and after the assignment of x
> to the formals of f, x$c does not become a formal argument of f. The
> second assignment does the job. It seems that x$c actually becomes the
> body of f after the first assignment. There is no problem if the body of
> f is not NULL (this probably explains why the second time the assignment
> to the formals of f works as expected.
>
>> x <- alist(a=,b=,c=)
>> x$b <- 4
Or just x <- alist(a=,b=4,c=)
>> f <- function(x) NULL
>> f
> function(x) NULL
>> formals(f) <- x
>> f
> function (a, b = 4)
>
>> formals(f) <- x
>> f
> function (a, b = 4, c)
>
>> body(f)
>
>
>
--
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
Re: [Rd] Bug in getVarCov.gls method (PR#9752)
Thank you, will be fixed in the next release of nlme (not yet scheduled, as everythign is code frozen for the release of R 2.5.1 tomorrow). On Tue, 26 Jun 2007, Andrzej Galecki wrote: > > Two attachments: > > 1. getVarCovBugReport.R - Rcode with an example illustrating the problem and > how to fix it > 2. getVarCovBugReportSession.txt contains code and R session results. > > Thank you > > Andrzej Galecki > > > > Prof Brian Ripley wrote: > >> On Mon, 25 Jun 2007, [EMAIL PROTECTED] wrote: >> >>> I am using R2.5 under Windows. >> >> >> I presume you mean 2.5.0 (there is no R2.5: see the posting guide). But >> which version of nlme, which is the relevant fact here? The R posting >> guide suggests showing the output of sessionInfo() to establish the >> environment used. >> >>> Looks like the following statement >>> >>> vars <- (obj$sigma^2)*vw >>> >>> in getVarCov.gls method (nlme package) needs to be replaced with: >>> >>> vars <- (obj$sigma*vw)^2 >> >> >> We need some evidence! Please supply a reproducible example and give your >> reasoning. For example, the FAQ says >> >> The most important principle in reporting a bug is to report _facts_, >> not hypotheses or categorizations. It is always easier to report the >> facts, but people seem to prefer to strain to posit explanations and >> report them instead. If the explanations are based on guesses about how >> R is implemented, they will be useless; others will have to try to figure >> out what the facts must have been to lead to such speculations. >> Sometimes this is impossible. But in any case, it is unnecessary work >> for the ones trying to fix the problem. >> >> It is very useful to try and find simple examples that produce >> apparently the same bug, and somewhat useful to find simple examples >> that might be expected to produce the bug but actually do not. If you >> want to debug the problem and find exactly what caused it, that is >> wonderful. You should still report the facts as well as any >> explanations or solutions. Please include an example that reproduces the >> problem, preferably the simplest one you have found. >> >> It should be easily possible to cross-check an example with one of the many >> other ways available to do GLS fits in R. >> >> [...] >> >> > > -- 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
