Re: [Rd] R Dev Day @ Imperial, London, Fri Apr 26
Reminder that the registration deadline for this event is this Sunday. On Wed, Mar 13, 2024, at 9:16 AM, Heather Turner wrote: > Dear All, > > R Dev Day @ Imperial will take place on Friday 26 April at Imperial > College London: > https://pretix.eu/r-contributors/r-dev-day-imperial-2024/ > > This event is aimed at current or aspiring R contributors based in the > UK. Unlike other contributor events, we may not have representation > from the R Core Team, however it is a chance for interested folk to get > together to learn more, or to work collaboratively on potential > contributions to base R. > > This R Dev Day is a satellite to London satRday, Saturday 27 April: > https://satrday-london-2024.jumpingrivers.com/. Thanks to Jumping > Rivers and Imperial Central RSE Team, coffee and lunch breaks are > catered for participants. > > There is no selective application for this event. Registration is free > and open until Sunday 14 April or until places are filled. > > Best wishes, > > Heather > [[alternative HTML version deleted]] > > __ > 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] R Dev Day @ PLUS, Salzburg, Austria on Fri 12 July
Reminder that the deadline for applications to this event is end of day Sunday March 24 (anywhere on earth). On Wed, Feb 28, 2024, at 2:43 PM, Heather Turner wrote: > Dear All, > > Information is now up for the R Dev Day that will take place as a > satellite event to useR! 2024 on Friday 12 July: > https://contributor.r-project.org/r-dev-day-plus-2024 > > This will be an opportunity for contributors to work alongside members > of the R Core Team on contributions to base R. > > Places will be allocated via an application process, balancing across > experience levels and giving opportunity to members of historically > underrepresented groups. > > If you would like to attend, please apply by *Sunday March 24*. > > Best wishes, > > Heather > > __ > 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
[Rd] R Dev Day @ Imperial, London, Fri Apr 26
Dear All, R Dev Day @ Imperial will take place on Friday 26 April at Imperial College London: https://pretix.eu/r-contributors/r-dev-day-imperial-2024/ This event is aimed at current or aspiring R contributors based in the UK. Unlike other contributor events, we may not have representation from the R Core Team, however it is a chance for interested folk to get together to learn more, or to work collaboratively on potential contributions to base R. This R Dev Day is a satellite to London satRday, Saturday 27 April: https://satrday-london-2024.jumpingrivers.com/. Thanks to Jumping Rivers and Imperial Central RSE Team, coffee and lunch breaks are catered for participants. There is no selective application for this event. Registration is free and open until Sunday 14 April or until places are filled. Best wishes, Heather [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Dev Day @ PLUS, Salzburg, Austria on Fri 12 July
Dear All, Information is now up for the R Dev Day that will take place as a satellite event to useR! 2024 on Friday 12 July: https://contributor.r-project.org/r-dev-day-plus-2024 This will be an opportunity for contributors to work alongside members of the R Core Team on contributions to base R. Places will be allocated via an application process, balancing across experience levels and giving opportunity to members of historically underrepresented groups. If you would like to attend, please apply by *Sunday March 24*. Best wishes, Heather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Project Sprint 2023: deadline 10 March (midnight UTC)
Dear All, This is a reminder that the deadline to apply to participate in the R Project Sprint 2023 is tomorrow, Friday 10 March. The form will close at midnight UTC. Details: https://contributor.r-project.org/r-project-sprint-2023/. Best wishes, Heather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Project Sprint 2023, Aug 30 - Sep 1, Coventry, UK
Dear All, We are happy to announce R Project Sprint 2023 Dates: Wednesday August 30 to Friday September 1. Venue: University of Warwick, Coventry, UK Novice and experienced contributors are encouraged to apply for a place at the residential event, with funding available for travel: **deadline Friday 10 March**. For further details, please visit the sprint website: https://contributor.r-project.org/r-project-sprint-2023/. We also welcome additional sponsors to support participant travel, accommodation and/or social events. Please contact r-project-sprint-2023@gaggle.email if you would like to explore this option! Best wishes, Heather Turner on behalf of the local organizing team [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R Contribution Working Group
Dear All, The R Contribution Working Group was set up last year with the purpose of encouraging new contributors to R core, especially from currently under-represented groups. More detail here: https://forwards.github.io/rcontribution/working-group. The group has been meeting approximately once a month with representatives from R Core, Forwards, R-Ladies, MiR and the general R contributor community (from aspiring to experienced contributors). We currently alternate between a Americas-friendly time and a Europe/Middle East/Africa-friendly time. Anyone supporting the aims of the group is welcome to attend when they can. The next meeting will be will be Tuesday, October 26, 2021, 20:00-21:00 UTC. The agenda is here: https://hackmd.io/GzIGWM4ZTdmM3B3q6C24RA?edit - feel free to add items for us to discuss (time allowing!). Join Zoom Meeting https://us02web.zoom.us/j/88955759010?pwd=VW9IR2p1eVRicHc5czJSZ1VkUDB6QT09 (ID: 88955759010, passcode: KOI9wWzh). Best wishes, Heather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Formula evaluation, environments and attached packages
Hi Milan,
I expect I may be able to do something about the way the terms are
evaluated, to ensure the evaluation is done in the gnm namespace (while
still ensuring the variables can be found!).
In the meantime, I think the following will work:
Mult <- gnm::Mult
f <- Freq ~ Eye + Hair + Mult(Eye, Hair)
gnm::gnm(f, family=poisson, data=dat)
Hope that helps,
Heather
On Wed, Apr 29, 2015, at 05:57 PM, Milan Bouchet-Valat wrote:
> Hi!
>
> Some time ago, I replaced calls to library() with calls to
> requireNamespace() in my package logmult, in order to follow the new
> CRAN policies. But I just noticed it broke jackknife/bootstrap using
> several workers via package parallel.
>
> The reason is that I'm running model replicates on the workers, and the
> formula includes non-standard terms like Mult() which are provided by
> gnm. If gnm is not attached to the global namespace, these functions are
> not found.
>
> What would be the best solution to fix this? I tried changing the
> environment of the formula to be gnm's namespace, but so far I failed.
>
> Here's a reproducer using only gnm:
>
> > dat <- structure(c(326, 688, 343, 98, 38, 116, 84, 48, 241, 584, 909,
> + 403, 110, 188, 412, 681, 3, 4, 26, 85), .Dim = 4:5, .Dimnames =
> structure(list(
> + Eye = c("Blue", "Light", "Medium", "Dark"), Hair = c("Fair",
> + "Red", "Medium", "Dark", "Black")), .Names = c("Eye", "Hair"
> + )), class="table")
> >
> > f <- Freq ~ Eye + Hair + Mult(Eye, Hair)
> > gnm::gnm(f, family=poisson, data=dat)
> Error in which(sapply(variables, function(x) { :
> error in evaluating the argument 'x' in selecting a method for function
> 'which':
> Error in get(as.character(FUN), mode = "function", envir = envir) :
> object 'Mult' of mode 'function' was not found
>
> # Failed attempt by setting the environment
> > environment(f) <- loadNamespace("gnm")
> > environment(f)
>
> > gnm::gnm(f, family=poisson, data=dat)
> Error in which(sapply(variables, function(x) { :
> error in evaluating the argument 'x' in selecting a method for function
> 'which':
> Error in get(as.character(FUN), mode = "function", envir = envir) :
> object 'Mult' of mode 'function' was not found
>
>
> Thanks for your help
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Matrix package: Matrix products (%*%, crossprod, tcrossprod) involving "nsparseMatrix" aka sparse pattern matrices
We don't use the pattern matrices, nevertheless the proposed changes
sound good to me. I particularly like the suggestion to treat the
matrices as numeric by default, but provide simple ways to use boolean
arithmetic instead - this means that developers have access to both
forms of arithmetic and it will be more obvious from the code which
arithmetic is being used.
Best wishes,
Heather
On Thu, Mar 19, 2015, at 10:02 PM, Martin Maechler wrote:
> This is a Request For Comment, also BCCed to 390 package maintainers
> of reverse dependencies of the Matrix package.
>
> Most users and package authors working with our 'Matrix' package will
> be using it for numerical computations, and so will be using
> "dMatrix" (d : double precision) matrix objects M, and indirectly,
> e.g., for
> M >= c will also use "lMatrix" (l: logical i.e. TRUE/FALSE/NA).
> All the following is **not** affecting those numerical / logical
> computations.
>
> A few others will know that we also have "pattern" matrices (purely
> binary: TRUE/FALSE, no NA) notably sparse ones, those "ngCMatrix" etc,
> all starting with "n" (from ``patter[n]``) which do play a prominent
> role in the internal sparse matrix algorithms, notably of the
> (underlying C code) CHOLMOD library in the so-called "symbolic"
> cholesky decomposition and other such operations. Another reason you
> may use them because they are equivalent to incidence matrices of
> unweighted (directed or undirected) graphs.
>
> Now, as the subject says, I'm bringing up the topic of what should
> happen when these matrices appear in matrix multiplications.
> Somewhat by design, but also partly by coincidence, the *sparse*
> pattern matrices multiplication in the Matrix package mostly builds on
> the CHOLMOD library `cholmod_ssmult()` function which implements
> "Boolean arithmetic" for them, instead of regular arithmetic:
> "+" is logical "or"
> "*" is logical "and".
> Once we map TRUE <-> 1 and FALSE <-> 0, the only difference between
> boolean and regular arithmetic is that "1+1 = 1" in the (mapped)
> boolean arithmetic, because "TRUE | TRUE" is TRUE in original logic.
>
> The drawback of using the boolean arithmetic here is the "clash" with
> the usual numeric arithmetic, and arithmetic in R where logical is
> coerced to integer (and that to "double") when certain numerical
> functions/operations are used.
>
> A more severe problem --- which I had not been aware of until
> relatively recently -- is the fact that the CHOLMD function
> cholmod_ssdmult(A, B)
> treats *both* A and B as "pattern" as soon as one of them is a
> (sparse) pattern matrix.
> And this is - I say - in clear contrast to what R users would expect:
> If you multiply a numeric with a "kind of logical" matrix (a pattern
> one), you will expect that the
> TRUE/FALSE matrix will be treated as a 1/0 matrix because it is
> combined with a numeric matrix.
> So we could say that in this case, the Matrix package behavior is
> clearly bugous but still it has been the behavior for the last 10
> years or so.
>
> RFC 1: "Change 1":
> I currently propose to change this behavior for the upcoming release
> of Matrix (version 1.2-0), though I have no idea if dependent
> packages would partly fail their checks or otherwise have changed
> behavior subsequently.
> The change seems sensible, since I think if your package relied on
> this behavior, it was inadvertent and accidental.
> Still you may differ in your opinion about this change nr.1
>
> RFC 2: "Change 2":
> This change would be more radical, and something I would not plan for
> the upcoming release of Matrix, but possibly for an update say one or
> two months later or so: It concerns the matrix products when *both*
> matrices are pattern. A situation where the boolean arithmetic may
> really make sense and where indeed packages may have depended on the
> current behavior ("T + T |--> T"). ... although that is currently
> only used for *sparse* pattern matrices, not for dense ones.
>
> Further, it may still seem surprising that matrix multiplication does
> not behave numerically for a pair of such matrices, and by the
> principle of "least surprise" we should provide the boolean arithmetic
> matrix products in another way than by the standard %*%,
> crossprod() and tcrossprod() functions.
> So one possibility could be to change the standard functions to behave
> numerically,
> and e.g., use %&% (replace the numeric "*" by a logical "&") and
> crossprod(A,B, boolean=TRUE), tcrossprod(A,B, boolean=TRUE)
> for the three boolean arithmetic version of matrix multiplications.
>
> What do you think about this? I'm particularly interested to hear
> from authors and users of packages such as 'arules' which IIRC
> explicitly work with sparse pattern matrices.
>
> Thank you for your thoughts and creative ideas,
> Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.eth
Re: [Rd] installing spam package is failing (spam_0.29-1)
I expect what's happened is that you have installed R at some point, then later updated Ubuntu, which caused the R repository you had stored to be disabled. Try running sudo gedit /etc/apt/sources.list If my guess is right, you will probably have something like # deb http:///bin/linux/ubuntu natty/ #disabled on upgrade to oneiric Note that the whole line has been commented out! To fix, simply uncomment and replace the old ubuntu version (e.g. natty) with your new one (e.g. oneiric). Then, assuming you already have Michael Rutter's key on your system, just run sudo apt-get update && sudo apt-get upgrade and you should be able to upgrade to 2.15.1 Best wishes, Heather On 17/07/12 07:34, chuckles the clone wrote: > Thank you for your snark but it was not necessary. > > In fact I *have* read the "documentation". That's how I got R installed > in the first place. But I followed, again, the instructions on that page > and, again, I am still at version 2.13.1. (SEE BELOW) > > Is there some other means of causing R to update to the latest version? > There is nothing at all in the "documentation" that suggests I should be > having this issue or what to do about it. > > Thanks! > > > # apt-get install r-base > Reading package lists... Done > Building dependency tree > Reading state information... Done > r-base is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded. > > # apt-get install r-base-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > r-base-dev is already the newest version. > r-base-dev set to manually installed. > 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded. > root:~# > > root:~# R --version > R version 2.13.1 (2011-07-08) > Copyright (C) 2011 The R Foundation for Statistical Computing > ISBN 3-900051-07-0 > Platform: x86_64-pc-linux-gnu (64-bit) > > > -- > View this message in context: > http://r.789695.n4.nabble.com/installing-spam-package-is-failing-spam-0-29-1-tp4636628p4636727.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > 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] model.matrix troubles with AlgDesign
Ah ok, I get the problem now.
I think you just need to modify model.matrix.formula as follows
model.matrix.formula <- function (frml, data = sys.frame(sys.parent()),
...)
{
if (!missing(data)) {
if (!inherits(data, "data.frame"))
stop("data must be a data.frame")
if (!inherits(frml, "formula"))
stop("frml must be a formuls")
env <- environment(frml)
frml <- expand.formula(frml, colnames(data))
environment(frml) <- env
}
model.matrix.default(frml, data, ...)
}
or the equivalent could be done inside expand.formula, which might be
neater actually.
Hope that fixes it,
Heather
Ulrike Groemping wrote:
> Hi Heather,
>
> thanks, I would be able to add the variable y <- 1:nrow(aus), I would even
> be able to omit these.
> What concerns me is the fact that the presence of function
> model.matrix.formula in package AlgDesign will stop model.matrix from
> working as expected in further situations that I have not spotted yet.
>
> For the future development of package DoE.wrapper, I would like to include
> AlgDesign in the Depends field, and that would mean that the package would
> then stop user functions with perfectly valid code from working correctly.
> So I would like to find a way to modify model.matrix.formula or
> expand.formula from AlgDesign so that AlgDesign stops messing up usages of
> model.matrix in other contexts. I think that the solution may perhaps lie in
> assigning the right environment to frml in expand.formula, but I am not
> familiar enough with assigning environments to know what the right strategy
> would be.
>
> Any suggestions ?
>
> Regards,
> Ulrike
>
>
>
> Heather Turner wrote:
>> Hi Ulrike,
>>
>> It looks like 'aus' is created by fac.design(); is there any reason why
>> you can't add the variable
>> y <- 1:nrow(aus)
>> to this data frame and use y as the response in your formula?
>>
>> Otherwise I think aus needs to be in the environment of frml (or frml
>> needs to be given the environment of aus).
>>
>> Heather
>>
>> Ulrike Groemping wrote:
>>> Dear DevelopeRs,
>>>
>>> in continuing with my suite of packages on experimental design, I am
>>> stuck
>>> with an issue that appears to be related to package AlgDesign - I have
>>> tried
>>> to get it solved by Bob Wheeler, but he seems to be stuck as well.
>>>
>>> Whenever AlgDesign is loaded, some of my code does not work any more. For
>>> example, in a fresh R session:
>>>
>>> require(DoE.base)
>>> fac.design(nlevels=c(2,6,2))
>>> require(AlgDesign)
>>> fac.design(nlevels=c(2,6,2))
>>>> Error in nrow(aus) : object 'aus' not found
>>> The reason seems to be that AlgDesign creates a function
>>> model.matrix.formula that only finds variables that are in the global
>>> environment and variables that are in the data frame given with the
>>> formula,
>>> but not calculation results from the intermediate calling environment.
>>>
>>> Results from traceback():
>>> 9: nrow(aus)
>>> 8: eval(expr, envir, enclos)
>>> 7: eval(predvars, data, env)
>>> 6: model.frame.default(object, data, xlev = xlev)
>>> 5: model.frame(object, data, xlev = xlev)
>>> 4: model.matrix.default(frml, data, ...)
>>> 3: model.matrix.formula(1:nrow(aus) ~ ., data = aus)
>>> 2: model.matrix(1:nrow(aus) ~ ., data = aus)
>>> 1: fac.design(nlevels = c(2, 6, 2))
>>>
>>> If I reset model.matrix.formula to model.matrix.default, the problem
>>> disappears (but AlgDesign's comfort functions for squares etc. do not
>>> work
>>> any longer). In this particular case, I can also avoid the issue by
>>> modifying the formula in fac.design, removing the left-hand side. But
>>> this
>>> just means to wait for the next place where troubles occur. Between 3 and
>>> 4
>>> of the traceback(), AlgDesign's function model.matrix.formula modifies
>>> the
>>> formula frml using AlgDesign's function expand.formula:
>>>
>>> model.matrix.formula <- function (frml, data = sys.frame(sys.parent()),
>>> ...)
>>> {
>>> if (!missing(data)) {
>>> if (!inherits(data, "data.frame"))
>>> stop("data must be a data.frame")
>>> if (!inherits(frml, "formula"))
>>> stop("frml must be a formuls")
>>&g
Re: [Rd] model.matrix troubles with AlgDesign
Hi Ulrike,
It looks like 'aus' is created by fac.design(); is there any reason why
you can't add the variable
y <- 1:nrow(aus)
to this data frame and use y as the response in your formula?
Otherwise I think aus needs to be in the environment of frml (or frml
needs to be given the environment of aus).
Heather
Ulrike Groemping wrote:
> Dear DevelopeRs,
>
> in continuing with my suite of packages on experimental design, I am stuck
> with an issue that appears to be related to package AlgDesign - I have tried
> to get it solved by Bob Wheeler, but he seems to be stuck as well.
>
> Whenever AlgDesign is loaded, some of my code does not work any more. For
> example, in a fresh R session:
>
> require(DoE.base)
> fac.design(nlevels=c(2,6,2))
> require(AlgDesign)
> fac.design(nlevels=c(2,6,2))
>> Error in nrow(aus) : object 'aus' not found
>
> The reason seems to be that AlgDesign creates a function
> model.matrix.formula that only finds variables that are in the global
> environment and variables that are in the data frame given with the formula,
> but not calculation results from the intermediate calling environment.
>
> Results from traceback():
> 9: nrow(aus)
> 8: eval(expr, envir, enclos)
> 7: eval(predvars, data, env)
> 6: model.frame.default(object, data, xlev = xlev)
> 5: model.frame(object, data, xlev = xlev)
> 4: model.matrix.default(frml, data, ...)
> 3: model.matrix.formula(1:nrow(aus) ~ ., data = aus)
> 2: model.matrix(1:nrow(aus) ~ ., data = aus)
> 1: fac.design(nlevels = c(2, 6, 2))
>
> If I reset model.matrix.formula to model.matrix.default, the problem
> disappears (but AlgDesign's comfort functions for squares etc. do not work
> any longer). In this particular case, I can also avoid the issue by
> modifying the formula in fac.design, removing the left-hand side. But this
> just means to wait for the next place where troubles occur. Between 3 and 4
> of the traceback(), AlgDesign's function model.matrix.formula modifies the
> formula frml using AlgDesign's function expand.formula:
>
> model.matrix.formula <- function (frml, data = sys.frame(sys.parent()), ...)
> {
> if (!missing(data)) {
> if (!inherits(data, "data.frame"))
> stop("data must be a data.frame")
> if (!inherits(frml, "formula"))
> stop("frml must be a formuls")
> frml <- expand.formula(frml, colnames(data))
> }
> model.matrix.default(frml, data, ...)
> }
>
>
> I have looked at expand.formula as well, and I've been wondering whether a
> simple fix can be found by adding environment information (which?) within
> that function (I believe that the relevant portion of the code is included
> below):
>
> expand.formula <- function (frml, varNames, const = TRUE, numerics = NULL)
> {
> ## omitted quite a bit of code
> ##...
> frml <- deparse(frml, width = 500)
> while ((0 != (pos <- findFunction("quad", frml))[1]) || (0 !=
> (pos <- findFunction("cubicS", frml))[1]) || (0 != (pos <-
> findFunction("cubic",
> frml))[1])) {
> prog <- substr(frml, pos[1], pos[2])
> strHead <- substr(frml, 1, pos[1] - 1)
> strTail <- substr(frml, pos[2] + 1, nchar(frml))
> prog <- eval(parse(text = prog))
> frml <- paste(strHead, prog, strTail, sep = "")
> }
> if (0 != (pos <- findDot(".", frml))[1]) {
> strHead <- substr(frml, 1, pos[1] - 1)
> strTail <- substr(frml, pos[2] + 1, nchar(frml))
> prog <- eval(parse(text = "doDot()"))
> frml <- paste(strHead, prog, strTail, sep = "")
> }
> if (!const)
> frml <- paste(frml, "+0", sep = "")
> frml <- as.formula(frml)
> frml
> }
>
> Any help would be greatly appreciated.
>
> Regards, Ulrike
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages now intentionally references .Rprofile?
I had a similar problem when moving to R-2.9.0 as my .Rprofile called
update.packages(). The solution was to use
if(interactive()) {
utils:::update.packages(ask = FALSE)
}
HTH,
Heather
Mark Kimpel wrote:
> This was my original post, with the code example only slightly modified by
> Martin for clarity. Prior to R-2.9.0, this repeated downloading did not
> occur, the code worked as intended. In fact, if memory serves me correctly,
> it even worked at least during the first 3 months of R-2.0.0 in its
> development stage, before release as a numbered version. Is there a reason
> for that? Is there a work-around? As I mentioned in my original post, the
> code is actually wrapped in a function that checks the date and the date of
> the last update, and proceeds to update package once per week. It was quite
> handy when it was working, hence my desire for a fix for my code.
>
> Thanks,
> Mark
>
> Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry
> Indiana University School of Medicine
>
> 15032 Hunter Court, Westfield, IN 46074
>
> (317) 490-5129 Work, & Mobile & VoiceMail
> (317) 399-1219 Home
> Skype: mkimpel
>
> "The real problem is not whether machines think but whether men do." -- B.
> F. Skinner
> **
>
>
> On Thu, May 21, 2009 at 2:17 AM, Prof Brian Ripley
> wrote:
>
>> On Wed, 20 May 2009, Martin Morgan wrote:
>>
>> A post on the Bioconductor mailing list
>>> https://stat.ethz.ch/pipermail/bioconductor/2009-May/027700.html
>>>
>>> suggests that install.packages now references .Rprofile (?), whereas
>>> in R-2-8 it did not. Is this intentional?
>>>
>> Yes. And in fact it did in earlier versions, to find the default library
>> into which to install.
>>
>>
>>
>>> The example is, in .Rprofile
>>>
>>> library(utils)
>>> install.packages("Biobase",
>>> repos="http://bioconductor.org/packages/2.4/bioc";)
>>>
>>> then starting R from the command line results in repeated downloads
>>> of Biobase
>>>
>>> mtmor...@mm:~/tmp> R --quiet
>>> trying URL
>>> '
>>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>>> '
>>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>>> opened URL
>>> ==
>>> downloaded 1.9 Mb
>>>
>>> trying URL
>>> '
>>> http://bioconductor.org/packages/2.4/bioc/src/contrib/Biobase_2.4.1.tar.gz
>>> '
>>> Content type 'application/x-gzip' length 1973533 bytes (1.9 Mb)
>>> opened URL
>>> ==
>>> downloaded 1.9 Mb
>>>
>>> ^C
>>> Execution halted
>>>
>>> sessionInfo()
>>> R version 2.9.0 Patched (2009-05-20 r48588)
>>> 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=C;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 base
>>>
>>> Martin
>>> --
>>> Martin Morgan
>>> Computational Biology / Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N.
>>> PO Box 19024 Seattle, WA 98109
>>>
>>> Location: Arnold Building M1 B861
>>> Phone: (206) 667-2793
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>> --
>> Brian D. Ripley, rip...@stats.ox.ac.uk
>> Professor of Applied Statistics,
>> http://www.stats.ox.ac.uk/~ripley/
Re: [Rd] using predict method with an offset
Hi Ken,
First of all, whether you specify the offset by the argument or in the
formula, your code requires that q25 is the same length as the variable
Contr. You can set this up by defining your new data as follows:
nd <- data.frame( Contr = cc , q25 = qlogis(0.25))
This sorts out the problem of the warnings/errors. Secondly your two
calls to predict give different results because you have not specified
the same type - the first is predicting on the response scale and the
second is predicting on the link scale. If you use
predict(c1.glm, newdata = nd, type = "response")
predict(c1f.glm, newdata = nd, type = "response")
you get the same result. This does seem to go against the documentation
however, so it would seem that the paragraph you quoted should be taken
out of the help file for predict.lm.
Best wishes,
Heather
Kenneth Knoblauch wrote:
> Hi,
>
> I have run into another problem using offsets, this time with
> the predict function, where there seems to be a contradiction
> again between the behavior and the help page.
>
> On the man page for predict.lm, it says
>
> Offsets specified by offset in the fit by lm will not be included in
> predictions, whereas those specified by an offset term in the formula
> will be.
>
> While it indicates nothings about offsets under ?predict.glm, predict.glm
> calls predict.lm. when there is a newdata argument.
>
> In the example below, the behavior is the opposite of the help
> page, if I am understanding it correctly, and a warning is thrown
> when it does seem to work as desired.
>
> c1 <- structure(list(Contr = c(0.028, 0.043, 0.064, 0.097, 0.146, 0.219
> ), Correct = c(34L, 57L, 94L, 152L, 160L, 160L), Incorrect = c(126L,
> 103L, 66L, 8L, 0L, 0L)), .Names = c("Contr", "Correct", "Incorrect"
> ), row.names = c("13", "15", "17", "19", "21", "23"), class = "data.frame")
>
> q25 <- rep( qlogis( 0.25 ), nrow(c1) )
>
> # offset defined in arguments
> c1.glm <- glm( cbind(Correct, Incorrect) ~ Contr - 1, binomial,
> c1, offset = q25 )
> # offset defined in formula
> c1f.glm <- glm( cbind(Correct, Incorrect) ~ Contr + offset(q25) -1,
> binomial, c1 )
> cc <- seq( 0, 1, len = 10 )
> nd <- data.frame( Contr = cc )
>
> When predict used with model for which offset was defined in
> the arguments, offset is taken into account and a warning
> is emitted.
>
> predict(c1.glm, newdata = nd, type = "response")
>
> 1 2 3 4 5 6 7
> 0.250 0.8859251 0.9945037 0.9997628 0.898 0.996 1.000
> 8 910
> 1.000 1.000 1.000
> Warning message:
> In predictor + offset :
> longer object length is not a multiple of shorter object length
>
> When predict used with model for which offset was defined in
> the formula, an error occurs
>
> predict( c1f.glm, newdata = nd )
>
> Error in model.frame.default(Terms, newdata, na.action = na.action, xlev
> = object$xlevels) :
> variable lengths differ (found for 'offset(q25)')
>
> even if a column for offset is included in newdata,
>
> ndf <- cbind( nd, "offset(q25)" = rep( qlogis(0.25), length(cc) ) )
> predict( c1f.glm, newdata = ndf )
>
> Error in model.frame.default(Terms, newdata, na.action = na.action, xlev
> = object$xlevels) :
> variable lengths differ (found for 'offset(q25)')
>
> unless there is a special way to specify the offset to predict
> that I haven't been able to figure out.
>
> traceback indicates the problem, again, with model.frame.default
>
> Thank you for any clarification.
>
> best,
>
> Ken
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] length 1 offset in glm (& lm)
Prof Brian Ripley wrote:
> On Wed, 25 Feb 2009, Kenneth Knoblauch wrote:
>
>> Hi
>>
>> Quoting Prof Brian Ripley :
>>
>>> On Wed, 25 Feb 2009, Heather Turner wrote:
>>>
>>>> This post about length 1 offsets on R help seems to have been ignored
>>>> (sorry deleted original email - is there a way to continue thread in
>>>> this case?)
>>>>
>>>> https://stat.ethz.ch/pipermail/r-help/2009-February/189352.html
>>>
>>> So let's be clear: this was the 'offset' argument' and not the offset()
>>> function as you refer to below.
>>
>> It occurs for both
>
> Yes (I knew). but no one (AFAICS) said the function allows length-1
> arguments: Heather is raising the possibility that it should as new
> functionality, I believe.
>
Not particularly, just observing that if the problem of handling a
length one offset passed to the offset argument is solved by model.frame
doing the necessary recycling, then offset() would also work with length
one arguments (I think) and this could be a useful feature. If the
problem is solved by dealing with the offset argument separately, then
you wouldn't get this side-benefit, so it's just something to bear in
mind when deciding on a fix.
>> c1 <- structure(list(Contr = c(0.028, 0.043, 0.064, 0.097, 0.146, 0.219
>> ), Correct = c(34L, 57L, 94L, 152L, 160L, 160L), Incorrect = c(126L,
>> 103L, 66L, 8L, 0L, 0L)), .Names = c("Contr", "Correct", "Incorrect"
>> ), row.names = c(NA, 6L), class = "data.frame")
>>
>> glm(cbind(Correct, Incorrect) ~ Contr + offset(qlogis(0.25)) - 1,
>> binomial,
>> data = c1)
>> Error in model.frame.default(formula = cbind(Correct, Incorrect) ~
>> Contr + :
>> variable lengths differ (found for 'offset(qlogis(0.25))')
>> +
>>
>> Thanks for looking into this when time permits.
>>
>> Ken
>>
>> --- remaining deleted
>
>> --
>> Ken Knoblauch
>> Inserm U846
>> Stem-cell and Brain Research Institute
>> Department of Integrative Neurosciences
>> 18 avenue du Doyen Lépine
>> 69500 Bron
>> France
>> tel: +33 (0)4 72 91 34 77
>> fax: +33 (0)4 72 91 34 61
>> portable: +33 (0)6 84 10 64 10
>> http://www.sbri.fr/members/kenneth-knoblauch.html
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] length 1 offset in glm (& lm)
This post about length 1 offsets on R help seems to have been ignored (sorry deleted original email - is there a way to continue thread in this case?) https://stat.ethz.ch/pipermail/r-help/2009-February/189352.html It does seem to be a bug, in that glm does not behave as documented. In fact the same bug applies to lm as well. I don't think the suggested fix works though - Y isn't available until the model frame is evaluated. Moreover you would want to evaluate the offset as part of the model frame, to take care of the search path, subset and na.action. One possibility would be to modify model.frame to recycle variables of length one. This would be a potentially useful feature from my point of view as offset(constant) could replace Const(constant) in gnm, which is basically a work around for this problem in the case of specifying a constant in a nonlinear term. However, this solution may have undesired side-effects and I don't feel too strongly about it as there are various work-arounds. Perhaps the simplest solution would be to modify the docs so that offsets of length one are disallowed - it is easy enough for the user to create a vector of the right length as necessary. Best regards, Heather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proposed simulate.glm method
Yes, thanks to Ben for getting the ball rolling. His code was more
streamlined than mine, pointing to further simplifications which I've
included in the extended version below.
The code for the additional families uses functions from MASS and
SuppDists - I wasn't sure about the best way to do this, so have just
used :: for now.
It appears to be working happily for both glm and gnm objects (no
gnm-specific code used).
Best wishes,
Heather
simulate.glm <- function (object, nsim = 1, seed = NULL, ...)
{
fam <- object$family$family
if(fam == "gaussian")
return(simulate.lm(object, nsim=nsim, seed=seed, ...))
if(!exists(".Random.seed", envir = .GlobalEnv, inherits = FALSE))
runif(1) # initialize the RNG if necessary
if(is.null(seed))
RNGstate <- get(".Random.seed", envir = .GlobalEnv)
else {
R.seed <- get(".Random.seed", envir = .GlobalEnv)
set.seed(seed)
RNGstate <- structure(seed, kind = as.list(RNGkind()))
on.exit(assign(".Random.seed", R.seed, envir = .GlobalEnv))
}
## get probabilities/intensities
pred <- object$fitted
ntot <- length(pred) * nsim
val <- switch(fam,
"poisson" = rpois(ntot, pred),
"binomial" = {
wts <- object$prior.weights
if (any(wts %% 1 != 0))
stop("cannot simulate from non-integer
prior.weights")
rbinom(ntot, size = wts, prob = pred)/wts
},
"Gamma" = {
shape <- MASS::gamma.shape(object)$alpha
rgamma(ntot, shape = shape, rate = shape/pred)
},
"inverse.gaussian" = {
lambda <- 1/summary(object)$dispersion
SuppDists::rinvGauss(ntot, nu = pred, lambda = lambda)
},
stop("family '", fam, "' not yet implemented"))
ans <- as.data.frame(matrix(val, ncol = nsim))
attr(ans, "seed") <- RNGstate
ans
}
Martin Maechler wrote:
> Thanks a lot, Heather,
>
>>>>>> "HT" == Heather Turner
>>>>>> on Fri, 13 Feb 2009 11:49:06 + writes:
>
> HT> Dear Martin,
> HT> I think a simulate.glm method ought to be able to work for gnm objects
> HT> too. David Firth and I started to work on this a long time ago, but
> HT> stopped part-way through when simulate.lm was introduced, thinking
> that
> HT> simulate.glm was probably in the pipeline and we were duplicating
> HT> effort. Obviously we have let this slip when a contribution might have
> HT> been useful. We developed a prototype for poisson, binomial, gaussian,
> HT> gamma and inverse gaussian models which might be usefully merged with
> HT> Ben's proposed simulate.glm. What's the best way to go about this? I
> HT> would also like to test the proposed simulate.glm to check whether it
> HT> will work with gnm objects or whether a simulate.gnm will be
> necessary.
>
> In the mean time, private e-mail communications have started on
> the subject, and yes, we are very insterested in finding
> ``the best'' possible way, probably making use of
> Heather+David's code together with Ben's.
> One alternative (not mentioned yet on R-devel), we've been
> considering is to use simulate.lm() to also deal with "glm" (and
> possibly "gnm") objects ``in one place''.
>
> Martin
>
>
> HT> Martin Maechler wrote:
> >>>>>>> "BB" == Ben Bolker
> >>>>>>> on Thu, 12 Feb 2009 11:29:14 -0500 writes:
> >>
> BB> I have found the "simulate" method (incorporated
> BB> in some packages) very handy. As far as I can tell the
> BB> only class for which simulate is actually implemented
> BB> in base R is lm ... this is actually a little dangerous
> BB> for a naive user who might be tempted to try
> BB> simulate(X) where X is a glm fit instead, because
> BB> it defaults to simulate.lm (since glm inherits from
> BB> the lm class), and the answers make no sense ...
> >>
> BB> Here is my simulate.glm(), which is modeled on
> BB> simulate.lm . It implements simulation for poisson
> BB> and binomial (binary or non-binary) models, should
> BB> be easy to implement others if that seems necessary.
> >>
> BB> I hereby request comments
Re: [Rd] proposed simulate.glm method
Dear Martin, I think a simulate.glm method ought to be able to work for gnm objects too. David Firth and I started to work on this a long time ago, but stopped part-way through when simulate.lm was introduced, thinking that simulate.glm was probably in the pipeline and we were duplicating effort. Obviously we have let this slip when a contribution might have been useful. We developed a prototype for poisson, binomial, gaussian, gamma and inverse gaussian models which might be usefully merged with Ben's proposed simulate.glm. What's the best way to go about this? I would also like to test the proposed simulate.glm to check whether it will work with gnm objects or whether a simulate.gnm will be necessary. Thanks and best regards, Heather Martin Maechler wrote: >> "BB" == Ben Bolker >> on Thu, 12 Feb 2009 11:29:14 -0500 writes: > > BB> I have found the "simulate" method (incorporated > BB> in some packages) very handy. As far as I can tell the > BB> only class for which simulate is actually implemented > BB> in base R is lm ... this is actually a little dangerous > BB> for a naive user who might be tempted to try > BB> simulate(X) where X is a glm fit instead, because > BB> it defaults to simulate.lm (since glm inherits from > BB> the lm class), and the answers make no sense ... > > BB> Here is my simulate.glm(), which is modeled on > BB> simulate.lm . It implements simulation for poisson > BB> and binomial (binary or non-binary) models, should > BB> be easy to implement others if that seems necessary. > > BB> I hereby request comments and suggest that it wouldn't > BB> hurt to incorporate it into base R ... (I will write > BB> docs for it if necessary, perhaps by modifying ?simulate -- > BB> there is no specific documentation for simulate.lm) > > BB> cheers > BB> Ben Bolker > > [...] > > Hi Ben, > thank you for your proposals. > > I agree that simulate.glm() has been in missing in some way, > till now, in particular, as, as you note, "glm" objects extend > "lm" ones and hence simulate(, ...) currently dispatches to > calling simulate.lm() which is only correct in the case of > the gaussian family. > > I have looked at your proposal a bit, already "improved" the > code slightly (e.g. re-include the comment you lost when you > ``copied'' simulate.lm(): In such cases, please work from the > source, not from what you get by print()ing > stats:::simulate.lm --- the source is either a recent tarball, > or the SVN repository, in this case, file > https://svn.r-project.org/R/trunk/src/library/stats/R/lm.R ] > and am planning to look at your and some own examples; > all with the goal to indeed include this in the R standard > 'stats' package in R-devel [to become R 2.9.0 in the future]. > > About the help page: At the moment, I think that only a few > words would need to be added to the simulate help page, > i.e., https://svn.r-project.org/R/trunk/src/library/stats/man/simulate.Rd > and will be happy to receive a patch against this file. > > Thank you again, and best regards, > Martin Maechler, ETH Zurich > > __ > 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] Posting Guide - help.request() function?
Okay, here's the update.
I've created a new function create.post() (with Windows and Unix
versions) which would be the internal function that creates the post
template ready to edit and optionally send. In the Windows version I've
added an experimental method == "mailto" option, which will open the
post template in the default mailer (e.g. Outlook) ready to edit and
post. Maybe a Unix version would also be nice, e.g.
browseURL("mailto:[EMAIL PROTECTED] bug&body=%0A<bug report here>>%0A%0A%0A%0A--please do not edit the information
below--%0A%0AVersion:%0A platform = x86_64-unknown-linux-gnu%0A ...")
would open the post template in e.g. Thunderbird, but has the side
effect of opening an empty page in the web browser. I don't know if
there's a neater solution?
The create.post() function is basically the old bug.report() with two
extra arguments: 'description' (e.g. "bug report") and 'instructions'
(e.g. "\\n<>\\n") for customization. It could be
used directly e.g to post to R-devel with session information.
The new bug.report() simply calls create.post() with the appropriate
arguments.
The improved help-request() function calls create.post() after running
through the checks described before.
In response to Gabor's comments, help.request():
- now checks packages are up-to-date and gives option to update
on-the-fly (user may not know whether involved in query, so check all)
- keeps default mailing options as in old bug.report() but
create.post() gives clearer message ("Email the post now?\n (yes/no)")
requiring definite response ("yes" vs "y")
- still uses online documents because some are only available online
(R Site Search, posting guide), it ensures the most up-to-date
documentation is used, and it allows direction to global FAQ page,
avoiding need to check whether user is on Windows/Mac
- uses more robust method of checking R version is up-to-date
I've also written a help file for help.request() which includes the
method="mailto" option. The help file for bug.report would need updating
if this option was kept.
Best wishes,
Heather
Martin Maechler wrote:
>>>>> "HT" == Heather Turner <[EMAIL PROTECTED]>
>>>>> on Mon, 09 Jun 2008 17:21:17 +0100 writes:
HT> Thanks for the helpful tips and suggestions, I'll work
HT> them in. You get local versions of the documents on Unix
HT> too - RShowDoc() will do the trick.
HT> I'll post an updated version in due course,
Thank you, Heather and Gabor (and the other contributors).
Indeed, I too like the idea of providing a new R function for
this.
Ideally, Heather, you'd try to "factor out" some of the common
functionality of bug.report() and help.request() into a few
utils-namespace hidden auxiliary functions.
Ideally, you'd attach text/plain attachments (base64 encoded) so
there won't be line wrap arounds.
Martin
HT> Gabor Grothendieck wrote:
>> That's an excellent idea.
>>
>> One other item that could be checkable would be if the
>> user has the most recent versions of the packages
>> involved in the query. Perhaps it could display the
>> unupdated packages and ask the user if any of those are
>> involved in the query.
>>
>> Probably needs to give fair warning that it is sending
>> off an email so people don't wind up sending out emails
>> when they are really just trying out the system.
>> Probably "none" should be the default for email so that
>> its not regarded as obnoxious.
>>
>> Might be nice if it used local versions of documents if
>> they exist locally. On Windows they do.
>>
>> Check out ?getRversion
>>
>> On Mon, Jun 9, 2008 at 10:35 AM, Dr Heather Turner
>> <[EMAIL PROTECTED]> wrote:
>>> Whilst it is a good idea to improve the posting guide,
>>> it seems to me that it would be useful to have a
>>> function along the lines of bug.report(), to help a
>>> potential questioner make sure they have done their
>>> homework and have the relevant information to put into a
>>> post to R-help.
>>>
>>> Even those of us who know what ought to go into a post
>>> can sometimes forget to check something obvious - I
>>> recently got caught out by not checking an error was
>>> reproducible in the patched version for example.
>>>
>>> So I have written a help.request() function (see below),
>>> which - prompts the user to check the relev
Re: [Rd] Posting Guide - help.request() function?
Thanks for the helpful tips and suggestions, I'll work them in. You get
local versions of the documents on Unix too - RShowDoc() will do the trick.
I'll post an updated version in due course,
Heather
Gabor Grothendieck wrote:
That's an excellent idea.
One other item that could be checkable would
be if the user has the most recent versions of the packages involved
in the query.Perhaps it could display the unupdated packages
and ask the user if any of those are involved in the query.
Probably needs to give fair warning that it is sending
off an email so people don't wind up sending out emails when they
are really just trying out the system. Probably "none" should be the
default for email so that its not regarded as obnoxious.
Might be nice if it used local versions of documents if they exist
locally. On Windows they do.
Check out ?getRversion
On Mon, Jun 9, 2008 at 10:35 AM, Dr Heather Turner
<[EMAIL PROTECTED]> wrote:
Whilst it is a good idea to improve the posting guide, it seems to me that
it would be useful to have a function along the lines of bug.report(), to
help a potential questioner make sure they have done their homework and have
the relevant information to put into a post to R-help.
Even those of us who know what ought to go into a post can sometimes forget
to check something obvious - I recently got caught out by not checking an
error was reproducible in the patched version for example.
So I have written a help.request() function (see below), which
- prompts the user to check the relevant resources, stopping and opening the
relevant url where necessary
- checks their R version is up-to-date (in a rather messy way - please
suggest improvements!)
- prompts them to prepare appropriate example code and test it in a fresh R
session
- prompts them to give a meaningful subject line
- automatically adds system info to the post (as in bug.report)
- sends the message for them (ensuring a fresh thread is started)
Is this an idea worth taking further? I would be happy to make improvements
as suggested and write a help file if so.
Heather
help.request <- function (subject = "",
ccaddress = Sys.getenv("USER"),
method = getOption("mailer"),
address = "[EMAIL PROTECTED]",
file = "R.help.request")
{
no <- function(answer) answer == "n"
yes <- function(answer) answer == "y"
go <- function(url) {
cat("Please do this first - the site has been loaded in your web
browser\n")
browseURL(url)
}
cat("Checklist:\n")
post <- readline("Have you read the posting guide? (y/n) ")
if (no(post)) return(go("http://www.r-project.org/posting-guide.html";))
FAQ <- readline("Have you checked the FAQ? (y/n) ")
if (no(FAQ)) return(go("http://cran.r-project.org/faqs.html";))
intro <- readline("Have you checked An Introduction to R? (y/n) ")
if (no(intro))
return(go("http://cran.r-project.org/doc/manuals/R-intro.html";))
NEWS <- readline("Have you checked the NEWS of the latest development
release? (y/n) ")
if (no(NEWS)) return(go("https://svn.r-project.org/R/trunk/NEWS";))
rsitesearch <- readline("Have you looked on RSiteSearch? (y/n) ")
if (no(rsitesearch)) {
cat("Please do this first - the site has been loaded in your web
browser\n")
return(RSiteSearch(subject))
}
inf <- sessionInfo()
if ("otherPkgs" %in% names(inf)){
other <- readline("You have packages other than the base packages
loaded.",
"\nIf your query relates to one of these, have you
",
"checked any corresponding books/manuals \nand ",
"considered contacting the package maintainer?
(y/n/NA) ")
if(no(other)) return("Please do this first.")
}
man <- url("http://cran.r-project.org/manuals.html";)
ver <- scan(man, what = character(0), sep = "\n", skip = 13, nlines = 1,
quiet = TRUE)
major <- as.numeric(substr(ver, start = 18, stop = 18))
minor <- as.numeric(substr(ver, start = 20, stop = 22))
if (major < as.numeric(R.Version()$major) ||
minor < as.numeric(R.Version()$major)) {
update <- readline("Your R version is out-of-date, would you like to
update now? (y/n) ")
if (yes(update)) {
return(go(getOption("repos")))
}
}
## To get long prompt!
cat("Have you written example code that is\n",
"- minimal\n - reproducible\n - self-contained\n - commented",
"\
Re: [Rd] Posting Guide - help.request() function?
Whilst it is a good idea to improve the posting guide, it seems to me
that it would be useful to have a function along the lines of
bug.report(), to help a potential questioner make sure they have done
their homework and have the relevant information to put into a post to
R-help.
Even those of us who know what ought to go into a post can sometimes
forget to check something obvious - I recently got caught out by not
checking an error was reproducible in the patched version for example.
So I have written a help.request() function (see below), which
- prompts the user to check the relevant resources, stopping and opening
the relevant url where necessary
- checks their R version is up-to-date (in a rather messy way - please
suggest improvements!)
- prompts them to prepare appropriate example code and test it in a
fresh R session
- prompts them to give a meaningful subject line
- automatically adds system info to the post (as in bug.report)
- sends the message for them (ensuring a fresh thread is started)
Is this an idea worth taking further? I would be happy to make
improvements as suggested and write a help file if so.
Heather
help.request <- function (subject = "",
ccaddress = Sys.getenv("USER"),
method = getOption("mailer"),
address = "[EMAIL PROTECTED]",
file = "R.help.request")
{
no <- function(answer) answer == "n"
yes <- function(answer) answer == "y"
go <- function(url) {
cat("Please do this first - the site has been loaded in your
web browser\n")
browseURL(url)
}
cat("Checklist:\n")
post <- readline("Have you read the posting guide? (y/n) ")
if (no(post)) return(go("http://www.r-project.org/posting-guide.html";))
FAQ <- readline("Have you checked the FAQ? (y/n) ")
if (no(FAQ)) return(go("http://cran.r-project.org/faqs.html";))
intro <- readline("Have you checked An Introduction to R? (y/n) ")
if (no(intro))
return(go("http://cran.r-project.org/doc/manuals/R-intro.html";))
NEWS <- readline("Have you checked the NEWS of the latest
development release? (y/n) ")
if (no(NEWS)) return(go("https://svn.r-project.org/R/trunk/NEWS";))
rsitesearch <- readline("Have you looked on RSiteSearch? (y/n) ")
if (no(rsitesearch)) {
cat("Please do this first - the site has been loaded in your
web browser\n")
return(RSiteSearch(subject))
}
inf <- sessionInfo()
if ("otherPkgs" %in% names(inf)){
other <- readline("You have packages other than the base
packages loaded.",
"\nIf your query relates to one of these,
have you ",
"checked any corresponding books/manuals \nand ",
"considered contacting the package
maintainer? (y/n/NA) ")
if(no(other)) return("Please do this first.")
}
man <- url("http://cran.r-project.org/manuals.html";)
ver <- scan(man, what = character(0), sep = "\n", skip = 13, nlines
= 1, quiet = TRUE)
major <- as.numeric(substr(ver, start = 18, stop = 18))
minor <- as.numeric(substr(ver, start = 20, stop = 22))
if (major < as.numeric(R.Version()$major) ||
minor < as.numeric(R.Version()$major)) {
update <- readline("Your R version is out-of-date, would you
like to update now? (y/n) ")
if (yes(update)) {
return(go(getOption("repos")))
}
}
## To get long prompt!
cat("Have you written example code that is\n",
"- minimal\n - reproducible\n - self-contained\n - commented",
"\nusing data that is either\n",
"- constructed by the code\n - loaded by data()\n",
"- reproduced using dump(\"mydata\", file = \"\")\n")
code <- readline(paste("have you checked this code in a fresh R
session",
"\n(invoking R with the --vanilla option if
possible)",
"\nand is this code copied to the clipboard?
(y/n) "))
if (no(code))
return(cat("\nIf your query is not directly related to code",
"(e.g. a general query \nabout R's capabilities),",
"email [EMAIL PROTECTED] directly. ",
"\nOtherwise prepare some example code first.\n"))
change <- readline(paste("Would you like to change your subject
line:\n",
subject, "\nto something more meaningful?
(y/n) "))
if (yes(change))
subject <- readline("Enter subject: \n")
methods <- c("mailx", "gnudoit", "none", "ess")
method <- if (is.null(method))
"none"
else methods[pmatch(method, methods)]
body <- paste("\\n>",
"\\n<>\\n\\n\\n\\n",
"--please do not edit the information below--\\n\\n",
"Version:\\n ", paste(names(R.version), R.version,
sep =
Re: [Rd] Cook's Distance in GLM (PR#9316)
Well I suppose a warning's not going to hurt. Even in a case like the occupationalStatus example where you know some points have been fitted exactly, it might be useful to be reminded that the standardised residuals for these points are then NaN and cannot be displayed. Of course when you don't know in advance that this issue will arise, there is even more reason to give a warning. So I say add the warning, Heather Martin B. Maechler wrote: > Thank you, Heather, > I've committed a version of your patch (which also works when h_ii ~= 1). > > BTW, when re-reading the code and previous postings about it, > I've been convinced _ again _ that the function *should* warn when points with > h_ii ~= 1 are suppressed. > That latter change is not yet committed. > > Martin Maechler, ETH Zurich -- Dr H Turner Research Fellow Dept. of Statistics The University of Warwick Coventry CV4 7AL Tel: 024 76575870 Fax: 024 76524532 Url: www.warwick.ac.uk/go/heatherturner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] str and class
In previous versions of the gnm package, the terms component of "gnm" objects had a "classID" attribute. This caused problems when used with str as the following simple example illustrates: > x <- 1 > attr(x, "classID") <- "type1" > str(x) Class 'type1' Class 'type1' Class 'type1' Class 'type1' Class 'type1' ... Error: evaluation nested too deeply: infinite recursion / options(expressions=)? The problem is that for S3 objects, str saves attr(object, "class") then recalls str on unclass(object) -- any "class" attribute is removed, but then the "classID" attribute is recursively picked up by attr(object, "class") due to partial matching. Obviously the solution is to use more sensibly named attributes, but str could be made more foolproof by using attr(object, "class", exact = TRUE) instead. Best regards, Heather -- Dr H Turner Research Fellow Dept. of Statistics The University of Warwick Coventry CV4 7AL Tel: 024 76575870 Fax: 024 76524532 Url: www.warwick.ac.uk/go/heatherturner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Incorrect fix for PR#9316: Cook's Distance & plot.lm
This is a multi-part message in MIME format.
--030304040002000407020206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bug PR#9316 noted an inconsistency between the Cook's distance contours
on plot.lm(x, which = 5) and the values given by cooks.distance(x) -- as
shown in plot.lm(x, which = 4) -- for glms:
http://bugs.r-project.org/cgi-bin/R/Analyses-fixed?id=9316;user=guest;selectid=9316
The suggested fix was to modify the contour levels by a dispersion
factor, implemented as follows:
dispersion <- if (isGlm)
summary(x)$dispersion
else 1
cl.h <- sqrt(crit * p * (1 - hh)/hh * dispersion)[1]
where crit is the value of Cook's distance along the contour, p is the
number of parameters and hh is a vector of hat values. It is clear that
in the case of a normal linear model, the cl.h values will depend on
whether the model was fitted by lm or glm. The following example
illustrates this:
par(mfrow = c(2, 2))
plot(lm(y ~ ., data = freeny), 4:5)
plot(glm(y ~ ., data = freeny), 4:5)
For the lm fit we have
crit = (cl.h^2 * hh)/(p * (1 - hh))
where cl.h is on the scale of the standardized residuals. This is the
Cook's distance as defined e.g. in the Cook & Weisberg reference on
?cooks.distance.
For the glm fit we have
crit = (cl.h^2 * hh)/(p * (1 - hh) * summary(x)$dispersion)
which is incorrect.
For glms, as defined in the William's reference on ?cooks.distance, the
Cook's distance is given by
C = (rs^2 * hh)/(p * (1 - hh))
where rs is the standardized *Pearson* residual, i.e.
rs = residuals(x, "pearson")/sqrt(summary(x)$dispersion * (1 - hh))
However plot 5 of plot.lm plots the standardized *deviance* residuals.
Therefore, for non-Gaussian models, contours based on [1], even with
"dispersion" = 1, will be on the wrong scale.
Since the deviance residuals are usually quite similar to the Pearson
residuals, the contours may not be far off, but the difference accounts
for the inconsistency reported in PR#9316.
The solution is simply to plot the standardised Pearson residuals
instead, as in the attached patch.
Best regards,
Heather
--
Dr H Turner
Research Fellow
Dept. of Statistics
The University of Warwick
Coventry
CV4 7AL
Tel: 024 76575870
Fax: 024 76524532
Url: www.warwick.ac.uk/go/heatherturner
--030304040002000407020206
Content-Type: text/x-patch;
name="plot.lm.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="plot.lm.diff"
Index: src/library/stats/R/plot.lm.R
===
--- src/library/stats/R/plot.lm.R (revision 45649)
+++ src/library/stats/R/plot.lm.R (working copy)
@@ -55,7 +55,7 @@
else cooks.distance(x, sd = s, res = r)
}
}
-if (any(show[c(2:3,5)])) {
+if (any(show[2:3])) {
ylab23 <- if (isGlm)
"Std. deviance resid."
else "Standardized residuals"
@@ -167,7 +167,11 @@
text.id(show.r, cook[show.r], show.r, adj.x=FALSE)
}
if (show[5]) {
- ylim <- range(rs, na.rm = TRUE)
+rps <- residuals(x, "pearson")/(s * sqrt(1 - hii))
+ylab5 <- if (isGlm)
+"Std. Pearson resid."
+else "Standardized residuals"
+ ylim <- range(rps, na.rm = TRUE)
if (id.n > 0) {
ylim <- extendrange(r= ylim, f = 0.08)
show.r <- order(-cook)[iid]
@@ -197,15 +201,15 @@
facval[ord] <- facval
xx <- facval # for use in do.plot section.
-plot(facval, rs, xlim = c(-1/2, sum((nlev-1) * ff) + 1/2),
+plot(facval, rps, xlim = c(-1/2, sum((nlev-1) * ff) + 1/2),
ylim = ylim, xaxt = "n",
main = main, xlab = "Factor Level Combinations",
- ylab = ylab23, type = "n", ...)
+ ylab = ylab5, type = "n", ...)
axis(1, at = ff[1]*(1:nlev[1] - 1/2) - 1/2,
labels= x$xlevels[[1]][order(sapply(split(yh,mf[,1]),
mean))])
mtext(paste(facvars[1],":"), side = 1, line = 0.25, adj=-.05)
abline(v = ff[1]*(0:nlev[1]) - 1/2, col="gray", lty="F4")
-panel(facval, rs, ...)
+panel(facval, rps, ...)
abline(h = 0, lty = 3, col = "gray")
}
else { # no factors
@@ -221,21 +225,20 @@
## omit hatvalues of 1.
xx[xx >= 1] <- NA
-plot(xx, rs, xlim = c(0, max(xx, na.rm = TRUE)), ylim = ylim,
- main = main, xlab = "Leverage", ylab = ylab23, type = "n",
+plot(xx, rps, xlim = c(0, max(xx, na.rm = TRUE)), ylim = ylim,
+ main = main, xlab = "Leverage", ylab = ylab5, type = "n",
...)
-panel(xx, rs, ...)
+panel(xx, rps, ...)
abline(h = 0, v = 0, lty = 3, col = "gray")
if (one.fig)
Re: [Rd] Documentation issues [Was: Function hints]
>>> Duncan Murdoch <[EMAIL PROTECTED]> 06/20/06 11:58am >>> On 6/20/2006 5:18 AM, Heather Turner wrote: > I would like to follow up on another one of the documentation issues raised > in the discussion on function hints. Duncan mentioned that the R core were > working on preprocessing directives for .Rd files, which could possibly > include some sort of include directive. I was wondering if a > "includeexamples" directive might also be considered. > > It often makes sense to use the same example to illustrate the use of > different functions, or perhaps extend an example used to illustrate one > function to illustrate another. One way to do this is simply to put > > example(fnA) > > in the \examples for fnB, but this is not particularly helpful for people > reading the help pages as they either need to look at both help pages or run > the example. The alternative is to maintain multiple copies of the same code, > which is not ideal. > > So it would be useful to be able to put > > \includeexamples(fnA) > > so that the code is replicated in fnB.Rd. Perhaps an include directive could > do this anyway, but it might be useful to have a special directive for > examples so that RCMD check is set up to only check the original example to > save time (and unnecessary effort). Thanks, that's a good suggestion. My inclination would be towards just one type of \include; it could be surrounded by notation saying not to check it in all but one instance if the author wanted to save testing time. Fair enough, but at the moment I don't think such notation exists - using \dontrun would skip the check, but would also mean the code would not get run by example(), leading to missing/broken examples. You could introduce a \dontcheck directive but this might be dangerous! Heather > On a related issue, it would be nice if source() had an option to print > comments contained in the source file, so that example() and demo() could > print out annotation. Yes, this has been a long-standing need, but it's somewhat tricky because of the way source currently works: it parses the whole file, then executes the parsed version. The first step loses the comments, so you see a deparsed version when executing. What I think it should do is have pointers back from the parsed version to the original source code, but that needs fairly low level changes. This is some of the missing "infrastructure" I mentioned below. Duncan Murdoch > > Heather > > Dr H Turner > Research Assistant > Dept. of Statistics > The University of Warwick > Coventry > CV4 7AL > > Tel: 024 76575870 > Fax: 024 7652 4532 > Url: www.warwick.ac.uk/go/heatherturner > >>>> <[EMAIL PROTECTED]> 06/20/06 01:43am >>> > [This is not about the feasibility of a "hints" function-- which would > be incredibly useful, but perhaps very very hard to do-- but about some > of the other documentation issues raised in Hadley's post and in > Duncan's reply] > > WRTO documentation & code together: for several years, I've successfully > used the 'mvbutils' package to keep every function definition & its > documentation together, editing them together in the same file-- > function first, then documentation in plain-text (basically the format > you see if you use "vanilla help" inside R). Storage-wise, the > documentation is just kept as an attribute of the function (with a print > method that hides it by default)-- I also keep a text backup of the > combination. Any text editor will do. When it's time to create a > package, the Rd file is generated automatically. > > For me, it's been extremely helpful to keep function & documentation > together during editing-- it greatly increases the chance that I will > actually update the doco when I change the code, rather than putting it > off until I've forgotten what I did. Also, writing Rd format is a > nightmare (again, personal opinion)-- being able to write plain-text > makes the whole documentation thing bearable. > > The above is not quite to the point of the original post, I think, which > talks about storing the documentation as commented bits *inside* the > function code. However, I'm not sure the latter is really desirable; > there is some merit in forcing authors to write an explicit "Details" or > "Description" section that is not just a paraphrase of programming > comments, and such sections are unlikely to fit easily inside code. At > any rate, I wouldn't want to have to interpret my *own* programming > comments as a usage guide! > > WRTO automatic "usage" sections: it is easy t
[Rd] Documentation issues [Was: Function hints]
I would like to follow up on another one of the documentation issues raised in
the discussion on function hints. Duncan mentioned that the R core were working
on preprocessing directives for .Rd files, which could possibly include some
sort of include directive. I was wondering if a "includeexamples" directive
might also be considered.
It often makes sense to use the same example to illustrate the use of different
functions, or perhaps extend an example used to illustrate one function to
illustrate another. One way to do this is simply to put
example(fnA)
in the \examples for fnB, but this is not particularly helpful for people
reading the help pages as they either need to look at both help pages or run
the example. The alternative is to maintain multiple copies of the same code,
which is not ideal.
So it would be useful to be able to put
\includeexamples(fnA)
so that the code is replicated in fnB.Rd. Perhaps an include directive could do
this anyway, but it might be useful to have a special directive for examples so
that RCMD check is set up to only check the original example to save time (and
unnecessary effort).
On a related issue, it would be nice if source() had an option to print
comments contained in the source file, so that example() and demo() could print
out annotation.
Heather
Dr H Turner
Research Assistant
Dept. of Statistics
The University of Warwick
Coventry
CV4 7AL
Tel: 024 76575870
Fax: 024 7652 4532
Url: www.warwick.ac.uk/go/heatherturner
>>> <[EMAIL PROTECTED]> 06/20/06 01:43am >>>
[This is not about the feasibility of a "hints" function-- which would
be incredibly useful, but perhaps very very hard to do-- but about some
of the other documentation issues raised in Hadley's post and in
Duncan's reply]
WRTO documentation & code together: for several years, I've successfully
used the 'mvbutils' package to keep every function definition & its
documentation together, editing them together in the same file--
function first, then documentation in plain-text (basically the format
you see if you use "vanilla help" inside R). Storage-wise, the
documentation is just kept as an attribute of the function (with a print
method that hides it by default)-- I also keep a text backup of the
combination. Any text editor will do. When it's time to create a
package, the Rd file is generated automatically.
For me, it's been extremely helpful to keep function & documentation
together during editing-- it greatly increases the chance that I will
actually update the doco when I change the code, rather than putting it
off until I've forgotten what I did. Also, writing Rd format is a
nightmare (again, personal opinion)-- being able to write plain-text
makes the whole documentation thing bearable.
The above is not quite to the point of the original post, I think, which
talks about storing the documentation as commented bits *inside* the
function code. However, I'm not sure the latter is really desirable;
there is some merit in forcing authors to write an explicit "Details" or
"Description" section that is not just a paraphrase of programming
comments, and such sections are unlikely to fit easily inside code. At
any rate, I wouldn't want to have to interpret my *own* programming
comments as a usage guide!
WRTO automatic "usage" sections: it is easy to write code to do this
('prompt', and there is also some in 'mvbutils'-- not sure if it's in
the current release though) but at least as far as the "usage" section
goes, I think people should be "vigorously encouraged" to write their
own, showing as far as possible how one might actually *use* the
function. For many functions, just duplicating the argument list is not
helpful to the user-- a function can often be invoked in several
different ways, with different arguments relevant to different
invocations. I think it's good to show how this can be done in the
"usage" section, with comments, rather than deferring all practical
usage to "examples". For one thing, "usage" is near the top, and so
gives a very quick reminder without having to scroll through the entire
doco; for another, "usage" and "arguments" are visually adjacent,
whereas "examples" can be widely separated from "arguments".
My general point here is: the documentating process should be as
painless as possible, but not more so. Defaults that are likely to lead
to unhelpful documentation are perhaps best avoided.
For this general reason, I applaud R's fairly rigid documentation
standards, even though I frequently curse them. (And I would like to see
some bits more rigid, such as compulsory "how-to-use-this" documentation
for each package!)
The next version of 'mvbutils' will include various tools for easy "live
editing" and automated preparation of packages-- I've been using them
for a while, but still have to get round to finishing the documentation
;)
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232
[Rd] R CMD check and directory/package name
The NEWS for R 2.3.0 states that "R CMD check works for packages whose package name is different from the directory name in which it is located." However that hasn't been my experience. I ran R CMD check on package sources located in a directory with the same name as the package and it worked as expected. Then I renamed the directory and tried again. The first attempt got stuck when checking installation, so I tried again with option --no-install but it got stuck on checking for missing documentation entries. I can't see a way of getting round this. Perhaps I have misunderstood the NEWS? I can't find this behaviour documented elsewhere. R CMD check output given at the end, Thanks, Heather ## original D:\gnm>RCMD CHECK gnm RCMD CHECK gnm * checking for working latex ... OK * using log directory 'd:/gnm/gnm.Rcheck' * using Version 2.3.1 (2006-06-01) * checking for file 'gnm/DESCRIPTION' ... OK * this is package 'gnm' version '0.8-5' * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'gnm/src' contains object files. * checking whether package 'gnm' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for syntax errors ... OK * checking R files for library.dynam ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking Rd files ... OK * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking for CRLF line endings in C/C++/Fortran sources/headers ... OK * checking for portable compilation flags in Makevars ... OK * creating gnm-Ex.R ... OK * checking examples ... OK * checking tests ... ## some differences cut out to save space here OK make[1]: Leaving directory `/cygdrive/d/gnm/gnm.Rcheck/tests' OK * checking package vignettes in 'inst/doc' ... OK * creating gnm-manual.tex ... OK * checking gnm-manual.tex ... OK WARNING: There was 1 warning, see d:/gnm/gnm.Rcheck/00check.log for details ## first attempt with renamed directory D:\gnm>RCMD CHECK gnm2 * checking for working latex ... OK * using log directory 'D:/gnm/gnm2.Rcheck' * using Version 2.3.1 (2006-06-01) * checking for file 'gnm2/DESCRIPTION' ... OK * this is package 'gnm' version '0.8-5' * checking package dependencies ... OK * checking if this is a source package ... WARNING Subdirectory 'gnm2/src' contains object files. * checking whether package 'gnm' can be installed ... ERROR Installation failed. See 'D:/gnm/gnm2.Rcheck/00install.out' for details. ## D:/gnm/gnm2.Rcheck/00install.out installing R.css in D:/gnm/gnm2.Rcheck -- Making package gnm2 adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... windres --include-dir c:/R/tex/R-2.3.1/include -i gnm2_res.rc -o gnm2_res.o gcc -shared -s -o gnm2.dll gnm2.def gnm.o gnm2_res.o -Lc:/R/tex/R-2.3.1/bin -Lc:/R/tex/R-2.3.1/bin -lRblas -lg2c -lR ... DLL made installing DLL installing R files installing demos installing inst files installing data files installing man source files installing indices Error in .find.package(package, lib.loc, verbose = verbose) : there is no package called 'gnm2' Execution halted make[2]: *** [indices] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-gnm2] Error 2 *** Installation of gnm2 failed *** Removing 'D:/gnm/gnm2.Rcheck/gnm2' ## Second attempt D:\gnm>RCMD CHECK gnm2 --no-install * checking for working latex ... OK * using log directory 'D:/gnm/gnm2.Rcheck' * using Version 2.3.1 (2006-06-01) * checking for file 'gnm2/DESCRIPTION' ... OK * this is package 'gnm' version '0.8-5' * checking if this is a source package ... WARNING Subdirectory 'gnm2/src' contains object files. * checking package directory ... OK * checking for portable file names ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for syntax errors ... OK * checking R files for library.dynam ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking Rd files ... OK * checking Rd cross-references ... OK * checking for missing documentation entries ... ERROR Error: there is no package called 'gnm2' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Loading of namespace on load of .Rdata (was strange behaviourof load)
Apologies - I was not trying to correct you Brian, but to explore how the situation could arise. I'm sure you had a good idea why the namespace (or a reference to it) had been saved, but this was not clear to me and I thought, possibly not to others either. Thanks for putting me right over parent environments vs. enclosures - again I was not trying to correct you with the point I made there, but to trace back where the reference to the namespace might have come from in Giovanni's case. I think the issues raised are still of interest... Heather >>> Prof Brian Ripley <[EMAIL PROTECTED]> 01/18/06 01:31pm >>> On Wed, 18 Jan 2006, Heather Turner wrote: [Lines wrapped for legibility and R-help removed as it is not an appropriate list.] > Last week Giovanni Parrinello posted a message asking why various > packages were loaded when he loaded an .Rdata file. Brian Ripley replied > saying he thought it was because the saved workspace contained a > reference to the namespace of ipred. (Correspondence copied below). > > This begs the question: how did the reference to the namespace of ipred > come to be in the .Rdata file? Brian did say it is likely to be because > the workspace contained object(s) saved with environment the namespace > of ipred - but how would this come about? > > In this case I think is because the .Rdata file contained an object > whose *parent* environment was the namespace of ipred. Take the > following example from ?bagging (having loaded ipred): Excuse me: environments do not have parents but enclosures according to ?environment. Of course, the environment of mod is itself an object, and so my statement holds true. Saving a workspace saves all the objects (possibly as references) whether named or not. I was fully aware that the namespace was likely to be up the environment tree of a named object when I chose my words carefully. >> data(BreastCancer) >> >> mod <- bagging(Class ~ Cl.thickness + Cell.size > + + Cell.shape + Marg.adhesion > + + Epith.c.size + Bare.nuclei > + + Bl.cromatin + Normal.nucleoli > + + Mitoses, data=BreastCancer, coob=TRUE) >> >> environment(mod$mtrees[[1]]$btree$terms) > >> >> parent.env(environment(mod$mtrees[[1]]$btree$terms)) > parent.env is a very confusing name. To quote the draft R language definition: `The parent.env function may be used to access the enclosure of an environment.' [...] -- 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] Loading of namespace on load of .Rdata (was strange behaviour of load)
Last week Giovanni Parrinello posted a message asking why various packages were
loaded when he loaded an .Rdata file. Brian Ripley replied saying he thought it
was because the saved workspace contained a reference to the namespace of
ipred. (Correspondence copied below).
This begs the question: how did the reference to the namespace of ipred come to
be in the .Rdata file? Brian did say it is likely to be because the workspace
contained object(s) saved with environment the namespace of ipred - but how
would this come about?
In this case I think is because the .Rdata file contained an object whose
*parent* environment was the namespace of ipred. Take the following example
from ?bagging (having loaded ipred):
> data(BreastCancer)
>
> mod <- bagging(Class ~ Cl.thickness + Cell.size
+ + Cell.shape + Marg.adhesion
+ + Epith.c.size + Bare.nuclei
+ + Bl.cromatin + Normal.nucleoli
+ + Mitoses, data=BreastCancer, coob=TRUE)
>
> environment(mod$mtrees[[1]]$btree$terms)
>
> parent.env(environment(mod$mtrees[[1]]$btree$terms))
This occurs because the terms object is taken from the model frame which was
evaluated within the environment of a function from the ipred package (here
ipred:::irpart).
Therefore I think the behaviour observed by Giovanni will only occur in unusual
circumstances: when the workspace contains a formula object, a terms object, a
function, or some other object with a non-NULL environment, which has been
created in the environment of a packaged function. In particular, this would
not always occur with a packaged model fitting function, e.g. (from ?loglm in
MASS)
> library(MASS)
> minn38a <- array(0, c(3,4,7,2), lapply(minn38[, -5], levels))
> minn38a[data.matrix(minn38[,-5])] <- minn38$f
> fm <- loglm(~1 + 2 + 3 + 4, minn38a)
> environment(fm$terms)
in this case because the terms component is obtained from the formula, whose
environment is .GlobalEnv.
So, I have two points on this (more for R-devel than R-help now)
1. There is a more general situation where it would be useful to load the
namespace of a package after loading a saved workspace: when the workspace
contains objects of a class for which special methods are required. E.g. if
'fm' from the example above were saved in a workspace, the namespace of MASS
would not be loaded when the workspace was loaded into R. Thus unless MASS was
loaded by the user, default methods would be used by summary(), print() etc
rather than the specialised methods for objects of class "loglm".
Of course the user should quickly realise this, but there may be cases where
the default method gives a convincing but incorrect or unhelpful result. An
alternative would be to add an attribute to objects of class "loglm" (say),
e.g. attr(loglmObject, ".Environment") <- environment(MASS)
so that the namespace would automatically be loaded when it is required. [In
fact alternatives such as environment(loglmObject) <- environment(MASS) or
loglmObject$anyoldthing <- environment(MASS) would work just as well, but
perhaps the first suggestion is neatest.].
What do others think of this idea? Should it (or an equivalent idea) be
encouraged amongst package writers?
2. In the case highlighted by Giovanni, the namespace of ipred was loaded, but
the package was not. This would be fine, except that the packages on which
ipred depends *were* loaded. This seems inconsistent. I guess as long as there
are packages without namespaces though, this is the only way to proceed.
Perhaps in the meantime, package authors should be encouraged to use
importFrom() rather than import()? Or perhaps where packages do have
namespaces, only the namespace should be loaded in such a case.
Heather
> From: Prof Brian Ripley <[EMAIL PROTECTED]>
> Date: 12 January 2006 08:21:35 GMT
> To: giovanni parrinello <[EMAIL PROTECTED]>
> Cc: r-help@stat.math.ethz.ch
> Subject: Re: [R] Strange behaviour of load
>
> On Wed, 11 Jan 2006, giovanni parrinello wrote:
>
>> Dear All,
>> simetimes when I load an Rdata I get this message
>>
>> ###
>> Code:
>>
>> load('bladder1.RData')
>> Carico il pacchetto richiesto: rpart ( Bad traslastion: Load required
>> package-...)
>> Carico il pacchetto richiesto: MASS
>> Carico il pacchetto richiesto: mlbench
>> Carico il pacchetto richiesto: survival
>> Carico il pacchetto richiesto: splines
>>
>> Carico il pacchetto richiesto: 'survival'
>>
>>
>>The following object(s) are masked from package:Hmisc :
>>
>> untangle.specials
>>
>> Carico il pacchetto richiesto: class
>> Carico il pacchetto richiesto: nnet
>> #
>>
>> So I have many unrequired packages loaded.
>> Any idea?
>
> They are required! My guess is that you have object(s) saved with
> environment the namespace of some package, and loading that namespace
> is
> pulling these in. The only CRAN package which requires mlbench
> appears to
> be ipred, and that requires all of those
Re: [Rd] standardized residuals (rstandard & plot.lm) (PR#8468)
This bug is not quite fixed - the example from my original report now =
works using R-2.2.1, but
plot(Uniform, 6)
does not. The bug is due to
if (show[6]) {
ymx <- max(cook, na.rm =3D TRUE) * 1.025
g <- hatval/(1 - hatval) # Potential division by zero here #
plot(g, cook, xlim =3D c(0, max(g)), ylim =3D c(0, ymx),=20
main =3D main, xlab =3D "Leverage", ylab =3D "Cook's distance",=
=20
xaxt =3D "n", type =3D "n", ...)
...
All other values of 'which' seem to work fine. Sorry not to have checked =
this in the beta version,
Heather
>>> Prof Brian Ripley <[EMAIL PROTECTED]> 12/06/05 04:10pm >>>
Curiously, I was just looking at that, since I believe the answer =
should=20
be NaN, and some optimizing compilers/fast BLASes are not giving that.
(There's an example in reg-test-3.R.) So I think we need to return NaN=20
when hat is within rounding error of 1.
My take is that plot.lm should handle this: you will see most but not =
all=20
cases have na.rm=3DTRUE in calculating ylim, but as Inf is theoretically
impossible it has not been considered.
Note that plot.lm does not use rstandard and so needs a separate fix.
Thanks for the report
On Tue, 6 Dec 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Heather Turner
> Version: 2.2.0
> OS: Windows XP
> Submission from: (NULL) (137.205.240.44)
>
>
> Standardized residuals as calculated by rstandard.lm, rstandard.glm and =
plot.lm
> are Inf/NaN rather than zero when the un-standardized residuals are =
zero. This
> causes plot.lm to break when calculating 'ylim' for any of the plots of
> standardized residuals. Example:
>
> "occupationalStatus" <-
>structure(as.integer(c(50, 16, 12, 11, 2, 12, 0, 0, 19, 40, 35,
> 20, 8, 28, 6, 3, 26, 34, 65, 58, 12, 102, 19, =
14, 8,
> 18, 66, 110, 23, 162, 40, 32, 7, 11, 35, 40, =
25, 90,
> 21, 15, 11, 20, 88, 183, 46, 554, 158, 126, 6, =
8,
> 23,
> 64, 28, 230, 143, 91, 2, 3, 21, 32, 12, 177, =
71,
> 106)
> ), .Dim =3D as.integer(c(8, 8)), .Dimnames =3D
> structure(list(origin =3D c("1", "2", "3", "4", "5", "6", =
"7",
> "8"),
> destination =3D c("1", "2", "3", "4", "5", =
"6", "7",
> "8")), .Names =3D c("origin", "destination"))=
,
> class =3D "table")
> Diag <- as.factor(diag(1:8))
> Rscore <- scale(as.numeric(row(occupationalStatus)), scale =3D FALSE)
> Cscore <- scale(as.numeric(col(occupationalStatus)), scale =3D FALSE)
> Uniform <- glm(Freq ~ origin + destination + Diag +
> Rscore:Cscore, family =3D poisson, data =3D occupationalSta=
tus)
> residuals(Uniform)[as.logical(diag(8))] #zero/near-zero
> rstandard(Uniform)[as.logical(diag(8))] #mostly Inf/NaN
> plot(Uniform) #breaks on qqnorm plot (or any 'which' > 1)
>
> This could be fixed by replacing standardized residuals with zero where =
the hat
> value is one, e.g.
> rstandard.glm <- function (model,
>infl =3D lm.influence(model, do.coef =3D =
FALSE),
>...) {
> res <- infl$wt.res
> hat <- infl$hat
> ifelse(hat =3D=3D 1, 0, res/sqrt(summary(model)$dispersion * (1 -
> infl$hat)))
> }
> etc.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel=20
>
>
--=20
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/=20
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] standardized residuals (rstandard & plot.lm) (PR#8367)
Full_Name: Heather Turner
Version: 2.2.0
OS: Windows XP
Submission from: (NULL) (137.205.240.44)
Standardized residuals as calculated by rstandard.lm, rstandard.glm and plot.lm
are Inf/NaN rather than zero when the un-standardized residuals are zero. This
causes plot.lm to break when calculating 'ylim' for any of the plots of
standardized residuals. Example:
"occupationalStatus" <-
structure(as.integer(c(50, 16, 12, 11, 2, 12, 0, 0, 19, 40, 35,
20, 8, 28, 6, 3, 26, 34, 65, 58, 12, 102, 19, 14, 8,
18, 66, 110, 23, 162, 40, 32, 7, 11, 35, 40, 25, 90,
21, 15, 11, 20, 88, 183, 46, 554, 158, 126, 6, 8,
23,
64, 28, 230, 143, 91, 2, 3, 21, 32, 12, 177, 71,
106)
), .Dim = as.integer(c(8, 8)), .Dimnames =
structure(list(origin = c("1", "2", "3", "4", "5", "6", "7",
"8"),
destination = c("1", "2", "3", "4", "5", "6", "7",
"8")), .Names = c("origin", "destination")),
class = "table")
Diag <- as.factor(diag(1:8))
Rscore <- scale(as.numeric(row(occupationalStatus)), scale = FALSE)
Cscore <- scale(as.numeric(col(occupationalStatus)), scale = FALSE)
Uniform <- glm(Freq ~ origin + destination + Diag +
Rscore:Cscore, family = poisson, data = occupationalStatus)
residuals(Uniform)[as.logical(diag(8))] #zero/near-zero
rstandard(Uniform)[as.logical(diag(8))] #mostly Inf/NaN
plot(Uniform) #breaks on qqnorm plot (or any 'which' > 1)
This could be fixed by replacing standardized residuals with zero where the hat
value is one, e.g.
rstandard.glm <- function (model,
infl = lm.influence(model, do.coef = FALSE),
...) {
res <- infl$wt.res
hat <- infl$hat
ifelse(hat == 1, 0, res/sqrt(summary(model)$dispersion * (1 -
infl$hat)))
}
etc.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Using matprod from array.c
Hi,
I was wondering if I could use the matprod function from array.c in my own C
routine. I tried the following as a test
/* my_matprod.c */
# include /* for REAL, SEXP etc */
# include /* array.c says need for dgemm */
/* following copied from array.c */
static void matprod(double *x, int nrx, int ncx,
double *y, int nry, int ncy, double *z)
{
char *transa = "N", *transb = "N";
int i, j, k;
double one = 1.0, zero = 0.0, sum;
Rboolean have_na = FALSE;
if (nrx > 0 && ncx > 0 && nry > 0 && ncy > 0) {
/* Don't trust the BLAS to handle NA/NaNs correctly: PR#4582
* The test is only O(n) here
*/
for (i = 0; i < nrx*ncx; i++)
if (ISNAN(x[i])) {have_na = TRUE; break;}
if (!have_na)
for (i = 0; i < nry*ncy; i++)
if (ISNAN(y[i])) {have_na = TRUE; break;}
if (have_na) {
for (i = 0; i < nrx; i++)
for (k = 0; k < ncy; k++) {
sum = 0.0;
for (j = 0; j < ncx; j++)
sum += x[i + j * nrx] * y[j + k * nry];
z[i + k * nrx] = sum;
}
} else
F77_CALL(dgemm)(transa, transb, &nrx, &ncy, &ncx, &one,
x, &nrx, y, &nry, &zero, z, &nrx);
} else /* zero-extent operations should return zeroes */
for(i = 0; i < nrx*ncy; i++) z[i] = 0;
}
/* test function: matrix multiplication of nr by nc matrix with nc-vector */
SEXP my_matprod(SEXP M, SEXP v, SEXP nr, SEXP nc) {
R_len_t nrm = INTEGER(nr)[0], ncm = INTEGER(nc)[0];
SEXP ans;
PROTECT(ans = allocMatrix(REALSXP, nrm, 1));
matprod(REAL(M), nrm, ncm,
REAL(v), ncm, 1, REAL(ans));
UNPROTECT(1);
return(ans);
}
When I try to make the DLL I get the following
D:\C_routines>RCMD SHLIB my_matprod.c
making my_matprod.d from my_matprod.c
gcc -IC:/R/tex/R-2.2.0/include -Wall -O2 -c my_matprod.c -o my_matprod.o
ar cr my_matprod.a my_matprod.o
ranlib my_matprod.a
gcc --shared -s -o my_matprod.dll my_matprod.def my_matprod.a -LC:/R/tex/R-2.
2.0/src/gnuwin32 -lg2c -lR
my_matprod.a(my_matprod.o)(.text+0x19a):my_matprod.c: undefined reference to `dg
emm_'
collect2: ld returned 1 exit status
make: *** [my_matprod.dll] Error 1
I'm using Windows XP and I'm using the MinGW gcc. It works fine if I comment
out the Fortran call so that the method for have_na is always used.
Do I need to include another header file to use dgemm? Is there a better way to
use matprod than just to copy the code?
Any help appreciated,
Heather
Dr H Turner
Research Assistant
Dept. of Statistics
The University of Warwick
Coventry
CV4 7AL
Tel: 024 76575870
Url: www.warwick.ac.uk/go/heatherturner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] storage.mode, C data types and speed
Hi,
I am trying to speed up part of an algorithm in which certain columns of a
large matrix (X) are replaced by the element-wise product of a matrix (M) and a
vector (v). In R, the code might be
X[, ind] <- M * v
I have written a small C routine to do this for me, but the timing depends on
how I define the storage.mode of the objects in R and the data types in C, in a
way which I don't understand.
To illustrate, suppose I have the following for X, M and v:
nr <- 1
X <- matrix(1, nr, 500)
M <- matrix(1:(nr*450), nr, 450)
v <- 1:nr
storage.mode(X) <- storage.mode(M) <- storage.mode(v) <- "double"
Then I have the following integers required by my C code - these are the
objects which I'm not sure how to handle
a <- 50*nr#index of X indicating where to start replacing values
nm <- length(M)
nv <- length(v)
I would have thought I wanted
storage.mode(a) <- storage.mode(nm) <- storage.mode(nv) <- "integer"
to go with the following C code
# include
SEXP prod_integer(SEXP X, SEXP M, SEXP v, SEXP a, SEXP nm, SEXP nv) {
int i = INTEGER(a)[0], i1 = 0, i2 = 0;
for ( ; i1 < INTEGER(nm)[0]; i2 = (++i2 == INTEGER(nv)[0]) ? 0 : i2) {
REAL(X)[i++] = REAL(M)[i1++] * REAL(v)[i2];
}
return(X);
}
Running this is R gives the following timings on my PC
> dyn.load("D:/C_routines/prod_integer")
> for(i in 1:3) {print(system.time(.Call("prod_integer", X, M, v, a, nm, nv)))}
[1] 0.17 0.00 0.18 NA NA
[1] 0.18 0.00 0.17 NA NA
[1] 0.15 0.00 0.17 NA NA
But strangely (to me) if I change the storage mode of my integers to "double",
I get
> storage.mode(a) <- storage.mode(nm) <- storage.mode(nv) <- "double"
> for(i in 1:3) {print(system.time(.Call("prod_integer", X, M, v, a, nm, nv)))}
[1] 0 0 0 NA NA
[1] 0 0 0 NA NA
[1] 0 0 0 NA NA
If on the other hand I use REAL instead of INTEGER in my C code:
# include
SEXP prod_real(SEXP X, SEXP M, SEXP v, SEXP a, SEXP nm, SEXP nv) {
int i = REAL(a)[0], i1 = 0, i2 = 0;
for ( ; i1 < REAL(nm)[0]; i2 = (++i2 == REAL(nv)[0]) ? 0 : i2) {
REAL(X)[i++] = REAL(M)[i1++] * REAL(v)[i2];
}
return(X);
}
The reverse is true:
> storage.mode(a) <- storage.mode(nm) <- storage.mode(nv) <- "integer"
> for(i in 1:3) {print(system.time(.Call("prod_real", X, M, v, a, nm, nv)))}
[1] 0 0 0 NA NA
[1] 0 0 0 NA NA
[1] 0 0 0 NA NA
> storage.mode(a) <- storage.mode(nm) <- storage.mode(nv) <- "double"
> for(i in 1:3) {print(system.time(.Call("prod_real", X, M, v, a, nm, nv)))}
[1] 0.22 0.00 0.22 NA NA
[1] 0.21 0.00 0.20 NA NA
[1] 0.21 0.00 0.22 NA NA
> identical(.Call("prod_integer", X, M, v, a, nm, nv), .Call("prod_real", X, M,
> v, a, nm, nv))
[1] TRUE
So I seem to get the fastest results if I store a, nm and nv as doubles in R
and treat them as integers in C or if I store them as integers in R and treat
them as doubles in C, rather than matching the storage in R to the data type in
C.
I must be misunderstanding something here. Can someone explain what's going on
- please note I have only just begun to learn C, apologies if this is a basic C
issue.
Thanks,
Heather
Dr H Turner
Research Assistant
Dept. of Statistics
The University of Warwick
Coventry
CV4 7AL
Tel: 024 76575870
Url: www.warwick.ac.uk/go/heatherturner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.data.frame.table responseName argument (PR#8006)
Full_Name: Heather Turner Version: 2.1.1 OS: Windows XP Submission from: (NULL) (137.205.240.44) I get an error when trying to use the responseName argument of as.data.frame.table, e.g. > ## Create table > f <- gl(3, 3) > tab <- table(f) > tab f 1 2 3 3 3 3 > ## Convert to data.frame - works fine > dat1 <- as.data.frame(tab) > dat1 f Freq 1 13 2 23 3 33 > ## As above with responseName - get error > dat2 <- as.data.frame(tab, responseName = "count") Error in as.data.frame(tab, responseName = "count") : unused argument(s) (responseName ...) I have checked the arguments of as.data.frame.table and responseName is there: > args(as.data.frame.table) function (x, row.names = NULL, optional = FALSE, responseName = "Freq", ...) NULL but I notice as.data.frame has no dots argument > args(as.data.frame) function (x, row.names = NULL, optional = FALSE) NULL which would (I think) explain the error, Heather __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
