Re: [Rd] [R] library(): load library from a specified location
[ re-diverted to R-devel ] Barry Rowlingson b.rowling...@lancaster.ac.uk on Tue, 30 Mar 2010 20:15:00 +0100 writes: On Tue, Mar 30, 2010 at 7:58 PM, Rolf Turner r.tur...@auckland.ac.nz wrote: But ***please*** say ``load *package*'', not ``load library''. The *location* (collection of packages) from which you wish to load the given package is the ``library''. Anyone vote for deprecating the library() function and renaming it use() or requiring require() instead? I'm voting pro. We (R core) had planned to do this, probably about 5 to eight years ago, then started discussing about possible features of the new use() function, of making a package into an object that you'd want to interrogate, ... and then probably got tired ;-) With the many moons passed, I'd now tend to *not* add features, but really renamed 'library' to 'use' and create a library() with a deprecation message which then simply calls use()... and yes, I'd allow a very exceptionally long deprecation period of two to five years before making library() defunct. Martin I mean, when I go get a book out of our library, I don't say I'd like to library Case Studies in Spatial Point Process Modelling. Maybe we should use 'borrow(package)'? Then it might be clear you were getting a package from a library, and that you magically put it back at the end of your R session Slightly silly mood this evening Barry __ r-h...@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] svn.r-project.org with new trusted certificate
The SVN (Subversion) Server of the R-project, svn.r-project.org, financed and run by the Math Department of ETH Zurich, now has got it's own validated aka trusted SSL certificate, mostly thanks to Simon Urbanek (R-core) and his employer, ATT Labs. This may mean that those of you who have been using the R development sources, (or had scripts that read the logs, or ...) may need to cache the new certificate by some one-time manual interaction. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] difficulties with setMethod([ and ...
Tony Plate tpl...@acm.org
on Mon, 17 May 2010 20:51:12 -0600 writes:
Jim, yes, I have dealt with that particular challenge that list(...)
throws an error for a call like f(x,,,) where the empty args match to a
... formal argument. Here's some fragments of code that I used to cope
with this:
# to find the empty anon args, must work with the unevaluated dot args
dot.args.uneval - match.call(expand.dots=FALSE)$...
if (length(dot.args.uneval))
missing.dot.args - sapply(dot.args.uneval, function(arg)
is.symbol(arg) as.character(arg)==)
else
missing.dot.args - logical(0)
...
# Now we can work with evaluated dot args.
# Can't do dot.args - list(...) because that will
# stop with an error for missing args.
dot.args - mapply(dot.args.uneval, missing.dot.args,
FUN=function(arg, m) if (!m) eval(arg) else NULL)
I don't have much time at the moment, to delve into Jim's code,
nor to analyze what exactly Tony's does.
Some notes however which I deem important:
1) My experiece in writing many S4 methods for [ -- with the
Matrix package, but also for 'Rmpfr' -- is that you
really need to work with nargs()
rather than with things like length(list(...))
2) If you really want to be compatible to the very rich
semantics of S and R subsetting, you need to spend more time
than you anticipate.
- negative subscripts, names, logicals
- A[i] for an array A where i can be a vector and then the
array is treated as if it had no dim() attribute
- A[i] for an array A where i is a *matrix* with k columns
where k - length(dim(A)) --- (k = 2 for matrices)
- A[]
Are you sure you would not try to use
setClass('myExample', contains = array, representation = ...)
rather than your
setClass('myExample', representation(x = array, ...))
?
You would get all the [ (and other array methods) for free,
and would only need to specify those methods where 'myExample'
really differed from array-subsetting.
3) Lots of well-testedsetMethod([, ) examples
are in the sources of the Matrix package.
There, BTW, I found it useful to use
## for 'i' in x[i] or A[i,] : (numeric = {double, integer})
setClassUnion(index, members = c(numeric, logical, character))
and then, e.g., a simple example method ..
setMethod([, signature(x = denseMatrix, i = index, j = missing,
drop = logical),
function (x, i, j, ..., drop) {
if((na - nargs()) == 3)
r - as(x, matrix)[i, drop=drop]
else if(na == 4)
r - as(x, matrix)[i, , drop=drop]
else stop(invalid nargs()= ,na)
if(is.null(dim(r))) r else as(r, geClass(x))
})
The examples in the Rmpfr package are much less and simpler.
To find the methods, for both, use
fgrep 'setMethod([' R/*R
if you are on a decent OS and in side the package source directory.
--
Martin Maechler, ETH Zurich
Let me know if you need any further explanation.
Several warnings:
* I was using this code with S3 generics and methods.
* There are quite possibly better ways of detecting empty unevaluated
arguments than 'is.symbol(arg) as.character(arg)=='.
* You'll probably want to be careful that the eval() in the last line is
using the appropriate environment for your application.
I didn't read your code in detail, so apologies if the above is
off-the-point, but your verbal description of the problem and the coding
style and comments in the [ method for myExample triggered my memory.
-- Tony Plate
On 05/17/2010 07:48 PM, James Bullard wrote:
Apologies if I am not understanding something about how things are being
handled when using S4 methods, but I have been unable to find an answer
to
my problem for some time now.
Briefly, I am associating the generic '[' with a class which I wrote
(here: myExample). The underlying back-end allows me to read contiguous
slabs, e.g., 1:10, but not c(1, 10). I want to shield the user from this
infelicity, so I grab the slab and then subset in memory. The main
problem
is with datasets with dim(.) 2. In this case, the '...' argument
doesn't
seem to be in a reasonable state. When it is indeed missing then it
properly reports that fact, however, when it is not missing it reports
that it is not missing, but then the call to: list(...) throws an
argument
is missing exception.
I cannot imagine that this has not occurred before, so I am expecting
someone might be able to point me to some example code. I have attached
some code demonstrating my general problem ((A) and (B) below) as well as
the outline of the sub-selection code. I have to say that coding this has
proven non-trivial
[Rd] BIC() in stats {was [R-sig-ME] how to extract the BIC value}
MM == Martin Maechler maech...@stat.math.ethz.ch
on Tue, 18 May 2010 12:37:21 +0200 writes:
GaGr == Gabor Grothendieck ggrothendi...@gmail.com
on Mon, 17 May 2010 09:45:00 -0400 writes:
GaGr BIC seems like something that would logically go into stats in the
GaGr core of R, as AIC is already, and then various packages could define
GaGr methods for it.
MM Well, if you look at help(AIC):
Usage:
AIC(object, ..., k = 2)
Arguments:
object: a fitted model object, for which there exists a ‘logLik’
method to extract the corresponding log-likelihood, or an
object inheriting from class ‘logLik’.
...: optionally more fitted model objects.
k: numeric, the _penalty_ per parameter to be used; the default
‘k = 2’ is the classical AIC.
MM you may note that the original authors of AIC where always
MM allowing the AIC() function (and its methods) to compute the BIC,
MM simply by using 'k = log(n)' where of course n must be correct.
MM I do like the concept that BIC is just a variation of AIC and
MM AFAIK, AIC was really first (historically).
MM Typically (and with lme4), the 'n' needed is already part of the
logLik()
MM attributes :
AIC((ll - logLik(fm1)), k = log(attr(ll,nobs)))
MM REML
MM 1774.786
MM indeed gives the BIC (where the REML name may or may not be a
MM bit overkill)
MM A stats-package based BIC function could then simply be defined as
BIC - function (object, ...) UseMethod(BIC)
BIC.default - function (object, ...) BIC(logLik(object), ...)
BIC.logLik - function (object, ...)
AIC(object, ..., k = log(attr(object,nobs)))
{well, modulo the fact that ... should really allow to do
this for *several* models simultaneously}
In addition to that (and more replying to Doug Bates):
Given nlme's tradition of explicitly providing BIC(), and in
analogue to the S3 semantics of the AIC() methods,
- I think lme4 (and lme4a on R-forge) should end up having
working AIC() and BIC() directly for fitted models, instead of
having to use
AIC(logLik(.)) andBIC(logLik(.))
The reason that even the first of this currently does *not*
work is that lme4 imports AIC from stats but should do so
from stats4.
-- I'm about to change that for 'lme4' (and 'lme4a').
However, for the BIC case, ... see below
- I tend to agree with Gabor (for once! :-) that
basic BIC methods (S3, alas) should move from nlme to stats.
For this reason, I'm breaking the rule of do not cross-post
for once, and am hereby diverting this thread to R-devel
Martin
MM --
MM Martin Maechler, ETH Zurich
GaGr On Mon, May 17, 2010 at 9:29 AM, Douglas Bates ba...@stat.wisc.edu
wrote:
On Mon, May 17, 2010 at 5:54 AM, Andy Fugard (Work)
andy.fug...@sbg.ac.at wrote:
Greetings,
Assuming you're using lmer, here's an example which does what you need:
(fm1 - lmer(Reaction ~ Days + (Days|Subject), sleepstudy))
Linear mixed model fit by REML
Formula: Reaction ~ Days + (Days | Subject)
Data: sleepstudy
AIC BIC logLik deviance REMLdev
1756 1775 -871.8 1752 1744
Random effects:
Groups Name Variance Std.Dev. Corr
Subject (Intercept) 612.092 24.7405
Days 35.072 5.9221 0.066
Residual 654.941 25.5918
Number of obs: 180, groups: Subject, 18
Fixed effects:
Estimate Std. Error t value
(Intercept) 251.405 6.825 36.84
Days 10.467 1.546 6.77
Correlation of Fixed Effects:
(Intr)
Days -0.138
(fm1fit - summary(fm1)@AICtab)
AIC BIC logLik deviance REMLdev
1755.628 1774.786 -871.8141 1751.986 1743.628
fm1fit$BIC
[1] 1774.786
That's one way of doing it but it relies on a particular
representation of the object returned by summary, and that is subject
to change.
I had thought that it would work to use
BIC(logLik(fm1))
but that doesn't because the BIC function is imported from the nlme
package but not later exported. The situation is rather tricky - at
one point I defined a generic for BIC in the lme4 package but that led
to conflicts when multiple packages defined different versions. The
order in which the packages were loaded became important in
determining which version was used.
We agreed to use the generic from the nlme package, which is what is
now done. However, I don't want to make the entire nlme package
visible when you have loaded lme4 because of resulting conflicts.
I can get the result as
(fm1 - lmer(Reaction ~ Days + (Days|Subject), sleepstudy))
Linear mixed model fit by REML
Formula: Reaction ~ Days + (Days | Subject)
Data
Re: [Rd] BIC() in stats {was [R-sig-ME] how to extract the BIC value}
Adding to my own statements (below) :
MM == Martin Maechler maech...@stat.math.ethz.ch
on Tue, 18 May 2010 13:05:27 +0200 writes:
MM == Martin Maechler maech...@stat.math.ethz.ch
on Tue, 18 May 2010 12:37:21 +0200 writes:
GaGr == Gabor Grothendieck ggrothendi...@gmail.com
on Mon, 17 May 2010 09:45:00 -0400 writes:
GaGr BIC seems like something that would logically go into stats in the
GaGr core of R, as AIC is already, and then various packages could define
GaGr methods for it.
MM Well, if you look at help(AIC):
Usage:
AIC(object, ..., k = 2)
Arguments:
object: a fitted model object, for which there exists a ‘logLik’
method to extract the corresponding log-likelihood, or an
object inheriting from class ‘logLik’.
...: optionally more fitted model objects.
k: numeric, the _penalty_ per parameter to be used; the default
‘k = 2’ is the classical AIC.
MM you may note that the original authors of AIC where always
MM allowing the AIC() function (and its methods) to compute the BIC,
MM simply by using 'k = log(n)' where of course n must be correct.
MM I do like the concept that BIC is just a variation of AIC and
MM AFAIK, AIC was really first (historically).
MM Typically (and with lme4), the 'n' needed is already part of the
logLik()
MM attributes :
AIC((ll - logLik(fm1)), k = log(attr(ll,nobs)))
MM REML
MM 1774.786
MM indeed gives the BIC (where the REML name may or may not be a
MM bit overkill)
MM A stats-package based BIC function could then simply be defined as
BIC - function (object, ...) UseMethod(BIC)
BIC.default - function (object, ...) BIC(logLik(object), ...)
BIC.logLik - function (object, ...)
AIC(object, ..., k = log(attr(object,nobs)))
MM {well, modulo the fact that ... should really allow to do
MM this for *several* models simultaneously}
MM In addition to that (and more replying to Doug Bates):
MM Given nlme's tradition of explicitly providing BIC(), and in
MM analogue to the S3 semantics of the AIC() methods,
MM - I think lme4 (and lme4a on R-forge) should end up having
MM working AIC() and BIC() directly for fitted models, instead of
MM having to use
MM AIC(logLik(.)) andBIC(logLik(.))
MM The reason that even the first of this currently does *not*
MM work is that lme4 imports AIC from stats but should do so
MM from stats4.
MM -- I'm about to change that for 'lme4' (and 'lme4a').
MM However, for the BIC case, ... see below
MM - I tend to agree with Gabor (for once! :-) that
MM basic BIC methods (S3, alas) should move from nlme to stats.
MM For this reason, I'm breaking the rule of do not cross-post
MM for once, and am hereby diverting this thread to R-devel
What I *did* find is that the stats4 package has already had
all necessary BIC methods -- S4, not S3.
So for lme4 (and R-forge's lme4a),
I've only needed to change the NAMESPACE file to have both
importFrom(stats4, AIC, BIC, logLik)# so S4 methods are used!
and later
export(AIC, BIC,
.)
and also add 'stats4' to the 'Imports: ' line in DESCRIPTION.
So both (development versions of) lme4 and lme4a now have
working AIC() and BIC(),
and I guess Doug could release a new version of lme4 (not ..a)
pretty soon.
I got private e-mail suggestions for extensive S3 methods for
AIC, BIC and logLik.
I think these should happen more in public (i.e. here, on
R-devel), and while I still advocate that a BIC S3 generic +
simple default methods should be added (as above),
I'd be happy if others joined into the discussion,
(and possibly provided simple patches).
Martin Maechler, ETH Zurich
GaGr On Mon, May 17, 2010 at 9:29 AM, Douglas Bates ba...@stat.wisc.edu
wrote:
On Mon, May 17, 2010 at 5:54 AM, Andy Fugard (Work)
andy.fug...@sbg.ac.at wrote:
Greetings,
Assuming you're using lmer, here's an example which does what you
need:
(fm1 - lmer(Reaction ~ Days + (Days|Subject), sleepstudy))
Linear mixed model fit by REML
Formula: Reaction ~ Days + (Days | Subject)
Data: sleepstudy
AIC BIC logLik deviance REMLdev
1756 1775 -871.8 1752 1744
Random effects:
Groups Name Variance Std.Dev. Corr
Subject (Intercept) 612.092 24.7405
Days 35.072 5.9221 0.066
Residual 654.941 25.5918
Number of obs: 180, groups: Subject, 18
Fixed effects:
Estimate Std. Error t value
(Intercept) 251.405 6.825 36.84
Days 10.467 1.546 6.77
Correlation of Fixed Effects:
(Intr)
Days -0.138
(fm1fit - summary(fm1)@AICtab)
AIC BIC logLik deviance REMLdev
1755.628 1774.786 -871.8141 1751.986 1743.628
fm1fit$BIC
Re: [Rd] [R] avoiding reinstall already installed *package*
On Tue, May 18, 2010 at 22:38, William Dunlap wdun...@tibco.com wrote:
-Original Message-
From: r-help-boun...@r-project.org
[mailto:r-help-boun...@r-project.org] On Behalf Of Martin Maechler
Sent: Tuesday, May 18, 2010 1:25 PM
To: milton ruser
Cc: r-h...@r-project.org
Subject: Re: [R] avoiding reinstall already installed *package*
On Tue, May 18, 2010 at 18:06, milton ruser
milton.ru...@gmail.com wrote:
Hi Martin,
thanks for your reply, and very thanks for your kind tips
about package
and library
So, I was trying to understand *why* we load packages using
library().
I've started to use and suggest using require(.) instead
{as my efforts to introduce use() or usePackage() *and* deprecating
library() where met with strong opposition}
I hate to get into arguments over function names, but
I would have thought that require(pkg) would throw
an error if the required pkg was not available. It seems
like require() can be used when pkg is not really required
but library(pkg) is easiest when pkg is required to
continue:
{ require(noSuchPackage); functionFromNoSuchPackage() }
Loading required package: noSuchPackage
Error: could not find function functionFromNoSuchPackage
In addition: Warning message:
In library(package, lib.loc = lib.loc, character.only = TRUE,
logical.return = TRUE, :
there is no package called 'noSuchPackage'
{ library(noSuchPackage); functionFromNoSuchPackage() }
Error in library(noSuchPackage) :
there is no package called 'noSuchPackage'
Well, both require() and library() pretty soon lead to an error if the
package is not available... but I agree that you'd prefer to get the more
helpful error message immediately rather than belatedly.
If that's an issue, the typical use of require() would be
if(require(...)) {
...
...
} else {
stop(. not available; do this or that )
}
but instead of stop(..) which can provide a context dependent, customized
error message, you can also work around the absence of the package in other
ways.
a usePackage() function would typically use best of library() and
require() ,
maybe not allowing usePackage(MASS)
but requiring usePackage(MASS)
but also working logically e.g. for
mylme - lme4
usePackage(mylme)
i.e. not allowing non-standard evaluation.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
I suggest that developers killl the problem on its root,
deleting library
function :-)
Good to know already installed packages will not be reinstalled.
cheers
milton
On Tue, May 18, 2010 at 12:49 PM, Martin Maechler
maech...@stat.math.ethz.ch wrote:
{ I've modified the subject; I can't stand it hitting square into
my face ... }
mr == milton ruser milton.ru...@gmail.com
on Tue, 18 May 2010 12:36:23 -0300 writes:
mr Dear R-experts,
mr I am installing new libraries using
mr install.packages(ggplot2,dependencies=T).
mr But I perceive that many dependencies are already
installed. As I
am using
mr a low-band internet, how can avoid reinstall
installed libraries?
There's no problem with installed libraries, as ...
they DO NOT EXIST.
These are *PACKAGES* !
Why do you think are you talking about the function
install.packages()
---
To answer the question you did want to ask:
Do not be afraid: Depedencies are only installed when needed,
i.e., no package will be downloaded and installed if it already
is there.
Martin Maechler, ETH Zurich
mr cheers
mr milton
mr [[alternative HTML version deleted]]
(another thing you should learn to avoid, please)
[[alternative HTML version deleted]]
__
r-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN vs DVCS
Felix Andrews fe...@nfrac.org on Wed, 26 May 2010 11:20:12 +1000 writes: On second thoughts it is really none of my business how the R sources are managed. But I would encourage package developers and/or r-forge maintainers to consider these systems. Thank you, Felix, for the compilation of these alternatives. One very relevant piece of information that you've not added, is, how easily one could *move* from svn to such a system (including the full history of every file with revision numbers, log messages, etc), and .. for R-forge, e.g., which of these provide nice and flexible tools (as svn does) for an automatic web interface to inspect file histories, differences, etc. Regards, Martin ( maintainer of svn.r-project.org ) Regards -Felix On 26 May 2010 10:29, Felix Andrews fe...@nfrac.org wrote: Hi, Just wondering whether anyone had thought about moving the R sources to a distributed version control system such as Bazaar, Git or Mercurial. These new generation systems make it easier to work on feature branches, allow working offline, are very fast, etc. Some projects that have moved to Git are Linux Kernel Perl Ruby on Rails ... http://en.wikipedia.org/wiki/Git_(software) Some projects that have moved to Bazaar (bzr) are Ubuntu MySQL Inkscape ... http://en.wikipedia.org/wiki/Bazaar_(software) Some projects that have moved to Mercurial (hg) are Mozilla Octave Python ... http://en.wikipedia.org/wiki/Mercurial_(software) Joel Spolky's take on it: http://www.joelonsoftware.com/items/2010/03/17.html Regards -Felix -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ -- Felix Andrews / 安福立 Postdoctoral Fellow Integrated Catchment Assessment and Management (iCAM) Centre Fenner School of Environment and Society [Bldg 48a] The Australian National University Canberra ACT 0200 Australia M: +61 410 400 963 T: + 61 2 6125 4670 E: felix.andr...@anu.edu.au CRICOS Provider No. 00120C -- http://www.neurofractal.org/felix/ __ 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] warning from install.packages()
BB == Ben Bolker bol...@ufl.edu
on Wed, 02 Jun 2010 13:45:18 -0400 writes:
BB Michael Dewey wrote:
At 13:40 01/06/2010, Ben Bolker wrote:
On 25/05/10 23:25 PM, Ben Bolker bolker at ufl.edu wrote:
Just curious: is there a particular reason why install.packages()
gives a warning in normal use when 'lib' is not specified (e.g.
argument
'lib' is missing: using '/usr/local/lib/R/site-library' )?
As I see it R is saying 'I am doing what you told
me, but just in case I am checking whether that
was what you really wanted'. Note that you do not
get a warning if there was only one place R could
put it. I would certainly vote for a message if
people are getting unnecessarily alarmed by the warning.
BB But this seems so different from R's general philosophy/behavior
BB (inherited from Unix?) that a function that gets correct input and
BB executes without error returns silently ...
That's correct.
Note however that installing a package is not just a thing
happening in your R session.
It will affect all your future R sessions, and possibly even
other users' who have the same .libPaths()[1]
{e.g. the group here does share it}.
I'd agree to not put a warning but I'd definitely want a message
aka note to the user.
The *wording* of that note should not be alarming at all, I
agree, just a note to the user.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning from install.packages()
VG == Vincent Goulet vincent.gou...@act.ulaval.ca
on Thu, 3 Jun 2010 10:24:21 -0400 writes:
VG Le jeu. 3 juin à 09:27, Ben Bolker a écrit :
Martin Maechler wrote:
BB == Ben Bolker bol...@ufl.edu
on Wed, 02 Jun 2010 13:45:18 -0400 writes:
BB Michael Dewey wrote:
At 13:40 01/06/2010, Ben Bolker wrote:
On 25/05/10 23:25 PM, Ben Bolker bolker at ufl.edu wrote:
Just curious: is there a particular reason why install.packages()
gives a warning in normal use when 'lib' is not specified (e.g.
argument
'lib' is missing: using '/usr/local/lib/R/site-library' )?
As I see it R is saying 'I am doing what you told
me, but just in case I am checking whether that
was what you really wanted'. Note that you do not
get a warning if there was only one place R could
put it. I would certainly vote for a message if
people are getting unnecessarily alarmed by the warning.
BB But this seems so different from R's general philosophy/behavior
BB (inherited from Unix?) that a function that gets correct input and
BB executes without error returns silently ...
That's correct.
Note however that installing a package is not just a thing
happening in your R session.
It will affect all your future R sessions, and possibly even
other users' who have the same .libPaths()[1]
{e.g. the group here does share it}.
I'd agree to not put a warning but I'd definitely want a message
aka note to the user.
The *wording* of that note should not be alarming at all, I
agree, just a note to the user.
Martin Maechler, ETH Zurich
OK, then, how about this as a minimal change?
===
--- packages.R (revision 52192)
+++ packages.R (working copy)
@@ -534,8 +534,8 @@
if(missing(lib) || is.null(lib)) {
lib - .libPaths()[1L]
-warning(gettextf(argument 'lib' is missing: using %s, lib),
-immediate. = TRUE, domain = NA)
+message(gettextf(argument 'lib' is missing: using %s, lib),
+domain = NA)
}
paths - .find.package(pkgs, lib)
Index: packages2.R
===
--- packages2.R (revision 52192)
+++ packages2.R (working copy)
@@ -193,8 +193,8 @@
if(missing(lib) || is.null(lib)) {
lib - .libPaths()[1L]
if(length(.libPaths()) 1L)
-warning(gettextf(argument 'lib' is missing: using '%s',
lib),
-immediate. = TRUE, domain = NA)
+message(gettextf(argument 'lib' is missing: using '%s',
lib),
+domain = NA)
}
## check for writability by user
VG I wholeheartedly support the change discussed here since it is also
something that has been worrying my students for some time.
VG However, I think saying argument 'lib' not specified: using '%s'
would be even less alarming. ... is missing sort of implies the user forgot
something.
Yes, thank you Vincent,
I meant some such change when I said
The *wording* of that note should not be alarming at all, I
agree, just a note to the user.
I'd even change it further, to something like
Installing package into '%s' (as 'lib' is not specified)
Martin
VG Dr. Vincent Goulet
VG Full Professor
VG École d'actuariat, Université Laval, Québec
VG vincent.gou...@act.ulaval.ca http://vgoulet.act.ulaval.ca
--
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
*** NEW E-MAIL ADDRESSES:
*** bbol...@gmail.com , bol...@math.mcmaster.ca
bol...@ufl.edu / people.biology.ufl.edu/bolker
GPG key: people.biology.ufl.edu/bolker/benbolker-publickey.asc
signature.ascATT1..txt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] named empty list
HP == Hervé Pagès hpa...@fhcrc.org on Thu, 03 Jun 2010 13:25:10 -0700 writes: HP Hi, HP I just realized that a named empty list is displayed the same HP way as an empty list: list(aa=2:5)[0] HP list() list() HP list() HP For empty atomic vectors, the print method makes the difference: c(aa=3L)[0] HP named integer(0) integer(0) HP integer(0) HP Maybe lists could do that too? Yes, I agree. I have had at least one situation in the past where I had even been confused for a few minutes by this. I'm about to add it for R-devel [2.12.0] (only; considering it a new feature). Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Argument recycling in substring()
HP == Hervé Pagès hpa...@fhcrc.org on Thu, 03 Jun 2010 17:53:33 -0700 writes: HP Hi, HP According to its man page substring() expands (its) arguments HP cyclically to the length of the longest _provided_ none are of HP zero length. HP So, as expected, I get an error here: substring(abcd, first=2L, last=integer(0)) HP Error in substring(abcd, first = 2L, last = integer(0)) : HP invalid substring argument(s) HP But I don't get one here: substring(character(0), first=1:2, last=3L) HP character(0) HP which is unexpected. according to the docu. My gut feeling would say that the documentation should be updated in this case, rather than the implementation. RFC! other opinions? HP Otherwise, yes substring() will recycle its arguments to the HP length of the longest: substring(abcd, first=1:3, last=4:3) HP [1] abcd bc cd HP Cheers, HP H. HP -- HP Hervé Pagès HP Program in Computational Biology HP Division of Public Health Sciences HP Fred Hutchinson Cancer Research Center HP 1100 Fairview Ave. N, M2-B876 HP P.O. Box 19024 HP Seattle, WA 98109-1024 HP E-mail: hpa...@fhcrc.org HP Phone: (206) 667-5791 HP Fax:(206) 667-1319 HP __ HP R-devel@r-project.org mailing list HP 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] seek() and gzfile() on 32-bit R2.12.0 in linux
BW == Brandon Whitcher bwhitc...@gmail.com on Wed, 23 Jun 2010 12:14:35 +0100 writes: BW Peter, thanks for your comments. The reason I have taken this issue BW to R-devel is from the advice of Kurt Hornik. An update to my package BW oro.nifti is being refused by CRAN because it fails on the BW _development_ version of R on 32-bit linux. As we have just discussed BW (and thanks to Matt's input), the problem is not with my package but BW with the development version of R. Hence, I wanted to alert to the R BW Core Development Team that the _unstable_ version of R appears to have BW a problem. BW Obviously, I would prefer to have my new version of oro.nifti accepted BW by CRAN... but at the moment I am in between a rock and a hard place. BW I agree that the 2.12.0 release of R is quite far in the future. Is BW there a possibility of relaxing the exclusion criteria BW for CRAN? Well, the criteria are very good as a general rule, but in the case where a new/changed package reveals a *bug* in R-devel (only), the package of course should still be released to CRAN. So the only remaining problem for you ;-) is to convince the CRAN maintainers that indeed this is a bug in R-devel, or probably in zlib 1.2.4 (R 2.11.x uses zlib 1.2.3). Within R-core, Brian Ripley has been the zlib principal investigator, and I'd wait a bit for his comment on this issue. Martin Maechler, ETH Zurich and R-Core Team BW cheers... BW Brandon PD Please notice that there is NO release of R 2.12.0 until some time PD around October. You are using a build from the UNSTABLE development PD branch. The stable branch is 2.11.1 with a release date of May 31. If PD Ubuntu is claiming that there is such a thing as a R 2.12.0 release, I'd PD say that they have a problem. PD Not that we don't welcome reports on problems in the development branch, PD but do notice that it is by definition UNSTABLE, and that bugs can come PD and go without notice. PD -pd __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAs and weighted.mean
RobMcG == McGehee, Robert robert.mcge...@geodecapital.com on Wed, 23 Jun 2010 19:38:44 -0400 writes: RobMcG R-developers, RobMcG In version R 2.11.0, weighted.mean was changed such that: weighted.mean(NA, na.rm=TRUE) RobMcG [1] 0 RobMcG rather than NaN as in previous versions of R. which versions? Even in 2.10.0 it gave 0. RobMcG rather than NaN as in previous versions of R. I see a note in the NEWS RobMcG file indicates that weighted.mean was changed so an infinite value with RobMcG zero weight does not force an NaN result. RobMcG In case the side effect of returning 0 rather than NaN in this case was RobMcG unintentional, I'd like to propose that this case be reverted such that RobMcG weighted.mean(NA, na.rm=TRUE) returns a NaN to be consistent with the RobMcG mean function. I tend to agree with you. Note that also, for such functions FUN FUN(NA, na.rm=TRUE) identical to FUN( numeric(0) ) and for mean-like functions I agree it should return NaN (or NA, perhaps). RobMcG Otherwise perhaps a note should be added in the RobMcG documentation explaining this inconsistent RobMcG behavior. RobMcG I believe this patch should fix the problem while preserving the RobMcG behavior in the NEWS file: RobMcG -w - w/sum(w) RobMcG -sum((x*w)[w != 0]) RobMcG +sum((x*w)[w != 0])/sum(w)d Yes, it seems so, and I will probably commit it, for R-devel at first, and R-patched later after a while. Martin Maechler, ETH Zurich RobMcG Here's the full note from the NEWS file. RobMcG o The default method of weighted.mean(x, w) coerces 'w' to be RobMcG numeric (aka double); previously only integer weights were RobMcG coerced. Zero weights are handled specially so an infinite RobMcG value with zero weight does not force an NaN result. RobMcG Thanks, Robert __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] POSIXlt matching bug
RobMcG == McGehee, Robert robert.mcge...@geodecapital.com on Tue, 29 Jun 2010 10:46:06 -0400 writes: RobMcG I came across the below mis-feature/bug using match with POSIXlt objects RobMcG (from strptime) in R 2.11.1 (though this appears to be an old issue). x - as.POSIXlt(Sys.Date()) table - as.POSIXlt(Sys.Date()+0:5) length(x) RobMcG [1] 1 x %in% table # I expect TRUE RobMcG [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE match(x, table) # I expect 1 RobMcG [1] NA NA NA NA NA NA NA NA NA RobMcG This behavior seemed more plausible when the length of a POSIXlt object RobMcG was 9 (back in the day), however since the length was redefined, the RobMcG length of x no longer matches the length of the match function output, RobMcG as specified by the ?match documentation: A vector of the same length RobMcG as 'x'. RobMcG I would normally suggest that we add a POSIXlt method for match that RobMcG converts x into POSIXct or character first. However, match does not RobMcG appear to be generic. Below is a possible rewrite of match that appears RobMcG to work as desired. RobMcG match - function(x, table, nomatch = NA_integer_, incomparables = NULL) RobMcG .Internal(match(if(is.factor(x)||inherits(x, POSIXlt)) RobMcG as.character(x) else x, RobMcG if(is.factor(table)||inherits(table, POSIXlt)) RobMcG as.character(table) else table, RobMcG nomatch, incomparables)) RobMcG That said, I understand some people may be very sensitive to the speed RobMcG of the match function, yes, indeed. I'm currently investigating an alternative, considerably more programming time, but in the end should loose much less speed, is to .Internal()ize the tests in C code, so that the resulting R code would simply be match - function(x, table, nomatch = NA_integer_, incomparables = NULL) .Internal(x, table, nomatch, incomparables) Martin Maechler, ETH Zurich RobMcG and may prefer a simple change to the ?match RobMcG documentation noting this (odd) behavior for POSIXlt. RobMcG Thanks, Robert RobMcG R.version RobMcG _ RobMcG platform x86_64-unknown-linux-gnu RobMcG arch x86_64 RobMcG os linux-gnu RobMcG system x86_64, linux-gnu RobMcG status RobMcG major 2 RobMcG minor 11.1 RobMcG year 2010 RobMcG month 05 RobMcG day31 RobMcG svn rev52157 RobMcG language R RobMcG version.string R version 2.11.1 (2010-05-31) RobMcG Robert McGehee, CFA RobMcG Geode Capital Management, LLC RobMcG One Post Office Square, 28th Floor | Boston, MA | 02109 RobMcG Tel: 617/392-8396Fax:617/476-6389 RobMcG mailto:robert.mcge...@geodecapital.com This e-mail, and any attachments hereto, are intended for use by the RobMcG addressee(s) only and may contain information that is (i) confidential RobMcG information of Geode Capital Management, LLC and/or its affiliates, RobMcG and/or (ii) proprietary information of Geode Capital Management, LLC RobMcG and/or its affiliates. If you are not the intended recipient of this RobMcG e-mail, or if you have otherwise received this e-mail in error, please RobMcG immediately notify me by telephone (you may call collect), or by e-mail, RobMcG and please permanently delete the original, any print outs and any RobMcG copies of the foregoing. Any dissemination, distribution or copying of RobMcG this e-mail is strictly prohibited. RobMcG __ RobMcG R-devel@r-project.org mailing list RobMcG 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] POSIXlt matching bug
MM == Martin Maechler maech...@stat.math.ethz.ch on Fri, 2 Jul 2010 12:22:07 +0200 writes: RobMcG == McGehee, Robert robert.mcge...@geodecapital.com on Tue, 29 Jun 2010 10:46:06 -0400 writes: RobMcG I came across the below mis-feature/bug using match with POSIXlt objects RobMcG (from strptime) in R 2.11.1 (though this appears to be an old issue). x - as.POSIXlt(Sys.Date()) table - as.POSIXlt(Sys.Date()+0:5) length(x) RobMcG [1] 1 x %in% table # I expect TRUE RobMcG [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE match(x, table) # I expect 1 RobMcG [1] NA NA NA NA NA NA NA NA NA RobMcG This behavior seemed more plausible when the length of a POSIXlt object RobMcG was 9 (back in the day), however since the length was redefined, the RobMcG length of x no longer matches the length of the match function output, RobMcG as specified by the ?match documentation: A vector of the same length RobMcG as 'x'. RobMcG I would normally suggest that we add a POSIXlt method for match that RobMcG converts x into POSIXct or character first. However, match does not RobMcG appear to be generic. Below is a possible rewrite of match that appears RobMcG to work as desired. RobMcG match - function(x, table, nomatch = NA_integer_, incomparables = NULL) RobMcG .Internal(match(if(is.factor(x)||inherits(x, POSIXlt)) RobMcG as.character(x) else x, RobMcG if(is.factor(table)||inherits(table, POSIXlt)) RobMcG as.character(table) else table, RobMcG nomatch, incomparables)) RobMcG That said, I understand some people may be very sensitive to the speed RobMcG of the match function, MM yes, indeed. MM I'm currently investigating an alternative, considerably more MM programming time, but in the end should loose much less speed, MM is to .Internal()ize the tests in C code, MM so that the resulting R code would simply be MM match - function(x, table, nomatch = NA_integer_, incomparables = NULL) MM .Internal(x, table, nomatch, incomparables) I have committed such a change to R-devel, to be 2.12.x. This should mean that match() actually is now very slightly faster than it used to be. The speed gain may not be measurable though. Martin Maechler, ETH Zurich RobMcG and may prefer a simple change to the ?match RobMcG documentation noting this (odd) behavior for POSIXlt. RobMcG Thanks, Robert RobMcG R.version RobMcG _ RobMcG platform x86_64-unknown-linux-gnu RobMcG arch x86_64 RobMcG os linux-gnu RobMcG system x86_64, linux-gnu RobMcG status RobMcG major 2 RobMcG minor 11.1 RobMcG year 2010 RobMcG month 05 RobMcG day31 RobMcG svn rev52157 RobMcG language R RobMcG version.string R version 2.11.1 (2010-05-31) RobMcG Robert McGehee, CFA RobMcG Geode Capital Management, LLC RobMcG One Post Office Square, 28th Floor | Boston, MA | 02109 RobMcG Tel: 617/392-8396Fax:617/476-6389 RobMcG mailto:robert.mcge...@geodecapital.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Best way to determine if you're running 32 or 64 bit R on windows
Jeffrey Horner jeffrey.horner at gmail.com writes:
Is this sufficient?
if (.Machine$sizeof.pointer==4){
cat('32\n')
} else {
cat('64\n')
}
Or is it better to test something in R.version, say os?
No, the above is perfect, as it also works on other platforms to distinguish
32-bit and 64-bit.
Regards, Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] kmeans
Gabor Grothendieck ggrothendi...@gmail.com
on Fri, 2 Jul 2010 18:50:28 -0400 writes:
In kmeans() in stats one gets an error message with the default
clustering algorithm if centers = 1. Its often useful to calculate
the sum of squares for 1 cluster, 2 clusters, etc. and this error
complicates things since one has to treat 1 cluster as a special case.
A second reason is that easily getting the 1 cluster sum of squares
makes it easy to calculate the between cluster sum of squares when
there is more than 1 cluster.
I suggest adding the line marked ### to the source code of kmeans (the
other lines shown are just ther to illustrate context). Adding this
line forces kmeans to use the code for algorithm 3 if centers is 1.
This is useful since unlike the code for the default algorithm, the
code for algorithm 3 succeeds for centers = 1.
if(length(centers) == 1) {
if (centers == 1) nmeth - 3 ###
k - centers
I agree that this is a reasonable improvement,
and have applied this (+ docu + example) to the R-devel sources.
Thank you, Gabor.
Also note that KMeans in Rcmdr produces a betweenss and a tot.withinss
and it would be nice if kmeans in stats did that too:
Well, patches (to the R-devel *sources*) are happily accepted
Martin
library(Rcmdr)
str(KMeans(USArrests, 3))
List of 6
$ cluster : Named int [1:50] 1 1 1 2 1 2 3 1 1 2 ...
..- attr(*, names)= chr [1:50] Alabama Alaska Arizona Arkansas
...
$ centers : num [1:3, 1:4] 11.81 8.21 4.27 272.56 173.29 ...
..- attr(*, dimnames)=List of 2
.. ..$ : chr [1:3] 1 2 3
.. ..$ : chr [1:4] Murder Assault UrbanPop Rape
$ withinss: num [1:3] 19564 9137 19264
$ size: int [1:3] 16 14 20
$ tot.withinss: num 47964 =
$ betweenss : num 307844 =
- attr(*, class)= chr kmeans
__
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] arr.ind argument to which.min and which.max
HenrikB == Henrik Bengtsson h...@stat.berkeley.edu
on Mon, 5 Jul 2010 22:53:59 +0200 writes:
HenrikB ...and, of course, just after sending it off I found out that from
R
HenrikB v2.11.0 there is now an arrayInd() in the 'base' package doing
exactly
HenrikB the same thing. See help(arrayInd).
yes... and if you wondered *who* re-factored which() into its
internal the arrayInd() part .
.
had not known about the R.utils function.
[]
On Mon, Jul 5, 2010 at 8:27 PM, Patrick Burns pbu...@pburns.seanet.com
wrote:
On 05/07/2010 10:56, Martin Maechler wrote:
PatB == Patrick Burnspbu...@pburns.seanet.com
on Sun, 04 Jul 2010 09:43:44 +0100 writes:
PatB Is there a reason that 'which.min' and
PatB 'which.max' don't have an 'arr.ind'
PatB argument?
well, help(which.min) tells you that they really were aimed at
doing their job *fast* for vectors.
Of course you are right and a generalization to arrays might be
convenient at times.
PatB The context in which I wanted that was
PatB a grid search optimization, which seems
PatB like it would be reasonably common to me.
well, as the author of these two functions, I can only say
patches are welcome!
and I think should be pretty simple, right ?
You just have to do very simple remapping of the 1d index 'i' back
to the array index, i.e., the same operation
you need to transform seconds into days:hours:minutes:seconds
{{and yes, we old-timers may recall that APL had an operator (I
think T-bar) to do that ...}
I think the exercise is just to copy the definition of
'which' and add four characters.
Well, yes. But then, one reason for refactoring 'which' into its
vector and arrayInd() part was that people could use arrayInd()
on its own.
Wouldn't it make more sense to call
arrayInd(which.min(mat), dim(mat))
instead of
which.min(mat, arr.ind = TRUE)
in the spirit of modularity, maintainability, ... ?
Honestly, in my first reply I had forgotten about my own
arrayInd() modularization
If the order of the if condition were reversed, then
possibly the slight reduction in speed of 'which.min'
and 'which.max' would be more than made up for in the
slight increase in speed of 'which'.
thanks for the hint, but
increase in speed of 'which' -- really, can you measure that?
(I'll reverse the order anyway)
If we are interested in speed increase, we should add an option
to *not* work with dimnames at all (*) and if we have programmer
time left, we could take it .Internal() and get a real
boost... not now though.
(*) I'm doing that for now, *and* I would like to change the
default behavior or arrayInd(), but of course *not* the
default behavior of which(),
to *not* attach dimnames to the result, by default.
I.e., I'm proposing to add 'useNames = FALSE' as argument to
arrayInd() but have which() call arrayInd(..., useNames=TRUE).
This is a back-compatibility change in arrayInd() -- which has
existed only since 2.11.0 anyway, so would seem ok, to me.
Opinions ?
--
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Large discrepancies in the same object being saved to .RData
DM == Duncan Murdoch murdoch.dun...@gmail.com
on Sun, 11 Jul 2010 17:25:45 -0400 writes:
DM On 11/07/2010 1:30 PM, Prof Brian Ripley wrote:
[]
On 7/10/2010 10:10 PM, bill.venab...@csiro.au wrote:
Well, I have answered one of my questions below. The hidden
environment is attached to the 'terms' component of v1.
Well, not really hidden. A terms component is a formula
(see ?terms.object), and a formula has an environment
just as a closure does. In neither case does the print()
method tell you about it -- but ?formula does.
DM I've just changed the default print method for formulas to display the
DM environment if it is not globalenv(), which is the rule used for
DM closures as well. So now in R-devel:
as.formula(y ~ x)
DM y ~ x
DM as before, but
as.formula(y ~ x, env=new.env())
DM y ~ x
DM environment: 01f83400
I see that our print.formula() actually has not truely fulfilled
our own rule about print methods:
?print has
Description:
‘print’ prints its argument and returns it _invisibly_
..
Further, I completely agree that it's good to mention the
environment, however, it can be a nuisance when it's part of a
larger print(.) method, so I'd like allowing to suppress that
and hence I've committed the current
print.formula - function(x, showEnv = !identical(e, .GlobalEnv), ...)
{
e - environment(.x - x) ## return(.) original x
attr(x, .Environment) - NULL
print.default(unclass(x), ...)
if (showEnv) print(e)
invisible(.x)
}
--
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken link to new features in R-devel: no NEWS file
Prof Brian Ripley rip...@stats.ox.ac.uk on Wed, 21 Jul 2010 07:27:58 +0100 (BST) writes: Please report problems with websites to the webmaster: no one else can handle them. I believe that for CRAN the appropriate address is cran-ad...@r-project.org. In addition, please let me note that one of the very oldest websites for R *developement* has been http://stat.ethz.ch/R-manual/ (used to be called R-alpha) it contains manuals of both R patched and R manual *and* direct links to the NEWS of both. One reason, I have not advertized this very long-living (and daily updated) web page is that it's really about *NON RELEASED* versions of R. Martin Maechler, ETH ZUrich On Wed, 21 Jul 2010, mark.braving...@csiro.au wrote: Hi The link from CRAN to new features in R-devel hasn't been working for a few days. Specifically, there is no NEWS file in https://svn.r-project.org/R/trunk/, though there is an ONEWS. The link is in the Source code for all platforms subwindow, where it says: Daily snapshots of current patched and development versions are available here. Please read about new features and bug fixes before filing corresponding feature requests or bug reports. Mark -- Mark Bravington CSIRO Mathematical Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ 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/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 __ 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 CMD build wiped my computer
Jarrod Hadfield j.hadfi...@ed.ac.uk on Tue, 27 Jul 2010 21:37:09 +0100 writes: Hi, I ran R (version 2.9.0) CMD build under root in Fedora (9). When it tried to remove junk files it removed EVERYTHING in my local account! (See below). Can anyone tell me what happened, the culprit may lay here: * removing junk files unlink MCMCglmm_2.05/R/ residuals.MCMCglmm.R ~ where it seems that someone (you?) have added a newline in the filname, so instead of 'residuals.MCMCglmm.R~' you got 'residuals.MCMCglmm.R ~' and the unlink / rm command interpreted '~' as your home directory. But I can hardly believe it. This seems explanation seems a bit doubtful to me.. ... and even more importantly if I can I restore what was lost. well, you just get it from the backup. You do daily backups, do you? Regards, Martin Maechler, ETH Zurich Panickingly, Jarrod [jar...@localhost AManal]$ R CMD build MCMCglmm_2.05 * checking for file 'MCMCglmm_2.05/DESCRIPTION' ... OK * preparing 'MCMCglmm_2.05': * checking DESCRIPTION meta-information ... OK * cleaning src * installing the package to re-build vignettes * Installing *source* package ?MCMCglmm? ... ** libs g++ -m64 -I/usr/include/R -I/usr/local/include-fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c MCMCglmm.cc -o MCMCglmm.o MCMCglmm.cc: In function ?void MCMCglmm(double*, double*, double*, int*, int*, int*, int*, int*, int*, double*, int*, int*, double*, int*, int*, double*, double*, int*, int*, int*, int*, int*, int*, int*, int*, int*, int*, double*, double*, double*, int*, int*, int*, int*, double*, double*, double*, int*, double*, bool*, double*, double*, int*, int*, int*, int*, int*, double*, int*, int*, int*, double*, double*, double*, int*, int*, double*, int*, int*, int*, int*, double*, double*, double*, double*)?: MCMCglmm.cc:228: warning: ?pvLS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?pvLL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Lrv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pmuL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?pvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?LambdaX? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?bv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?A? may be used uninitialized in this function MCMCglmm.cc:86: warning: ?dimG? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?AlphainvS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?AlphainvL? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation_tmp? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphalocation? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphazstar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphapred? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaastar? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?muAlpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Alphainv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tXalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Xalpha? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?linky_orig? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?tYKrinvYS? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?LambdaS? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?tYKrinvYL? may be used uninitialized in this function MCMCglmm.cc:227: warning: ?LambdaLU? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinvY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tYKrinv? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?ILY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?tY? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?Y? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?I? may be used uninitialized in this function MCMCglmm.cc:228: warning: ?alphaS? may be used uninitialized in this function MCMCglmm.cc:225: warning: ?alphaMME? may be used uninitialized
Re: [Rd] rbind on data.frame that contains a column that is also a data.frame
Heinz Tuechler tuech...@gmx.at
on Sat, 07 Aug 2010 01:01:24 +0100 writes:
Also Surv objects are matrices and they share the same problem when
rbind-ing data.frames.
If contained in a data.frame, Surv objects loose their class after
rbind and therefore do not more represent Surv objects afterwards.
Using rbind with Surv objects outside of data.frames shows a similar
problem, but not the same column names.
In conclusion, yes, matrices are common in data.frames, but not
without problems.
My understanding ( 20 yr long S and R experience) has been that
a dataframe definitely can have matrix-like components,
and as Bill Dunlap (with equal S R experience) has just
explained, that's actually more common than you have thought.
To have *data frame*s instead of simple matrices, should be much
less common, I'm not sure if it's a good idea.
But getting back to 'matrices',
I think they should work without problems, at least for basic
R operations such as rbind().
I don't have time to analyze the Surv - example below,
but at the moment think, that we'd be interested in
fixing the problems..
Martin Maechler, ETH Zurich
Heinz
## example
library(survival)
## create example data
starttime - rep(0,5)
stoptime - 1:5
event - c(1,0,1,1,1)
group - c(1,1,1,2,2)
## build Surv object
survobj - Surv(starttime, stoptime, event)
## build data.frame with Surv object
df.test - data.frame(survobj, group)
df.test
## rbind data.frames
rbind(df.test, df.test)
## rbind Surv objects
rbind(survobj, survobj)
At 06.08.2010 09:34 -0700, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Nicholas
L Crookston
Sent: Friday, August 06, 2010 8:35 AM
To: Michael Lachmann
Cc: r-devel-boun...@r-project.org; r-devel@r-project.org
Subject: Re: [Rd] rbind on data.frame that contains a column
that is also a data.frame
OK...I'll put in my 2 cents worth.
It seems to me that the problem is with this line:
b$a=a , where s is something other than a vector with
length equal to nrow(b).
I had no idea that a dataframe could hold a dataframe. It is not just
rbind(b,b) that fails, apply(b,1,sum) fails and so does plot(b). I'll
bet other R commands fail as well.
My point of view is that a dataframe is a list of vectors
of equal length and various types (this is not exactly what the help
page says, but it is what it suggests to me).
Hum, I wonder how much code is based on the idea that a
dataframe can hold
a dataframe.
I used to think that non-vectors in data.frames were
pretty rare things but when I started looking into
the details of the modelling code I discovered that
matrices in data.frames are common. E.g.,
library(splines)
sapply(model.frame(data=mtcars, mpg~ns(hp)+poly(disp,2)), class)
$mpg
[1] numeric
$`ns(hp)`
[1] ns basis matrix
$`poly(disp, 2)`
[1] poly matrix
You may not see these things because you don't call model.frame()
directly, but most modelling functions (e.g., lm() and glm())
do call it and use the grouping provided by the matrices to encode
how the columns of the design matrix are related to one another.
If matrices are allowed, shouldn't data.frames be allowed as well?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
15 years of using R just isn't enough! But, I can
say that not
one
line of code I've written expects a dataframe to hold a dataframe.
Hi,
The following was already a topic on r-help, but after
understanding
what is
going on, I think it fits better in r-devel.
The problem is this:
When a data.frame has another data.frame in it, rbind
doesn't work well.
Here is an example:
--
a=data.frame(x=1:10,y=1:10)
b=data.frame(z=1:10)
b$a=a
b
z a.x a.y
1 1 1 1
2 2 2 2
3 3 3 3
4 4 4 4
5 5 5 5
6 6 6 6
7 7 7 7
8 8 8 8
9 9 9 9
10 10 10 10
rbind(b,b)
Error in `row.names-.data.frame`(`*tmp*`, value = c(1,
2, 3, 4,
:
duplicate 'row.names' are not allowed
In addition: Warning message:
non-unique values when setting 'row.names': ?1?, ?10?, ?2?,
?3?, ?4?,
?5?,
?6?, ?7?, ?8?, ?9?
--
Looking at the code of rbind.data.frame, the error comes from the
lines:
--
xij - xi[[j]]
if (has.dim[jj]) {
value[[jj
Re: [Rd] R support for 64 bit integers
{Hijacking the thread from from R-help to R-devel -- as I am
consciously shifting the focus away from the original question
...
}
David Winsemius dwinsem...@comcast.net
on Tue, 10 Aug 2010 08:42:12 -0400 writes:
On Aug 9, 2010, at 2:45 PM, Theo Tannen wrote:
Are integers strictly a signed 32 bit number on R even if
I am running a 64 bit version of R on a x86_64 bit
machine?
I ask because I have integers stored in a hdf5 file where
some of the data is 64 bit integers. When I read that
into R using the hdf5 library it seems any integer
greater than 2**31 returns NA.
That's the limit. It's hard coded and not affected by the
memory pointer size.
Any solutions?
I have heard of packages that handle big numbers. A bit
of searching produces suggestions to look at gmp on CRAN
and Rmpfr on R-Forge.
Note that Rmpfr has been on CRAN, too, for a while now.
If you only need large integers (and rationals), 'gmp' is enough
though.
*However* note that the gmp or Rmpfr (or any other arbitray
precision) implementation will be considerably slower in usage
than if there was native 64-bit integer support.
Introducing 64-bit integers natively into base R is an
interesting project, notably if we also allowed using them for
indices, and changed the internal structures to use them instead
of 32-bit.
This would allow to free ourselves from the increasingly
relevant maximum-atomic-object-length = 2^31 problem.
The latter is something we have planned to address, possibly for
R 3.0.
However, for that, using 64-bit integers is just one
possibility, another being to use double precision integers.
Personally, I'd prefer the long long (64-bit) integers quite
a bit, but there are other considerations, e.g.,
one big challenge will be to go there in a way such that not
all R packages using compiled code will have to be patched
extensively...
another aspect is how the BLAS / Lapack team will address the
problem.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] save() object w/o all of the loaded environment
RL == Roebuck,Paul L proeb...@mdanderson.org on Tue, 24 Aug 2010 11:06:54 -0500 writes: RL I have two packages, one that does the actual work (SC) RL and the other a Tcl/Tk UI (SCUI) that invokes methods RL within the former. Within the SCUI's invocation method, RL I save an object returned from SC, the results of a RL long-running method. RL Now the object is completely described by the SC RL package. Unfortunately, any attempt to load the object RL (in a fresh R session) fails as below. R library(SC) setwd(/path/to/results/) R load(sc-results.rda) RL Loading Tcl/Tk interface ... done Error: .onLoad failed RL in loadNamespace() for 'SCUI', details: call: RL optiondb_add(*Notebook.borderWidth, 2, RL widgetDefault) error: could not find function tcl RL That call (which adds resource to Tcl resource database) RL is made inside SCUI. Loading tcltk package removes the RL problem. R library(tcltk) load(sc-results.rda) ls() RL [1] results RL But I would really prefer not to need to load tcltk at RL all just to inspect/use the object, which contains RL nothing from SCUI anyway. Is there a way to strip the RL unwanted UI prerequisite (tcltk and SCUI) packages from RL the environment of the object prior/during save()? Yes, there is: fortune(Yoda) Evelyn Hall: I would like to know how (if) I can extract some of the information from the summary of my nlme. Simon Blomberg: This is R. There is no if. Only how. -- Evelyn Hall and Simon 'Yoda' Blomberg R-help (April 2005) About the how: I'd make use of ls.str(the environment) to start inspecting the objects there. To help you further, we'd need more details, e.g. such str()-like results of the things you are talking about. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No [[-.factor()
WD == William Dunlap wdun...@tibco.com on Wed, 25 Aug 2010 17:31:27 -0700 writes: WD Should there be a [[-.factor() that either throws WD an error or acts like [-.factor() to avoid making WD an illegal object of class factor? Yes, one or the other. Note that both `[-` and `[[-` are Primitive and do some informal dispatch in addition to the formal method dispatch, so there's no need for an explicit '[[-.factor' method definition. For factors, it seems rational and expectable that double bracket behaves as single bracket when *one* element is assigned. z[[2:3]] - c(Two, Three) however should continue to give an error. Martin Maechler, ETH Zurich z - factor(c(Two,Two,Three), levels=c(One,Two,Three)) z WD [1] Two Two Three WD Levels: One Two Three str(z) WD Factor w/ 3 levels One,Two,Three: 2 2 3 z[[2]] - One str(z) # the .Data part is now character WD Factor w/ 3 levels One,Two,Three: 2 One 3 z WD [1] NA NA NA WD Levels: One Two Three z[2] - One WD Error in class(x) - cx : adding class factor to an invalid object WD Bill Dunlap WD Spotfire, TIBCO Software WD wdunlap tibco.com WD __ WD R-devel@r-project.org mailing list WD 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] RCMD CHECK and non-methods
mark.braving...@csiro.au
on Wed, 25 Aug 2010 14:06:07 +1000 writes:
I recently moved a function 'subset.with.warning' into the 'mvbutils'
package (a version not yet on CRAN). When I tried RCMD CHECK, I got this
warning:
* checking S3 generic/method consistency ... WARNING
subset:
function(x, ...)
subset.with.warning:
function(x, cond, mess.head, mess.cond, row.info, sub)
See section 'Generic functions and methods' of the 'Writing R Extensions'
manual.
I know that S3 method arguments need to be compatible with arguments of
the generic. However, 'subset.with.warning' is deliberately not a registered S3
method,
I think that's your real trouble ... and then your users' if you
really insist.
Short answer: Don't do that!
There have been a few exceptions of 100 years old R functions
which validated this rule,
the most notable probably t() and t.test(),
and we (R core) have explicitly listed them in the code base
as yes, looks like a method for an S3 generic, but not it ain't!,
but have basically forbidden to commit more such crimes.
{Also, if you are interested: I think both t() and t.test()
pre-dated S3}
and its USAGE section doesn't include a \method{generic}{class}
statement. I couldn't see anything in R Extensions that says don't do this,
so I'm wondering:
Yes, we should add a such don't do this somewhere.
Can you propose a good place to put it in there?
- should this really be a NOTE not a WARNING (or nothing at all)?
{from the above: definitely a warning, if not worse}
Best regards,
Martin
Martin Maechler, ETH Zurich
- if not, shouldn't there be a more explicit statement to the effect that
if R decides it's a method, then it damned well is a method, whether you think
it is or not?
- and if so, should there also be a check for functions that look like
methods but aren't registered and declared as such?
My preference would be for the first, FWIW. Admittedly, just because I
didn't register 'subset.with.warning' as an S3 method, that won't stop 'subset'
from trying to use it if it ever encounters an object of class with.warning.
It's a risk that I'm happy to take, though CRAN might not be...
I made the warning go away by adding a '...' argument to the end of
'subset.with.warning', but that's not pretty.
Mark Bravington
CSIRO
Hobart
Australia
sessionInfo()
R version 2.11.1 Patched (2010-06-30 r52418)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] grDevices tools tcltk stats graphics utils methods
base
other attached packages:
[1] ad_1.0 chstuff_1.0handy2_1.2 tweedie_2.0.2
statmod_1.4.1 handy_1.1 debug_1.2.3mvbutils_2.5.2
__
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] No [[-.factor()
Prof Brian Ripley rip...@stats.ox.ac.uk on Mon, 30 Aug 2010 08:28:24 +0100 (BST) writes: On Thu, 26 Aug 2010, Martin Maechler wrote: WD == William Dunlap wdun...@tibco.com on Wed, 25 Aug 2010 17:31:27 -0700 writes: WD Should there be a [[-.factor() that either throws WD an error or acts like [-.factor() to avoid making WD an illegal object of class factor? Yes, one or the other. Note that both `[-` and `[[-` are Primitive and do some informal dispatch in addition to the formal method dispatch, I don't think so. do_subassign2 does formal method dispatch, albeit internally, but nothing else (do_assign2_dflt selects only by typeof()). One consider that as an informal dispatch, notably distinguishing lists and atomics... so there's no need for an explicit '[[-.factor' method definition. For factors, it seems rational and expectable that double bracket behaves as single bracket when *one* element is assigned. z[[2:3]] - c(Two, Three) however should continue to give an error. I added a [[-.factor yesterday. Note that we do have a [-.factor which works on the integer codes, and I simply copied its logic. thank you! BTW, you probably meant z[[2:3]] - c(Two, Three) yes, indeed! Martin z - factor(c(Two,Two,Three), levels=c(One,Two,Three)) z WD [1] Two Two Three WD Levels: One Two Three str(z) WD Factor w/ 3 levels One,Two,Three: 2 2 3 z[[2]] - One str(z) # the .Data part is now character WD Factor w/ 3 levels One,Two,Three: 2 One 3 z WD [1] NA NA NA WD Levels: One Two Three z[2] - One WD Error in class(x) - cx : adding class factor to an invalid object WD Bill Dunlap WD Spotfire, TIBCO Software WD wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 Method Signatures
DS == Dario Strbenac d.strbe...@garvan.org.au
on Fri, 3 Sep 2010 12:00:14 +1000 (EST) writes:
DS Hello,
DS If the signature of a method defines which generic it implements then
I'm confused about why this minimal example I invented won't work :
very short answer:
if(FALSE) { 0 == 1 }
slightly longer:
if( something_wrong ) { anything_can_be_put_here }
In other words:
Your assumption is wrong.
There's only one generic and potentially many methods, defined
via signatures, but you have not understood what a signature is.
DS setGeneric(myFun, function(rs, ...){standardGeneric(myFun)})
DS setGeneric(myFun, function(cs, ...){standardGeneric(myFun)})
DS setMethod(myFun, numeric, function(rs, colour = Blue)
DS {
DS cat(rs*100, colour)
DS })
DS setMethod(myFun, character, function(cs, colour = Red)
DS {
DS cat(cs, colour)
DS })
Rather:
setGeneric(myFun, function(x, ...) standardGeneric(myFun))
setMethod(myFun, numeric,
function(x, colour = Blue) cat(xs*100, colour))
## etc
where the last is an abbreviated form of
setMethod(myFun, signature(x = numeric),
function(x, colour = Blue) cat(xs*100, colour))
which is abbreviated for
setMethod(myFun, signature = signature(x = numeric),
function(x, colour = Blue) cat(xs*100, colour))
I do wonder why the examples on the ?setMethod
help page where not sufficient here..
DS Thanks for any tips,
you're welcome.
Martin Maechler, ETH Zurich
DS --
DS Dario Strbenac
DS Research Assistant
DS Cancer Epigenetics
DS Garvan Institute of Medical Research
DS Darlinghurst NSW 2010
DS Australia
DS __
DS R-devel@r-project.org mailing list
DS https://stat.ethz.ch/mailman/listinfo/r-devel
DS == Dario Strbenac d.strbe...@garvan.org.au
on Fri, 3 Sep 2010 12:00:14 +1000 (EST) writes:
DS Hello, If the signature of a method defines which
DS generic it implements then I'm confused about why this
DS minimal example I invented won't work :
DS setGeneric(myFun, function(rs,
DS ...){standardGeneric(myFun)}) setGeneric(myFun,
DS function(cs, ...){standardGeneric(myFun)})
DS setMethod(myFun, numeric, function(rs, colour =
DS Blue) { cat(rs*100, colour) })
DS setMethod(myFun, character, function(cs, colour =
DS Red) { cat(cs, colour) })
DS Thanks for any tips, Dario.
DS -- Dario Strbenac
DS Research Assistant Cancer Epigenetics Garvan Institute
DS of Medical Research Darlinghurst NSW 2010 Australia
DS __
DS R-devel@r-project.org mailing list
DS 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] OT: Reason/history behind ## notation for comments?
LG == Laurent Gatto laurent.ga...@gmail.com on Wed, 22 Sep 2010 08:33:20 +0100 writes: LG For what concerns emacs users, the number of '#' has LG different effects on the position of the comment. From LG the ESS manual: 'By default, comments beginning with LG ‘###’ are aligned to the beginning of the line. Comments LG beginning with ‘##’ are aligned to the current level of LG indentation for the block containing the LG comment. Finally, comments beginning with ‘#’ are LG aligned to a column on the right...'. I guess that ## is LG the most wanted indentation for comments. Yes, that's all correct. (and Emacs+ESS being used quite a bit by some active R Core members, at least historically) One thing to add: As most of you probably know, R was built using ideas and concepts from Lisp (aka LISP), and (Emacs-)Lisp being emacs' extension language, Emacs has always supported auto-indenting/filling of comments---which in lisp start with a ; --- using different indentation rules for ;, ;;, ;;; So it seems quite apt for R to continue this Lisp convention. Given the Lisp decent, this tradition is probably quite an old one in (academic) programming history. Martin Maechler, ETH Zurich (and R Core) LG Best wishes, LG Laurent LG On 22 September 2010 07:26, Henrik Bengtsson LG h...@stat.berkeley.edu wrote: Off topic, but since I've observe both styles, does anyone know the history behind/reason for using ## instead of a single # to start comments in R. I know some editors do this by default. Is it because in C it is easier to distinguish (search/replace/...) comments from C preprocessor directives such as #include, and that's became a de facto standard elsewhere? /Henrik PS. I don't want to get into a debate on what's the best style. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ LG R-devel@r-project.org mailing list LG 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] Recursion error after upgrade to R_2.11.1 [Sec=Unclassified] [Sec=Unclassified]
TR == Troy Robertson troy.robert...@aad.gov.au
on Thu, 7 Oct 2010 13:50:49 +1100 writes:
On 10/06/2010 06:12 PM, Troy Robertson wrote:
Hi all,
After no replies to my previous message I thought I might show some
code to demonstrate the change and again seek any
explanation for the
error now thrown by my code after upgrading from 2.10.1 to 2.11.1.
Thanks
Troy
setClass(PortableObject,
representation(test1= character),
prototype( test1 = ),
contains = .environment
)
setMethod(initialize, PortableObject,
function(.Object, ..., .xData=new.env(parent=emptyenv())) {
.Object - callNextMethod(.Object, ...,
.xData=.xData)
.obj...@test1 - Foo
# Following line works under 2.10.1 but now throws
# Error: evaluation nested too deeply:
infinite recursion / options(expressions=)?
#.Object[[test2]] - Bar
# The following does what I want though
.Object$test3 - Baa
return(.Object)
}
)
e - new(PortableObject)
The explicit example does help -- it's clear what bug you are
encountering. Here's the code in R-2.10
selectMethod([[-, .environment)
Method Definition:
function (x, i, j, ..., value)
{
call - sys.call()
call[[2]] - x...@.data
eval.parent(call)
x
}
and 2.11.1
selectMethod([[-, .environment)
Method Definition:
function (x, i, j, ..., value)
{
.local - function (x, i, j, ..., exact = TRUE, value)
{
call - sys.call()
call[[2]] - x...@.data
eval.parent(call)
x
}
.local(x, i, j, ..., value = value)
}
Apparently the 'exact' argument has been added, and because
the method signature differs from the generic, a .local
function is created. That 'sys.call()' originally returned
the environment in which the generic was called, but now it
returns the environment in which .local is defined. And so
eval() keeps evaluating .local(). This I think is a bug.
TR Yes, afer the email from William Dunlop, I found this difference in the
methods between 2.10.1 and 2.11.1
TR I had a play and by adding my own method to overload [[- for my
PortableObject was able to reinstate the original functionality without the
recursive error.
TR setMethod([[-, PortableObject,
TR function (x, i, j, ..., value)
TR {
TR call - sys.call()
TR call[[2]] - x...@.data
TR eval.parent(call)
TR x
TR }
TR )
For what it's worth, if I were interested in minimizing
copying I would set up initialize so that it ended with
callNextMethod(...), on the hopes that the method
eventually called would take care not to make too many copies
on slot assignment.
Martin
TR Hmmm, not sure what you mean here? My code passes objects such as
these as parameters to other S4 classes which alter their data. If the .xData
slot is used then I have no need to return the object. No copy-on-change is
performed but data held by the PortableObject is modified. This speeds up my
execution time by a LARGE amount.
TR I could very well have things all arse-about, having come from a Java
OO background, but this is the only way I have been able to create a
pass-by-reference paradigm using S4 classes. Any suggestions for alternative
solutions would be greatfully received.
TR Troy
R 2.12.2 (currently beta) has in its NEWS :
o A facility for defining reference-based S4 classes (in the OOP
style of Java, C++, etc.) has been added experimentally to
package methods; see ?ReferenceClasses.
--- Please get R-2.12.2 beta and tell here about your
experiences. John Chambers (you have in CC) will be particularly
interested in your feedback.
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] new.env does not recognize parents from subclassesof environment
2010/10/23 Uwe Ligges lig...@statistik.tu-dortmund.de:
On 23.10.2010 17:08, Uwe Ligges wrote:
Looks like those ETH pages were nnot updated after the R-2.12.0 release
(they do not show current R-tached / R-devel), hence CCing Martin
Maechler.
... which I actually do now...
Hmm, but why?
The daily snapshot page *does* show the current R-patched and R-devel
tar balls ?
Or what were you talking about ?
Regards,
Martin
Uwe
Best,
Uwe Ligges
On 22.10.2010 21:54, Vitally S. wrote:
John Chambersj...@stanford.edu writes:
You need to update your version of R (r-devel or 2.12 patched) to rev
53385 or later, and read NEWS, particularly the line:
- Assignment of an environment to functions or as an attribute to other
objects now works for subclasses of environment.
I am following the news in daily snapshots from here
ftp://ftp.stat.math.ethz.ch/Software/R
and the above line is still not in the NEWS of today's version.
Thanks for the patch. Looking forward to the stable release.
Vitally.
On 10/22/10 10:20 AM, Vitally S. wrote:
Yet another inconsistency. environment- does not work with S4:
setClass(myenv, contains = environment)
[1] myenv
env- new(myenv)
tf- function(x){x}
environment(tf)- env
Error in environment(tf)- env :
replacement object is not an environment
Vitally.
John Chambersj...@stanford.edu writes:
This is a problem related to the introduction of exact= into the [[
and [[- functions. As Bill says, the
current
method misuses eval.parent() when that argument is added.
However, a simpler and more efficient solution is to migrate the
checks for subclasses of environment used in
other base code into the code for [[- (and for $-), at which
point the methods for these functions are no
longer
needed.
A solution on these lines is being tested now and will find its way
into r-devel and 2.12 patched.
One other point about the original posting:
Please don't use constructions like e...@.xdata. This depends on the
current implementation and is not part of
the
user-level definition. Use as(env, environment) or equivalent.
(In this case, the assignment of the object's
own
environment was irrelevant to the error.)
John Chambers
On 10/21/10 9:21 AM, William Dunlap wrote:
The traceback looks very similar to a problem
in R 2.11.1 reported earlier this month by Troy Robertson.
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Troy Robertson
Sent: Wednesday, October 06, 2010 6:13 PM
To: 'r-devel@R-project.org'
Subject: Re: [Rd] Recursion error after upgrade to
R_2.11.1[Sec=Unclassified]
It was due to a miscount of how many frames to go
up before evaluating an expression in
getMethod([[-,.environment) because setMethod()
introduced a local function in the new method.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Vitally S.
Sent: Thursday, October 21, 2010 9:00 AM
To: John Chambers
Cc: r-devel@r-project.org
Subject: Re: [Rd] new.env does not recognize parents from
subclassesof environment
Here is an infinite recursion error which occurs only with S4
subclasses assignment.
setClass(myenv, contains = environment)
#[1] myenv
env- new(myenv)
env[[.me]]- ∑
#Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
With basic types it works as expected:
env1- new.env()
env1[[.me]]- env1
May be this is related to active bindings that you mentioned,
but I am still
reporting it here.
Vitally.
Thanks for the report. Should now be fixed in r-devel and
2.12 patched (rev 53383).
Please do report any cases where a subclass of environment
doesn't work. There are some known cases in locking and
active binding, that will be fixed in due course.
The workaround for any such problem is usually as.environment().
On 10/20/10 3:17 AM, Vitaly S. wrote:
Dear Developers,
A lot has been changed in the R12.0 with respect to
behavior of environment
subclasses. Many thanks for that.
One small irregularity, though; new.env does not allow the
parent to be from S4
subclass.
setClass(myenv, contains=environment)
[1] myenv
new.env(parent=new(myenv))
Error in new.env(parent = new(myenv)) : 'enclos' must be
an environment
I wonder if this is a planed behavior.
The use of .xData slot obviously works:
new.env(parent=new(myenv)@.xData)
environment: 063bb9e8
Thanks,
Vitaly.
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] new.env does not recognize parents from subclassesof environment
On Sat, Oct 23, 2010 at 18:23, Peter Dalgaard pda...@gmail.com wrote: On 10/23/2010 05:27 PM, Uwe Ligges wrote: On 23.10.2010 17:25, Martin Maechler wrote: 2010/10/23 Uwe Liggeslig...@statistik.tu-dortmund.de: On 23.10.2010 17:08, Uwe Ligges wrote: Looks like those ETH pages were nnot updated after the R-2.12.0 release (they do not show current R-tached / R-devel), hence CCing Martin Maechler. ... which I actually do now... Hmm, but why? The daily snapshot page *does* show the current R-patched and R-devel tar balls ? Or what were you talking about ? We are talking about the http://stat.ethz.ch/R-manual/ Thank you Uwe. The other e-mail cited John mentioning the ./Software/ page. Indeed those are outdated. and for about 6 weeks. The reason has been ssh host keys changed, disabling a cron job to run the updates... I hope this will be ok, within a couple of hours. page. R-devel NEWS show R-2.12.0, just as on example. Uwe You need to get NEWS from $BUILDDIR these days. Anything left in $SRCDIR is probably a relic. Yes, of course, but that has not been the problem here. Thank you Peter (and Uwe) Martin -- Peter Dalgaard Center for Statistics, Copenhagen Business School Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation of option 'help.ports' not in help(options)
Henrik Bengtsson h...@stat.berkeley.edu on Wed, 27 Oct 2010 12:54:15 -0700 writes: FYI, the option 'help.ports' is not document under help(options). Should it? yes, for completeness' sake; I've added it besides the other help.foobar options. It is documented under help(startDynamicHelp, package=tools). This is for for R v2.13.0dev and Rv2.12.0. Thank you, Henrik, for the notice. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 package warning
Robin Hankin rk...@cam.ac.uk
on Wed, 10 Nov 2010 09:53:30 + writes:
Hello everyone. R-2.12.0, suse linux 11.3.
I am debugging a package that uses S4 methods
and R CMD check gives the following warning:
Warning in methods::findMethods(g, env) :
non-generic function 'mdm' given to findMethods()
See the information on DESCRIPTION files in the chapter 'Creating R
packages' of the 'Writing R Extensions' manual.
I don't see anything obvious in that part of the R-exts but
FWIW, here is my DESCRIPTION file:
Package: multivator
Type: Package
Title: A multivariate emulator
Version: 1.0-1
Depends: R(= 2.10.0), emulator, methods, utils
Date: 2009-10-27
Author: Robin K. S. Hankin
Maintainer: hankin.robin_nospamAT_gmail.com
Description: A multivariate generalization of the emulator package
License: GPL-2
LazyLoad: yes
I think that the lines in question in my package are:
setClass(mdm, # mdm == multivariate design matrix
representation = representation(
xold = matrix,
types = factor
)
)
setGeneric(mdm,function(xold,types){standardGeneric(mdm)})
setMethod(mdm,signature(matrix,factor),function(xold, types){
new(mdm, xold=xold, types=types)
} )
which appear to execute without warning on a virgin console. In the
package, there are three
or four other S4 classes which are on the same footing as the mdm class,
but do not appear to generate a warning from R CMD check.
The same happens AFAICS on R-2.13, 53543
Can anyone advise on how to deal with the warning?
It is probably simply the *order* of your R/*.R files which matters:
The setGeneric() has to come before all its setMethod()s.
A maintenance-intensive solution to the problem is to use a
'Collate:' field in your DESCRIPTION.
A much simpler approach is what we've done in the Matrix
package: use R/AllClasses.R and R/AllGenerics.R
to put all setClass(.) and all setGeneric(.) calls,
respectively.
(and ensure not to use other file names that collate *before*
'All*' in some locales).
Martin
thank you
Robin
--
Robin K. S. Hankin
Uncertainty Analyst
University of Cambridge
19 Silver Street
Cambridge CB3 9EP
01223-764877
__
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] package matrix dummy.cpp
Prof Brian Ripley rip...@stats.ox.ac.uk on Sun, 28 Nov 2010 16:00:53 + (GMT) writes: It is Matrix, not matrix indeed! I too have corresponded with them about this. It seems to be a legacy from when the package contained C++ code, and can now be deleted. yes. Though, as Brian mentions below it's strange that you can't compile the package (how?) with the file present. I'd guess that this would mean you cannot (easily) install any CRAN packages that use C++ ? I think this will preclude you from using very fine R extensions! On Sun, 28 Nov 2010, Ambrus Kaposi wrote: Hi, The recommended package matrix contains an empty file src/dummy.cpp which results in using g++ instead of gcc to link Matrix.so. What is the reason for that? Is there any difference between using g++ or gcc? (There are no other cpp files in the source) I asked the maintainers of the package (matrix-auth...@r-project.org) 3 weeks ago but haven't received any answer. I apologize for that. Both Professor Doug Bates and I have been overloaded, and so this has slipped. On my system (NixOS Linux distribution, http://nixos.org) I can't compile package Matrix unless this file is deleted. Most likely you have not installed the C++ compiler (which is usually g++ on Linux) -- but you shouldn't need to in order to install R. Indeed, currently a C++ compiler for compiling/linking the R sources should not be needed just because of dummy.cpp in Matrix; and hence I've removed it for the next version of Matrix. However, as said above, I strongly believe your OS / R setup should be amended in such a way that you can also easily install packages with C++ code. Best regards, Martin Maechler, ETH Zurich Thank you very much, Ambrus Kaposi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RFC: sapply() limitation from vector to matrix, but not further
sapply() stems from S / S+ times and hence has a long tradition.
In spite of that I think that it should be enhanced...
As the subject mentions, sapply() produces a matrix in cases
where the list components of the lapply(.) results are of the
same length (and ...).
However, it unfortunately stops there.
E.g., if you *nest* two sapply() calls where the inner one
produces a matrix, very often the logical behavior would be for
the outer sapply() to stack these matrices into an array of
rank 3 [array rank(x) := length(dim(x))].
However it does not do that, e.g., an artifical example
p0 - function(...) paste(..., sep=)
myF - function(x,y) {
stopifnot(length(x) = 3)
x - rep(x, length.out=3)
ny - length(y)
r - outer(x,y)
dimnames(r) - list(p0(r,1:3), p0(C, seq_len(ny)))
r
}
and
(v - structure(10*(5:8), names=LETTERS[1:4]))
A B C D
50 60 70 80
if we let sapply() not simplify, we see the list of same size
matrices it produes:
sapply(v, myF, y = 2*(1:5), simplify=FALSE)
$A
C1 C2 C3 C4 C5
r1 100 200 300 400 500
r2 100 200 300 400 500
r3 100 200 300 400 500
$B
C1 C2 C3 C4 C5
r1 120 240 360 480 600
r2 120 240 360 480 600
r3 120 240 360 480 600
$C
C1 C2 C3 C4 C5
r1 140 280 420 560 700
r2 140 280 420 560 700
r3 140 280 420 560 700
$D
C1 C2 C3 C4 C5
r1 160 320 480 640 800
r2 160 320 480 640 800
r3 160 320 480 640 800
However, quite deceptively
sapply(v, myF, y = 2*(1:5))
A B C D
[1,] 100 120 140 160
[2,] 100 120 140 160
[3,] 100 120 140 160
[4,] 200 240 280 320
[5,] 200 240 280 320
[6,] 200 240 280 320
[7,] 300 360 420 480
[8,] 300 360 420 480
[9,] 300 360 420 480
[10,] 400 480 560 640
[11,] 400 480 560 640
[12,] 400 480 560 640
[13,] 500 600 700 800
[14,] 500 600 700 800
[15,] 500 600 700 800
My proposal -- implemented and make check tested --
is to add an optional argument 'ARRAY'
which allows
sapply(v, myF, y = 2*(1:5), ARRAY=TRUE)
, , A
C1 C2 C3 C4 C5
r1 100 200 300 400 500
r2 100 200 300 400 500
r3 100 200 300 400 500
, , B
C1 C2 C3 C4 C5
r1 120 240 360 480 600
r2 120 240 360 480 600
r3 120 240 360 480 600
, , C
C1 C2 C3 C4 C5
r1 140 280 420 560 700
r2 140 280 420 560 700
r3 140 280 420 560 700
, , D
C1 C2 C3 C4 C5
r1 160 320 480 640 800
r2 160 320 480 640 800
r3 160 320 480 640 800
---
In the best of all worlds, the default would be 'ARRAY = TRUE',
but of course, given the long-standing different behavior,
it seem much too risky, and my proposal includes remaining
back-compatible with default ARRAY = FALSE.
Martin Maechler,
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Rcpp-devel] GPL and R Community Policies (Rcpp)
Dominick Samperi djsamp...@gmail.com on Thu, 2 Dec 2010 03:27:58 -0500 writes: On Thu, Dec 2, 2010 at 2:51 AM, Gavin Simpson gavin.simp...@ucl.ac.ukwrote: On Wed, 2010-12-01 at 20:24 -0500, Dominick Samperi wrote: snip / Just to be clear I have never used the package and am not truly commenting on this particular case but only the general ideas in this thread. Also I was not suggesting that the comments in the code were purposefully misleading, only that they might be misleading since they could be interpreted in terms of contribution even though they are stated in terms of lines of code. The author of the phrase may very well have felt that the current team had done a lot of work to add design ideas and develop and promote the software but perhaps the unfortunate way in how it was expressed in that phrase that came out as a seeming comment on the original creator's contribution rather than the intended comment on their own, presumably also significant, contribution. There is no reason given why this should happen now, at this moment, and no explanation why the same standard should not be applied to other package authors, including other authors of Rcpp. Dominick, You feel you are the aggrieved party so of course you will find conspiracy in the timing. An equally plausible explanation is that the current set of developers on Rcpp intended to alter the contributions, to better reflect the current state of the package, some time ago but it slipped through the cracks. While we are in the housecleaning mood, perhaps the contributions can be reflected even better by removing all references to my name as I have suggested. You are predisposed to see the bad where non may exist. But also, you should be discussing this in private with the package developers. There is nothing in this thread of relevance to R-devel (other than to publicly refute your claims so as to balance the record should someone come across this in the archives) as this has nothing to do with developing R. There is no-one here who can speak for the R Community, because such a thing is not a concrete entity - you will just get the opinions of individuals. It is to the credit of this list (R-Devel) that this has not descended into a vitriolic stream of claim and counter claim. As for your claims about R Core, Doug has succinctly and clearly addressed your claims in that regard, regardless what you may personally believe. Rcpp is *not* an official product of the R Foundation, and neither is it part of the R distribution. Can we please take this elsewhere? Gavin. Yes, please. I think Dominick has received several suggestions and has got a few views from a tiny but not insignificant fraction of the R community. -- Thanks to all contributors ... and that should be *it*. Martin Maechler, ETH Zurich (Administrator of the R-devel mailing list) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0
Prof Brian Ripley rip...@stats.ox.ac.uk
on Tue, 7 Dec 2010 07:41:16 + (GMT) writes:
On Mon, 6 Dec 2010, Spencer Graves wrote:
Hello:
The example integrate(dnorm,0,2) says it fails on many systems.
I just got 0 from it, when I should have gotten either an error or
something
close to 0.5. I got this with R 2.12.0 under both Windows Vista_x64 and
Linux (Fedora 13); see the results from Windows below. I thought you
might
want to know.
Well, isn't that exactly what the help page says happens? That
example is part of a section entitled
## integrate can fail if misused
and is part of the illustration of
If the function is
approximately constant (in particular, zero) over nearly all its
range it is possible that the result and error estimate may be
seriously wrong.
yes, of course,
and the issue has been known for ``ages'' ..
..
..
but it seems that too many useRs are not reading the help
page carefully, but only browse it quickly.
I think we (R developers) have to live with this fact
and should consider adapting to it a bit more, particularly in
this case (see below)
Thanks for all your work in creating and maintaining R.
Best Wishes,
Spencer Graves
###
integrate(dnorm,0,2) ## fails on many systems
0 with absolute error 0
and this is particularly unsatisfactory for another reason:
absolute error 0
is *always* incorrect, so I think we should change *some*thing.
We could just use = (and probably should in any case, or
~= x which would convey ``is less than about x'' which I
think is all we can say),
but could consider giving a different message when the integral
evaluates to 0 or, rather actually,
only when the error bound ('abs.error') is 0 *and* 'subdivisions == 1'
as the latter indicates that the algorithm treated the integrand
f(.) as if f() was a linear function.
But in my quick experiments, even for linear (incl. constant)
functions, the 'abs.error' returned is never 0.
If we want to be cautious,
such a warning could be made explicitly suppressable by an argument
.warn.if.doubtful = TRUE
An additional possibility I'd like to try, is a new argument
'min.subdivisions = 3' which specifies the *minimal* number
of subdivisions to be used in addition to the already present
'subdivisions = 100' (= the maximum number of subintervals.)
Martin Maechler,
ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] minor problem in strsplit help file
PatB == Patrick Burns pbu...@pburns.seanet.com on Fri, 24 Dec 2010 10:27:23 + writes: PatB The 'extended' argument to 'strsplit' has been PatB removed, but it is still mentioned in the argument PatB items in the help file for 'fixed' and 'perl'. Indeed; thank you Pat! I've committed a fix. Martin PatB -- Patrick Burns pbu...@pburns.seanet.com twitter: PatB @portfolioprobe http://www.portfolioprobe.com/blog PatB http://www.burns-stat.com (home of 'Some hints for the PatB R beginner' and 'The R Inferno') __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: sapply() limitation from vector to matrix, but not further
Finally finding time to come back to this. Remember that I've started the thread by proposing a version of sapply() which does not just stop with making a matrix() from the lapply() result, but instead --- only when the new argument ARRAY = TRUE is set --- may return an array() of any (appropriate) order, in those cases where the lapply() result elements all return an array of the same dim(). On Wed, Dec 1, 2010 at 19:51, Hadley Wickham had...@rice.edu wrote: A downside of that approach is that lapply(X,...) can cause a lot of unneeded memory to be allocated (length(X) SEXP's). Those SEXP's would be tossed out by simplify() but the peak memory usage would remain high. sapply() can be written to avoid the intermediate list structure. But the upside is reusable code that can be used in multiple places - what about the simplification code used by mapply and tapply? Why are there three different implementations of simplification? Hadley I have now looked into using a version of what Hadley had proposed. Note (to Bill's point) that the current implementation of sapply() does go via lapply() and that we have vapply() as a faster version of sapply() with less copying (hopefully). Very unfortunately, vapply() .. which was only created 13 months ago, has inherited the ``illogical'' behavior of sapply() in that it does not make up higher rank arrays if the single element is already a matrix (say). ... Consequently, we also need a patch to vapply(), and I do wonder if we should not make ARRAY=TRUE the default there, since with vapply() you specify a result value, and if you specify a matrix, the total result should stack these matrices into an array of rank 3, etc. Looking at it, the patch is not so much work... notably if we don't use a new argument but really let FUN.VALUE determine what the result should look like. More comments are stil welcome... Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: sapply() limitation from vector to matrix, but not further
Gabor Grothendieck ggrothendi...@gmail.com on Mon, 27 Dec 2010 17:06:25 -0500 writes: On Wed, Dec 1, 2010 at 3:39 AM, Martin Maechler maech...@stat.math.ethz.ch wrote: My proposal -- implemented and make check tested -- is to add an optional argument 'ARRAY' which allows sapply(v, myF, y = 2*(1:5), ARRAY=TRUE) It would reduce the proliferation of arguments if the simplify= argument were extended to allow this, e.g. simplify = array or perhaps simplify = n would allow a maximum of n dimensions. That's a good idea, though it makes the implementation/documentation very slightly more complicated. I'm interested to get more feedback on my other questions, notably the only about *changing* vapply() (on the C-level) to behave logical in the sense of adding one dim(.)ension in those cases, the FUN.VALUE (result prototype) has a dim(). Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: sapply() limitation from vector to matrix, but not further
On Tue, Dec 28, 2010 at 19:14, Tony Plate tpl...@acm.org wrote:
The abind() function from the abind package is an alternative here -- it can
take a list argument, which makes it easy to use with the result of
lapply(). It's also able take direction about which dimension to join on.
x - list(a=1,b=2,c=3)
f - function(v) matrix(v, nrow=2, ncol=4)
sapply(x, f)
a b c
[1,] 1 2 3
[2,] 1 2 3
[3,] 1 2 3
[4,] 1 2 3
[5,] 1 2 3
[6,] 1 2 3
[7,] 1 2 3
[8,] 1 2 3
# The 'along=' argument to abind() determines on which dimension
# the list elements are joined. Use a fractional value to put the new
# dimension between existing ones.
dim(abind(lapply(x, f), along=0))
[1] 3 2 4
dim(abind(lapply(x, f), along=1.5))
[1] 2 3 4
dim(abind(lapply(x, f), along=3))
[1] 2 4 3
abind(lapply(x, f), along=3)
, , a
[,1] [,2] [,3] [,4]
[1,] 1 1 1 1
[2,] 1 1 1 1
, , b
[,1] [,2] [,3] [,4]
[1,] 2 2 2 2
[2,] 2 2 2 2
, , c
[,1] [,2] [,3] [,4]
[1,] 3 3 3 3
[2,] 3 3 3 3
Thank you, Tony.
Indeed, yes, abind() is nice here (and in the good ol' APL spirit !)
Wanting to keep things both simple *and* fast here, of course,
hence I currently contemplate the following code,
where the new simplify2array() is considerably simpler than abind():
##' Simplify a list of commonly structured components into an array.
##'
##' @title simplify list() to an array if the list elements are
structurally equal
##' @param x a list, typically resulting from lapply()
##' @param higher logical indicating if an array() of higher rank
##' should be returned when appropriate, namely when all elements of
##' \code{x} have the same \code{\link{dim}()}ension.
##' @return x itself, or an array if the simplification is sensible
simplify2array - function(x, higher = TRUE)
{
if(length(common.len - unique(unlist(lapply(x, length 1L)
return(x)
if(common.len == 1L)
unlist(x, recursive = FALSE)
else if(common.len 1L) {
n - length(x)
## make sure that array(*) will not call rep() {e.g. for 'call's}:
r - as.vector(unlist(x, recursive = FALSE))
if(higher length(c.dim - unique(lapply(x, dim))) == 1
is.numeric(c.dim - c.dim[[1L]])
prod(d - c(c.dim, n)) == length(r)) {
iN1 - is.null(n1 - dimnames(x[[1L]]))
n2 - names(x)
dnam -
if(!(iN1 is.null(n2)))
c(if(iN1) rep.int(list(n1), length(c.dim)) else n1,
list(n2)) ## else NULL
array(r, dim = d, dimnames = dnam)
} else if(prod(d - c(common.len, n)) == length(r))
array(r, dim = d,
dimnames= if(!(is.null(n1 - names(x[[1L]]))
is.null(n2 - names(x list(n1,n2))
else x
}
else x
}
sapply - function(X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
{
FUN - match.fun(FUN)
answer - lapply(X, FUN, ...)
if(USE.NAMES is.character(X) is.null(names(answer)))
names(answer) - X
if(!identical(simplify, FALSE) length(answer))
simplify2array(answer, higher = (simplify == array))
else answer
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] aperm() should retain class of input object
Michael Friendly frien...@yorku.ca
on Wed, 29 Dec 2010 08:33:07 -0500 writes:
On 12/28/2010 9:43 AM, Tim Hesterberg wrote:
Having aperm() return an object of the same class is dangerous, there
are undoubtedly classes for which that is not appropriate, producing an
illegal object for that class or quietly giving incorrect results.
OK. I can see that my initial proposal would be dangerous for xtabs
objects without further
modifications and that it is unwise to change default behavior in base
functions without
very strong reasons.
Three alternatives are to:
* add the keep.class option but with default FALSE
This first option is the minimally invasive corrective surgery.
This would put the burden on the user (or package writer), but at least
make it known
that keep.class=TRUE is an option. This version is
## add keep.class, non-generic
aperm - function (a, perm, resize = TRUE, keep.class=FALSE)
{
if (missing(perm))
perm - integer(0L)
result - .Internal(aperm(a, perm, resize))
if(keep.class) class(result) - class(a)
result
}
* make aperm a generic function
- without a keep.class argument
- with a ... argument
- methods for classes like table could have keep.class = TRUE
This would be much better, as long as an aperm.table method was added to
base, to complement table() itself,
and gives the desired behavior for table objects by default.
This version seems to be:
## make generic, with ...
aperm - function(a, ...)
UseMethod(aperm, ...)
use UseMethod(aperm)
instead and then all is fine
aperm.default - function (a, perm, resize = TRUE, ...)
{
if (missing(perm))
perm - integer(0L)
.Internal(aperm(a, perm, resize))
}
aperm.table - function(a, perm, resize=TRUE, keep.class=TRUE, ...)
{
result - aperm.default(a, perm, resize=resize)
if(keep.class) class(result) - class(a)
result
}
But it throws an error, maybe because I haven't redefined aperm as a
generic:
UCB - aperm(UCBAdmissions, c(2,1,3))
Error in aperm(UCBAdmissions, c(2, 1, 3)) :
'...' used in an incorrect context
.. well, because you've used extraneous ... in the S3 generic
definition (see above).
I'm really sympathetic with your proposal and would indeed
implement it (for R-devel aka R 2.13.0 to be)
unless someone has good arguments for something else.
{{well, my version *would* keep the 'perm = NULL' default for
both default and table methods.}}
Martin Maechler, ETH Zurich
The .table method does work as desired:
UCB - aperm.table(UCBAdmissions, c(2,1,3))
str(UCB)
table [1:2, 1:2, 1:6] 512 89 313 19 353 17 207 8 120 202 ...
- attr(*, dimnames)=List of 3
..$ Gender: chr [1:2] Male Female
..$ Admit : chr [1:2] Admitted Rejected
..$ Dept : chr [1:6] A B C D ...
* make aperm a generic function
- without a keep.class argument
- with a ... argument
- default method have keep.class = TRUE
The third option would give the proposed behavior by default, but
allow a way out for classes where the behavior is wrong. This puts
the burden on a class author to realize the potential problem with
aperm, so my preference is one of the first two options.
aperm() was designed for multidimensional arrays, but is also useful for
table objects, particularly
with the lattice, vcd and vcdExtra packages. But aperm() was designed
and implemented before other
related object classes were conceived, and I propose a small tune-up to
make it more generally useful.
The problem is that aperm() always returns an object of class 'array',
which causes problems for methods
designed for table objects. It also requires some package writers to
implement both .array and .table
methods for the same functionality, usually one in terms of the other.
Some examples of unexpected, and initially perplexing results (when only
methods for one class are implemented)
are shown below.
library(vcd)
pairs(UCBAdmissions, shade=TRUE)
UCB- aperm(UCBAdmissions, c(2, 1, 3))
# UCB is now an array, not a table
pairs(UCB, shade=TRUE)
There were 50 or more warnings (use warnings() to see the first 50)
# fix it, to get pairs.table
class(UCB)- table
pairs(UCB, shade=TRUE)
Of course, I can define a new function, tperm() that does what I think
should be the expected behavior:
# aperm, for table objects
tperm- function(a, perm, resize = TRUE) {
result- aperm(a, per, resize)
class(result)- class(a)
result
}
But I think it is more natural to include this functionality in aperm()
itself. Thus, I propose
Re: [Rd] RFC: sapply() limitation from vector to matrix, but not further
Martin Maechler maech...@stat.math.ethz.ch
on Tue, 28 Dec 2010 20:06:07 +0100 writes:
On Tue, Dec 28, 2010 at 19:14, Tony Plate tpl...@acm.org
wrote:
The abind() function from the abind package is an
alternative here -- it can take a list argument, which
makes it easy to use with the result of lapply(). It's
also able take direction about which dimension to join
on.
x - list(a=1,b=2,c=3) f - function(v) matrix(v,
nrow=2, ncol=4) sapply(x, f)
a b c [1,] 1 2 3 [2,] 1 2 3 [3,] 1 2 3 [4,] 1 2 3
[5,] 1 2 3 [6,] 1 2 3 [7,] 1 2 3 [8,] 1 2 3
# The 'along=' argument to abind() determines on which
dimension # the list elements are joined. Use a
fractional value to put the new # dimension between
existing ones.
dim(abind(lapply(x, f), along=0))
[1] 3 2 4
dim(abind(lapply(x, f), along=1.5))
[1] 2 3 4
dim(abind(lapply(x, f), along=3))
[1] 2 4 3
abind(lapply(x, f), along=3)
, , a
[,1] [,2] [,3] [,4] [1,] 1 1 1 1 [2,]
1 1 1 1
, , b
[,1] [,2] [,3] [,4] [1,] 2 2 2 2 [2,]
2 2 2 2
, , c
[,1] [,2] [,3] [,4] [1,] 3 3 3 3 [2,]
3 3 3 3
Thank you, Tony.
Indeed, yes, abind() is nice here (and in the good ol' APL
spirit !)
Wanting to keep things both simple *and* fast here, of
course, hence I currently contemplate the following code,
where the new simplify2array() is considerably simpler
than abind():
##' Simplify a list of commonly structured components into an array.
##'
##' @title simplify list() to an array if the list elements are
structurally equal
##' @param x a list, typically resulting from lapply()
##' @param higher logical indicating if an array() of higher rank
##' should be returned when appropriate, namely when all elements of
##' \code{x} have the same \code{\link{dim}()}ension.
##' @return x itself, or an array if the simplification is sensible
simplify2array - function(x, higher = TRUE)
{
if(length(common.len - unique(unlist(lapply(x, length 1L)
return(x)
if(common.len == 1L)
unlist(x, recursive = FALSE)
else if(common.len 1L) {
n - length(x)
## make sure that array(*) will not call rep() {e.g. for 'call's}:
r - as.vector(unlist(x, recursive = FALSE))
if(higher length(c.dim - unique(lapply(x, dim))) == 1
is.numeric(c.dim - c.dim[[1L]])
prod(d - c(c.dim, n)) == length(r)) {
iN1 - is.null(n1 - dimnames(x[[1L]]))
n2 - names(x)
dnam -
if(!(iN1 is.null(n2)))
c(if(iN1) rep.int(list(n1), length(c.dim)) else n1,
list(n2)) ## else NULL
array(r, dim = d, dimnames = dnam)
} else if(prod(d - c(common.len, n)) == length(r))
array(r, dim = d,
dimnames= if(!(is.null(n1 - names(x[[1L]]))
is.null(n2 - names(x list(n1,n2))
else x
}
else x
}
sapply - function(X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
{
FUN - match.fun(FUN)
answer - lapply(X, FUN, ...)
if(USE.NAMES is.character(X) is.null(names(answer)))
names(answer) - X
if(!identical(simplify, FALSE) length(answer))
simplify2array(answer, higher = (simplify == array))
else answer
}
As some may have noted, the above has been committed to R-devel
(r53886 | maechler | 2010-12-29 10:36:01 +0100)
with the extra
--
NOTE: vapply() and replicate() doing that *by default*
--
which means that I've deared to let vapply() and replicate()
behave logically (in the above sense) by default, i.e.
*not* back compatibly.
If you want to remain bug-compatible (:-),
for replicate() you can explicitly ask for 'simplify=TRUE'
instead of the new default simplify=array.
For vapply(), the extra work of implementing such a back/bug
compatibility option did not seem worth; in particular, as
vapply() is very new and not used in many places (on CRAN)
anyway.
The new replicate() default behavior has lead to two CRAN
packages ('emoa', 'plsRglm' whose authors I'll address privately)
to fail 'R CMD check'; inspection however shows that in both cases,
1) the check failure is from examples / test functions
2) the usage there being
t(replicate(N, foobar()))
where foobar() returns a 1D array instead of a vector, so one
way to fix the problem would be to change the above to
t(replicate(N, t(foobar(
So, in summary, the changed behavior of replicate() seems indeed
Re: [Rd] Minimum of an ordered factor
Thaler, Thorn, LAUSANNE, Applied Mathematics
thorn.tha...@rdls.nestle.com
on Wed, 5 Jan 2011 11:20:47 +0100 writes:
Hi everybody, Is there a particular reason, why this code
does not work as intended:
z - factor(LETTERS[1:3], ordered = TRUE)
u - 4:6
min(z[u 4])
Error in Summary.factor(2:3, na.rm = FALSE) :
min not meaningful for factors
I agree that min is indeed not meaningful for not ordered
factors, but it makes sense for ordered
factors. Especially since
z[3] z[2]
sort(z)
_ARE_ defined and work as expected.
I agree that it is natural then, to expect min(), max() and
range() to work as well.
Of course I can do something like
sort(z[u4])[1]
but this does not enhance readability of my code. Thus, I
overloaded Summary.ordered as follows:
Summary.ordered - function(..., na.rm) {
ok - switch(.Generic, max = , min = , range = TRUE,
FALSE)
if (!ok) {
warning(sprintf('%s' is not meaningful for ordered
factors, .Generic))
return(NA)
}
args - list(...)
level.list - lapply(args, levels)
level.set - Reduce(union, level.list)
if (!all(sapply(args, is.ordered)) ||
!all(sapply(level.list, identical, y = level.set))) {
stop(sprintf('%s' is only meaningful for ordered
factors if all arguments are ordered factors with the same
level sets,
.Generic))
}
codes - lapply(args, as.integer)
ind - do.call(.Generic, c(codes, na.rm = na.rm))
factor(level.set[ind], levels = level.set, ordered =
TRUE)
}
(the above is now even more garbled than it was already by your
use of HTML-ified e-mail ..)
But your code is fine, even nice, in most parts,
and I will add (most of) it (and some documentation) to R-devel
unless we get contradicting comments :
Any comments appreciated.
(still)
Thank you, Thorn!
With regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimum of an ordered factor
TTLAM == Thaler, Thorn, LAUSANNE, Applied Mathematics
thorn.tha...@rdls.nestle.com
on Thu, 6 Jan 2011 15:37:01 +0100 writes:
TTLAM Kurt Hornik writes
if (!all(sapply(args, is.ordered)) ||
!all(sapply(level.list, identical, y = level.set))) {
I think it would be better to use something like
ll - lapply(args, levels)
!all(sapply(ll, identical, ll[[1L]]))
[using union() is not quite right]
TTLAM Yes definitely. This line is in fact just a relic from a previous
idea I
TTLAM had.
I have now committed the amended proposal (rev 53925);
thank you for the feedbacks..
The general comment is that if we support this I don't see why we
should
not also support c.ordered (and in fact also c.factor) with the same
restrictions (identical level sequences for ordered and level sets for
factors). We already have Ops.factor and Ops.ordered using the same
principle afaic.
Yes, I think, too.
If we add c.ordered, we should be able to encapsulate the identity of
levels testing into this, and simply use
x - c(...)
and then call .Generic on the codes of x etc.
TTLAM Sounds reasonable. Ack.
Yes, adding c.factor() and c.ordered() seems reasonable in
principle.
However, S and R now have a more than 20 year old history of
silently coercing factors to there integer codes with c(),
that I'm not yet sure we can do this without breaking too much
code [[and I am pretty sure this topic has been discusses before]].
I think we should start discussing the issue in a new thread
with proper Subject explicitly mention c() or c.factor/c.ordered.
Martin
TTLAM BR Thorn
TTLAM __
TTLAM R-devel@r-project.org mailing list
TTLAM 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] Minimum of an ordered factor
Thaler,Thorn,LAUSANNE,Applied Mathematics thorn.tha...@rdls.nestle.com
on Fri, 7 Jan 2011 13:35:16 +0100 writes:
Martin Maechler writes
I have now committed the amended proposal (rev 53925);
thank you for the feedbacks..
I had a look at it and there is a typo:
stop(gettextf('%s' not defined for \difftime\ objects, .Generic),
domain = NA)
should rather be
stop(gettextf('%s' not defined for ordered factors, .Generic), domain
TM = NA)
aah.. blushshsh ! (and thanks).
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath indices: suggested addition to help file
Thank you, Claudia,
CB == Claudia Beleites cbelei...@units.it
on Thu, 20 Jan 2011 14:05:41 +0100 writes:
CB Dear all, I just stumbled over the fact that subsetting
CB by square bracket will only output the first given
CB index. I guess the rest is thrown away by the CADDR in
CB RenderSub (plotmath.c l. 1399). Maybe changing this
CB could be considered as low-priority desired (would be
CB nice if the output works for ?
I agree this is a ``missing feature'' and well worth wish list item.
CB However, I suggest to announce the fact that only the
CB first parameter is printed in plotmath.Rd.
CB E.g. in the table l. 72
CB \code{x[i]} \tab x subscript i; escape further indices (\code{x [i,
j]})\cr
How would get the equivalent of LaTeX x_{i_1, j_2} ?
Not by making it a string (that's not escape, I'd say),
but by something like
plot(0, axes=FALSE, main= expression(paste(x[i[1]],{}[j[2]])))
which works +-
but of course is unnecessarily ugly, compared to the desired
plot(0, axes=FALSE, main= expression( x[i[1], j[2]]))
Martin
CB Claudia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath indices: suggested addition to help file
PE == Peter Ehlers ehl...@ucalgary.ca
on Fri, 21 Jan 2011 06:17:20 -0800 writes:
PE On 2011-01-21 02:27, Martin Maechler wrote:
Thank you, Claudia,
CB == Claudia Beleitescbelei...@units.it on Thu,
20 Jan 2011 14:05:41 +0100 writes:
CB Dear all, I just stumbled over the fact that subsetting
CB by square bracket will only output the first given
CB index. I guess the rest is thrown away by the CADDR in
CB RenderSub (plotmath.c l. 1399). Maybe changing this
CB could be considered as low-priority desired (would be
CB nice if the output works for ?
I agree this is a ``missing feature'' and well worth wish
list item.
CB However, I suggest to announce the fact that only the
CB first parameter is printed in plotmath.Rd.
CB E.g. in the table l. 72 \code{x[i]} \tab x subscript i;
CB escape further indices (\code{x [i, j]})\cr
How would get the equivalent of LaTeX x_{i_1, j_2} ? Not
by making it a string (that's not escape, I'd say), but
by something like
plot(0, axes=FALSE, main=
expression(paste(x[i[1]],{}[j[2]])))
which works +- but of course is unnecessarily ugly,
compared to the desired
plot(0, axes=FALSE, main= expression( x[i[1], j[2]]))
PE I don't know if I've ever disagreed with Martin's advice but,
:-)
PE unless I'm missing something, Claudia wants something
PE done about the second index in x[i, j] while Martin is
PE talking about the case of cascading subscripts in
PE 'x_sub_i_sub_1' (as shown in his LaTeX expression).
Well, that was a misunderstanding.
I've use cascaded subscripts as an example of subscripts that
are themselves expressions, and so using a string,
as Claudia's suggestion (on R-devel!) was, is not enough.
Only afterwards, I saw the related thread on R-help,
which included the proposals you give here
PE Both situations are nicely handled with the 'list()' and '[]'
PE constructs in plotmath:
PE plot(0, axes=FALSE, main= expression( x[ list( i[1], j[2] ) ] ) )
PE To handle Claudia's wish, it might be desirable to have plotmath.c
PE automatically recognize such cases but I would consider that to
PE be (as Claudia says) in the 'nice if' category. Claudia's suggestion
PE for the help page could be handled by adding another example. Then
PE again, plotmath (not surprisingly) is like LaTeX in that, the more
PE you use it, the more you become familiar with the special constructs
PE needed to get the output you want. I still find myself scurrying to
PE ?plotmath and scanning the Syntax/Meaning table quite frequently.
okay.
Indeed, the following code snippet shows what I deem a summary
of the proposals seen.
Txt - function(y, exp) {
y - y/16 # to allow integer arguments on input
x0 - par(xaxp)[1]
text(y, exp, adj = 0, cex = 5)
text(y, deparse(substitute(exp)), adj = 1.1, cex=1.2)
}
plot(0, axes=FALSE,ann=FALSE, asp=1, type=n)
## These show no , between the two indices:
Txt( 0, expression(x[paste(i[1],j[2])]))
Txt( 2, expression(x[i[1]][j[2]])) ## -- clearly nicest
## This one does .. that's what Claudia wanted:
Txt(-3, expression(x[list(i[1],j[2])]))
## and this one uses extra space
Txt(-5, expression(x[list(~i[1],j[2])]))
g - seq(-1.6,1, .2)/4; abline(v=g+1, h=g, col=adjustcolor(1, .2))
Notably the distinction between (LaTeX)
x_{i,j} or x_{i_1, j_2}
and
x_{ij} or x_{i_1 i_2}
is something that the useR will want to be able to specify with
plotmath as well.
So Claudia's (and my) wish that x[i,j] (or x[i[1], j[2]] )
also work automatically in R's plotmath
would still have to say if we want the version with , or
without.
Martin
PE Peter Ehlers
Martin
CB Claudia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help with S4 objects: trying to use a link-glm as a class in an object definition
Paul Bailey pdbai...@umd.edu
on Thu, 27 Jan 2011 23:51:21 -0500 writes:
Hi, I'm trying to make a new S4 object with a slot for a
link-glm object. R doesn't like me have a slot of class
link-glm
class(make.link(probit))
[1] link-glm
setClass(a,representation(item=link-glm))
[1] a Warning message: undefined slot classes in
definition of a: item(class link-glm)
you need a
setOldClass(link-glm)
before the the setClass() above and then things work.
setOldClass(link-glm)
setClass(a,representation(item=link-glm))
[1] a
fa - function() { new(a,item=make.link(probit)) }
b - fa()
b
An object of class a
Slot item:
$linkfun
function (mu)
Martin Maechler, ETH Zurich
fa - function() {
+ new(a,item=make.link(probit)) + }
fa()
Error in validObject(.Object) : invalid class a object:
undefined class for slot item (link-glm)
# and a link-glm looks like a list to me, so I thought I
would tell R it is a list and see what happens
setClass(b,representation(item=list))
[1] b
fb - function() {
+ new(b,item=make.link(probit)) + }
fb()
Error in validObject(.Object) : invalid class b object:
invalid object for slot item in class b: got class
link-glm, should be or extend class list
Any advice?
Regards, Paul Bailey Ph.D. candidate Department of
Economics University of Maryland
## raw code #
setClass(a,representation(item=link-glm)) fa -
function() { new(a,item=make.link(probit)) } fa()
setClass(b,representation(item=list)) fb - function()
{ new(b,item=make.link(probit)) } fb()
###
__
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] patch dendrogram.R from stats [was: Re: dendrogram plot does not draw long labels ?]
Tobias Verbeke tobias.verb...@openanalytics.eu on Tue, 25 Jan 2011 21:27:41 +0100 writes: L.S. Please find below a patch for dendrogram.R (stats package) against revision r54107 which allows one to pass the xpd parameter as a component of the nodePar list (to be passed to plot.dendrogram). I hope I did not overlook anything. Thank you, Tobias. Note BTW, that on Linux I don't have your problems that the label is not drawn when it does not fit. For me, it just is clipped (to the figure region as you note), so chopped off but the part inside the figure box is well visible. I was searching a bit and did not find mentioned on ?par or ?clip that clipping happens device dependently, but I vaguely recall to have seen it stated.. However the patch is a good idea, anyway, and it will be in R 2.13.x.. Thanks again, Martin Maechler Best, Tobias 378a379 lab.xpd - Xtract(xpd, nPar, default = c(TRUE, TRUE), i) 391c392 text(X, Y, nodeText, xpd = TRUE, srt = srt, adj = adj, --- text(X, Y, nodeText, xpd = lab.xpd, srt = srt, adj = adj, 436c437 text(xBot, yBot + vln, nodeText, xpd = TRUE, --- text(xBot, yBot + vln, nodeText, xpd = lab.xpd, On 01/25/2011 04:34 PM, Karl Forner wrote: Hi Tobias and thank you for your reply, Using your insight I managed to work-around the issue (with some help) by increasing the mai option of par(). For example a mai with first coordinate (bottom) set to 5 allows to display ~ 42 letters. We tried to change the xpd value in the text() call that you mentioned, but it did not seem to fix the problem. But I think this is very annoying: the dendrogram plot is meant to be the common unique plotting for all clustering stuff and suddenly if your labels are just too long, nothing get displayed, without even a warning. I suppose that the margins should be dynamically set based on the max label text drawn length... The hclust plot seemed to handle very nicely these long labels, but I need to display colored labels and the only way I found is to use the plot.dendrogram for this. Best, Karl On Tue, Jan 25, 2011 at 12:17 PM, Tobias Verbeke tobias.verb...@openanalytics.eu mailto:tobias.verb...@openanalytics.eu wrote: Hi Karl, On 01/25/2011 11:27 AM, Karl Forner wrote: It seems that the plot function for dendrograms does not draw labels when they are too long. hc- hclust(dist(USArrests), ave) dend1- as.dendrogram(hc) dend2- cut(dend1, h=70) dd- dend2$lower[[1]] plot(dd) # first label is drawn attr(dd[[1]], label)- aa plot(dd) # first label is NOT drawn Is this expected ? Reading the code of stats:::plotNode, yes. Clipping to the figure region is hard-coded. You can see it is clipping to the figure region as follows: hc - hclust(dist(USArrests), ave) dend1 - as.dendrogram(hc) dend2 - cut(dend1, h=70) dd - dend2$lower[[1]] op - par(oma = c(8,4,4,2)+0.1, xpd = NA) plot(dd) # first label is drawn attr(dd[[1]], label) - abcdefghijklmnopqrstuvwxyz plot(dd) # first label is NOT drawn box(which = figure) par(op) Is it possible to force the drawing ? These are (from very quick reading -- not verified) the culprit lines in plotNode, I think: text(xBot, yBot + vln, nodeText, xpd = TRUE, # - clipping hard-coded cex = lab.cex, col = lab.col, font = lab.font) Best, Tobias __ 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] [.raster bug {was str() on raster objects fails ..}
Henrik Bengtsson h...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in `[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img - as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster - function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r - as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
Thank you, Henrik, for the bug report.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
On Wed, Feb 2, 2011 at 02:16, Paul Murrell p.murr...@auckland.ac.nz wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul Murrellp.murr...@auckland.ac.nz
wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in
`[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
The main motivation for non-standard behaviour here is to make sure that
a
subset of a raster object NEVER produces a vector (because the conversion
back to a raster object then produces a single-column raster and that may
be
a surprise). Thanks for making the code more standard and robust.
The r[i] case is still tricky. The following behaviour is quite
convenient
...
r[r == black]- white
... but the next behaviour is quite jarring (at least in terms of the
raster
image that results from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further non-standardness to
try
to ensure that the subset of a raster image always produces a sensible
image. A simple solution would be just to outlaw r[i] for raster objects
and force the user to write r[i, ] or r[, j], depending on what they
want.
FYI, I've tried out Martin's updated version at it seems like a
one-column raster matrix is now returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4);
r
[,1] [,2] [,3] [,4]
[1,] #202020 #606060 #9F9F9F #DFDFDF
[2,] #404040 #808080 #BFBFBF #FF
r[1:length(r)]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
[6,] #BFBFBF
[7,] #DFDFDF
[8,] #FF
... and the above is exactly the sort of thing that will fry your mind if
the image that you are subsetting is, for example, a photo.
Paul
I agree. But the r[i] case (not subassignment, but subsetting) case
has been in the code, and that's why I left it .. but changed it to
behave sensibly in the sense of compatible to matrix
... and with the consequence that r[1:length(r)] does not give an
error ... and in this sense behaves more regular.
Yet another alternative might be to only raise a warning and perhaps
return a (character) vector as that is very compatible to matrix
behavior.
BTW, you haven't mentioned the r[xy] indexing where xy is a
two-column matrix of indices.
There it's even more non-sense to return
r[1:5,drop=TRUE]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
Warning message:
In `[.raster`(r, 1:5, drop = TRUE) :
'drop' is always implicitly FALSE in '[.raster'
Also,
r[1:5]- white
r
[,1] [,2] [,3] [,4]
[1,] white white white #DFDFDF
[2,] white white #BFBFBF #FF
/Henrik
Paul
Thank you, Henrik, for the bug report.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
On Wed, Feb 2, 2011 at 23:30, Simon Urbanek simon.urba...@r-project.org wrote:
On Feb 1, 2011, at 8:16 PM, Paul Murrell wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul Murrellp.murr...@auckland.ac.nz
wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu
on Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain dimensions. For
example:
str(as.raster(0, nrow=1, ncol=100)) 'raster' chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in `[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster() is coded; when
subsetting as a vector, which str() relies on, [.raster()
still returns a matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5]
[1,] #0A0A0A #3D3D3D #707070 #A3A3A3 #D6D6D6
[2,] #141414 #474747 #7A7A7A #ADADAD #E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...);
}
Other suggestions?
The informal raster class is behaving ``illogical''
in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript out of bounds
When classes do behave in such a way, they definitely need their
own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is not at all
matrix-like and its help clearly says that subsetting should
work as for matrices.
A recent thread on R-help/R-devel has mentioned the fact that
[ methods for matrix-like methods need to use both nargs() and
missing() and that [.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20 years ago.
The main motivation for non-standard behaviour here is to make sure that a
subset of a raster object NEVER produces a vector (because the conversion
back to a raster object then produces a single-column raster and that may
be
a surprise). Thanks for making the code more standard and robust.
The r[i] case is still tricky. The following behaviour is quite convenient
...
r[r == black]- white
... but the next behaviour is quite jarring (at least in terms of the
raster
image that results from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further non-standardness to try
to ensure that the subset of a raster image always produces a sensible
image. A simple solution would be just to outlaw r[i] for raster objects
and force the user to write r[i, ] or r[, j], depending on what they want.
FYI, I've tried out Martin's updated version at it seems like a
one-column raster matrix is now returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4);
r
[,1] [,2] [,3] [,4]
[1,] #202020 #606060 #9F9F9F #DFDFDF
[2,] #404040 #808080 #BFBFBF #FF
r[1:length(r)]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
[6,] #BFBFBF
[7,] #DFDFDF
[8,] #FF
... and the above is exactly the sort of thing that will fry your mind if
the image that you are subsetting is, for example, a photo.
Why doesn't raster behave consistently like any matrix object? I would expect
simply
r[1:length(r)]
[1] #202020 #404040 #606060 #808080 #9F9F9F #BFBFBF #DFDFDF
[8] #FF
Where it's obvious what happened. I saw the comment about the vector but I'm
not sure I get it - why don't you want a vector? The raster is no different
than matrices - you still need to define the dimensions when going back
anyway, moreover what you get now is not consistent at all since there raster
never had that dimension anyway ...
Cheers,
Simon
I agree that this would be the most logical and notably least
surprising behavior,
which I find the most important argument
(I'm sorry my last message was cut off as it was sent accidentally
before being finished completely).
Martin
Paul
r[1:5,drop=TRUE]
[,1]
[1,] #202020
[2,] #404040
[3,] #606060
[4,] #808080
[5,] #9F9F9F
Warning message:
In `[.raster`(r, 1:5, drop = TRUE) :
'drop' is always implicitly FALSE in '[.raster'
Also,
r[1:5]- white
r
[,1] [,2] [,3] [,4]
[1,] white white white #DFDFDF
[2,] white white #BFBFBF #FF
/Henrik
Paul
Thank you, Henrik, for the bug report.
Martin
Re: [Rd] [.raster bug {was str() on raster objects fails ..}
Simon Urbanek simon.urba...@r-project.org
on Sun, 6 Feb 2011 20:53:01 -0500 writes:
On Feb 6, 2011, at 8:10 PM, Paul Murrell wrote:
Hi
On 3/02/2011 1:23 p.m., Simon Urbanek wrote:
On Feb 2, 2011, at 7:00 PM, Paul Murrell wrote:
Hi
Martin Maechler wrote:
On Wed, Feb 2, 2011 at 23:30, Simon
Urbaneksimon.urba...@r-project.org wrote:
On Feb 1, 2011, at 8:16 PM, Paul Murrell wrote:
Hi
On 2/02/2011 2:03 p.m., Henrik Bengtsson wrote:
On Tue, Feb 1, 2011 at 4:46 PM, Paul
Murrellp.murr...@auckland.ac.nz wrote:
Hi
On 1/02/2011 9:22 p.m., Martin Maechler wrote:
Henrik Bengtssonh...@biostat.ucsf.edu on
Mon, 31 Jan 2011 11:16:59 -0800 writes:
Hi, str() on raster objects fails for certain
dimensions. For example:
str(as.raster(0, nrow=1, ncol=100)) 'raster'
chr [1, 1:100]
#00 #00 #00 #00 ...
str(as.raster(0, nrow=1, ncol=101)) Error in
`[.raster`(object,
seq_len(max.len)) : subscript out of bounds
This seems to do with how str() and [.raster()
is coded; when subsetting as a vector, which
str() relies on, [.raster() still returns a
matrix-like object, e.g.
img- as.raster(1:25, max=25, nrow=5, ncol=5);
img[1:2]
[,1] [,2] [,3] [,4] [,5] [1,] #0A0A0A
#3D3D3D #707070 #A3A3A3 #D6D6D6 [2,]
#141414 #474747 #7A7A7A #ADADAD
#E0E0E0
compare with:
as.matrix(img)[1:2]
[1] #0A0A0A #3D3D3D
The easy but incomplete fix is to do:
str.raster- function(object, ...) {
str(as.matrix(object), ...); }
Other suggestions?
The informal raster class is behaving
``illogical'' in the following sense:
r- as.raster(0, nrow=1, ncol=11)
r[seq_along(r)]
Error in `[.raster`(r, seq_along(r)) : subscript
out of bounds
or, here equivalently,
r[1:length(r)]
Error in `[.raster`(r, 1:length(r)) : subscript
out of bounds
When classes do behave in such a way, they
definitely need their own str() method.
However, the bug really is in [.raster:
Currently, r[i] is equivalent to r[i,] which is
not at all matrix-like and its help clearly says
that subsetting should work as for matrices. A
recent thread on R-help/R-devel has mentioned the
fact that [ methods for matrix-like methods
need to use both nargs() and missing() and that
[.dataframe has been the example to follow
forever, IIRC already in S and S-plus as of 20
years ago.
The main motivation for non-standard behaviour
here is to make sure that a subset of a raster
object NEVER produces a vector (because the
conversion back to a raster object then produces a
single-column raster and that may be a
surprise). Thanks for making the code more
standard and robust.
The r[i] case is still tricky. The following
behaviour is quite convenient ...
r[r == black]- white
... but the next behaviour is quite jarring (at
least in terms of the raster image that results
from it) ...
r2- r[1:(nrow(r) + 1)]
So I think there is some justification for further
non-standardness to try to ensure that the subset
of a raster image always produces a sensible
image. A simple solution would be just to outlaw
r[i] for raster objects and force the user to
write r[i, ] or r[, j], depending on what they
want.
FYI, I've tried out Martin's updated version at it
seems like a one-column raster matrix is now
returned for r[i], e.g.
Yes, that's what I've been looking at ...
r- as.raster(1:8, max=8, nrow=2, ncol=4); r
[,1] [,2] [,3] [,4] [1,] #202020 #606060
#9F9F9F #DFDFDF [2,] #404040 #808080
#BFBFBF #FF
r[1:length(r)]
[,1] [1,] #202020 [2,] #404040 [3,] #606060
[4,] #808080 [5,] #9F9F9F [6,] #BFBFBF [7,]
#DFDFDF [8,] #FF
... and the above is exactly the sort of thing that
will fry your mind if the image that you are
subsetting is, for example, a photo.
Why doesn't raster behave consistently like any matrix
object?
I would expect simply
r[1:length(r)]
[1] #202020 #404040 #606060 #808080 #9F9F9F
#BFBFBF
#DFDFDF [8] #FF
Where it's obvious what happened. I saw the comment about
the
vector but I'm not sure I get it - why don't you want a
vector?
The raster is no different than matrices - you still need
to
define the dimensions when going back anyway, moreover
what you
get now is not consistent at all since there raster never
had
that dimension anyway ...
Cheers, Simon
I agree that this would be the most logical and
notably least surprising behavior, which I find the
most important
Re: [Rd] print(...,digits=2) behavior
to denormalization -- added for R 2.x.y
alpha - (r * 1e+30) / 10^(kp+30)
else
alpha - r / 10^kpower
## make sure that alpha is in [1,10)
if (10 - alpha eps) {
cat(.. scientific(.) correcting alpha=,format(alpha),
. x=, formatC(x,dig=2,w=1),RARE ! \n)
alpha - alpha/10
kpower- kpower + 1
}
## compute number of digits
a - alpha
nsig - digits
for (j in 1:nsig) {
if (abs(a - floor(a+0.5)) eps * a) {
nsig - j
break
}
a - a * 10
}
}
left - kpower + 1
c(sgn = sgn, kpower = kpower, nsig = nsig,
left = left, right = nsig - left,
sleft = sgn + max(1,left))
}
names.num - function(v, dig=2)
{
## Purpose: Add names to vector if it hasn't
## Author: Martin Maechler, Date: 16 Jul 97, 08:49
names(v) - formatC(v, w=1, dig=dig)
v
}
do.sci - function(v, nam.dig = 3, digits = getOption('digits'))
{
## Purpose: Call scientific(.) and do some more
## -
## Author: Martin Maechler, Date: 16 Jul 97, 17:03
## -- names.num(.) is from /u/maechler/R/Util.R ---
r - sapply(names.num(v, dig= nam.dig), scientific, digits=digits)
cbind(r, min = apply(r,1,min), max = apply(r,1,max))
}
and here some of the experimentation code:
-- Examples / Experiment, using scientific(),
the R function that does the same as 'scientific' in
Rsource/src/main/format.c
source(scientific.R)# for function definitions
##
scientific(pi)
scientific(pi,14)
scientific(pi,17)# 0 0 16
tens - names.num(10 ^ (-2:6))
do.sci(tens)
do.sci(3.1 * tens)
do.sci(pi * tens)
do.sci(pi * tens, dig = 12)
## v1 from /u/maechler/R/print-tests.R
if(!exists(v1)) v1 - 10^c(-4:0,2,4)
do.sci(v1)
## Ben's example (*, digits=2)
x2 - c(outer(c(-1,1), c(7.92, 7.921)))
x2 - c(x2, 10^c(-10,-3, -1:1, 3,10))
do.sci(x2, 4, digits = 2)
---
Now, I'm waiting for comments/suggestions ..
Martin__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] axTicks.Rd documentation bug
Ben Bolker bbol...@gmail.com on Fri, 04 Feb 2011 10:44:12 -0500 writes: ?axTicks says: usr: numeric vector of length four, defaulting to ‘par(usr)’ giving horizontal (‘x’) and vertical (‘y’) user coordinate limits. but this is not how the function is implemented -- in fact 'usr' should be a vector of length two corresponding to the appropriate elements of par(usr) [1:2 if side is 1 or 3, 3:4 if side is 2 or 4]. A patch for src/library/graphics/man/axTicks.Rd against the latest SVN is attached (I hope it makes it through). I also included an extended example of how to use axTicks without reference to an existing plot in the logarithmic axis case: it took me quite a bit of digging in documentation and source code to figure out how to do this for myself, so I think it would be useful to others ... Thanks a lot, Ben! I've also added the new example .. though slightly modified. Notably I'm a tiny bit disappointed ;-) that you were not aware of the existence of the extendrange() function ... Martin Maechler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] request for patch in drop1 (add.R)
Ben Bolker bbol...@gmail.com
on Wed, 23 Feb 2011 09:14:37 -0500 writes:
By changing three lines in drop1 from access based on $
to access based on standard accessor methods (terms() and
residuals()), it becomes *much* easier to extend drop1 to
work with other model types. The use of $ rather than
accessors in this context seems to be an oversight rather
than a design decision, but maybe someone knows better ...
In particular, if one makes these changes (which I am
pretty certain will not break anything, as the original
code basically mimicked the default methods anyway), it
becomes possible to make drop1() work with mer objects
(Doug Bates's new mixed model code) merely by defining:
terms.mer - function(x, ...) {
attr(x@frame,terms)
}
extractAIC.default - function(fit, scale=0, k=2, ...) {
L - logLik(fit)
edf - attr(L,df)
c(edf,-2*L+2*edf)
}
Adding this definition of extractAIC.default also makes drop1() work
with lme fits ...
Comments? Should I submit to the bug database as enhancement
request? Are there any hidden downsides to this?
drawback: a possible very small performance cut for the cases
where the $ access is ok. But that should not count.
I like the idea {it's a pity that only S3 methods work that way,
because residuals(), terms(), etc... are unfortunately not
general (implicit) S4 generics but just S3 ones..
I'm currently testing your change, plus some more in step().
However, for step() to work automagically there is more needed.
It currently relies in more places on 'object' being a list to
which you can append new components, basically by
fit - object
fit$new1 - ...
fit$new2 - ...
That would have to be changed to something like
fit - list(obj = object)
fit$new1 - ...
fit$new2 - ...
and more changes where 'fit' has to be replaced by 'fit$obj'.
Would that not be of interest as well?
Martin
Ben Bolker
--
Index: add.R
===
--- add.R (revision 54562)
+++ add.R (working copy)
@@ -330,7 +330,7 @@
drop1.default - function(object, scope, scale = 0, test=c(none,
Chisq),
k = 2, trace = FALSE, ...)
{
-tl - attr(object$terms, term.labels)
+tl - attr(terms(object), term.labels)
if(missing(scope)) scope - drop.scope(object)
else {
if(!is.character(scope))
@@ -344,7 +344,7 @@
ans - matrix(nrow = ns + 1L, ncol = 2L,
dimnames = list(c(none, scope), c(df, AIC)))
ans[1, ] - extractAIC(object, scale, k = k, ...)
-n0 - length(object$residuals)
+n0 - length(residuals(object))
env - environment(formula(object))
for(i in seq(ns)) {
tt - scope[i]
@@ -356,7 +356,7 @@
evaluate = FALSE)
nfit - eval(nfit, envir=env) # was eval.parent(nfit)
ans[i+1, ] - extractAIC(nfit, scale, k = k, ...)
-if(length(nfit$residuals) != n0)
+if(length(residuals(nfit)) != n0)
stop(number of rows in use has changed: remove missing values?)
}
dfs - ans[1L , 1L] - ans[, 1L]
--
__
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] request for patch in drop1 (add.R)
Ben Bolker bbol...@gmail.com
on Wed, 23 Feb 2011 19:36:43 -0500 writes:
On 11-02-23 06:12 PM, Prof Brian Ripley wrote:
residuals() and $residuals are often very different:
residuals() is generic, but even the default method is *not*
simple extraction. Their values can be of different lengths:
think about an lm fit with na.action = na.exclude. That is
precisely the sort of thing the tests in add.R were designed to
detect, hence the use of $residuals.
None of this is used in drop1()! One of the places $residuals
was used in that file was the default method for drop1(),
others being step() and the default method for add1(). As
default methods these have to continue to work for any class of
object that has previously been thrown at them over the last
10+ years, and even all CRAN packages will not be a good enough
test suite.
In any case, the current code in R-devel makes use of the new
generic nobs(), which is intended to help sort out the many
versions of functions called 'BIC in packages, but is also
useful here. (It is still under development.)
terms() is also generic so there is also some danger that its
substitution could give an inappropriate result. But as it
used in several other places in add.R the breakage will
probably occur elsewhere already.
:-) yes. I think it is very good change to have drop1.default() and
other R functions that do generic model analysis work
via calls to simpler generic functions such as residuals(), or
the new nobs() . Thanks for introducing that, a really good
idea I think (and along which I think I was also musing when I
last looked at the BIC() implementations..).
I'm glad you've started to clean this up nicely.
Thanks Prof. Ripley. (I will say that, while I understand why
residuals(x) and x$residuals could be different, I am happy that
a more transparent form of coding is being introduced ...)
(indeed, see above).
Advertising the use of nobs(), i.e. asking package authors to
write nobs() methods for their models will be probably worth
doing, as soon as 2.13.0 hits the roads..
Martin
On Wed, 23 Feb 2011, Martin Maechler wrote:
Ben Bolker bbol...@gmail.com
on Wed, 23 Feb 2011 09:14:37 -0500 writes:
By changing three lines in drop1 from access based on $
to access based on standard accessor methods (terms() and
residuals()), it becomes *much* easier to extend drop1 to
work with other model types. The use of $ rather than
accessors in this context seems to be an oversight rather
than a design decision, but maybe someone knows better ...
In particular, if one makes these changes (which I am
pretty certain will not break anything, as the original
code basically mimicked the default methods anyway), it
becomes possible to make drop1() work with mer objects
(Doug Bates's new mixed model code) merely by defining:
terms.mer - function(x, ...) {
attr(x@frame,terms)
}
extractAIC.default - function(fit, scale=0, k=2, ...) {
L - logLik(fit)
edf - attr(L,df)
c(edf,-2*L+2*edf)
}
Adding this definition of extractAIC.default also makes
drop1() work with lme fits ...
Comments? Should I submit to the bug database as
enhancement request? Are there any hidden downsides to
this?
drawback: a possible very small performance cut for the cases
where the $ access is ok. But that should not count.
I like the idea {it's a pity that only S3 methods work
that way, because residuals(), terms(), etc... are
unfortunately not general (implicit) S4 generics but just S3
ones..
I'm currently testing your change, plus some more in step().
However, for step() to work automagically there is more
needed. It currently relies in more places on 'object' being
a list to which you can append new components, basically by
fit - object fit$new1 - ... fit$new2 - ...
That would have to be changed to something like fit -
list(obj = object) fit$new1 - ... fit$new2 - ... and more
changes where 'fit' has to be replaced by 'fit$obj'. Would
that not be of interest as well?
Martin
Ben Bolker
--
Index: add.R
===
--- add.R (revision 54562) +++ add.R (working copy) @@
-330,7 +330,7 @@ drop1.default - function(object, scope,
scale = 0,
test=c(none, Chisq),
k = 2, trace = FALSE, ...) { - tl - attr(object$terms,
term.labels) + tl - attr(terms(object), term.labels)
if(missing(scope)) scope - drop.scope(object) else
Re: [Rd] Standardized Pearson residuals
peter dalgaard pda...@gmail.com
on Thu, 17 Mar 2011 15:45:01 +0100 writes:
On Mar 16, 2011, at 23:34 , John Maindonald wrote:
One can easily test for the binary case and not give the
statistic in that case.
Warning if expected cell counts 5 would be another
possibility.
A general point is that if one gave no output that was not open
to abuse, there'd be nothing given at all! One would not be
giving any output at all from poisson or binomial models, given
that data that really calls for quasi links (or a glmm with
observation level random effects) is in my experience the rule
rather than the exception!
Hmmm. Not sure I agree on that entirely, but that's a different
discussion.
At the very least, why not a function dispersion() or
pearsonchisquare() that gives this information.
Lots of options here Offhand, my preference would go to
something like anova(..., test=score) and/or an extra line in
summary(). It's not a computationally intensive item as far as I
can see, it's more about output real estate -- how SAS-like
do we want to become?
Apologies that I misattributed this.
Never mind...
Back to the original question:
The current rstandard() code reads
## FIXME ! -- make sure we are following the literature:
rstandard.glm - function(model, infl = lm.influence(model, do.coef=FALSE), ...)
{
res - infl$wt.res # = dev.res really
res - res / sqrt(summary(model)$dispersion * (1 - infl$hat))
res[is.infinite(res)] - NaN
res
}
which is svn blame to ripley but that is due to the 2003
code reorganization (except for the infinity check from
2005). So apparently, we have had that FIXME since
forever... and finding its author appears to be awkward
(Maechler, perhaps?).
yes, almost surely
I did try Bretts code in lieu of the above (with a mod to
handle $dispersion) and even switched the default to use
the Pearson residuals. Make check-devel sailed straight
through apart from the obvious code/doc mismatch, so we
don't have any checks in place nor any examples using
rstandard(). I rather strongly suspect that there aren't
many user codes using it either.
It is quite tempting simply to commit the change (after
updating the docs). One thing holding me back though: I
don't know what the literature refers to.
well, the relevant publications on the topic ...
and now define that (e.g. using the three 'References' on the
help page).
Really, that's what I think I meant when I (think I) wrote that FIXME.
The point then I think was that we had code donations, and they
partly were clearly providing functionality that was (tested)
correct (according to e.g. McCoullagh Nelder and probably
another one or two text books I would have consulted ... no
large Wikipedia back then),
but also provided things for which there was nothing in the
literature, but as the author provided them with other good
code, we would have put it in, as well
== my vague recollection from the past
Martin
--
Peter Dalgaard Center for Statistics, Copenhagen Business
School Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501 Email: pd@cbs.dk Priv:
pda...@gmail.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] texi2dvi / egrep issue shows (a.o.) up in R-alpha
Tobias Verbeke tobias.verb...@openanalytics.eu on Mon, 21 Mar 2011 23:45:33 +0100 writes: L.S. I noticed weird tools::texi2dvi behaviour on R-alpha when specifying an absolute path to the .tex file. The same phenomenon also appears to occur on R-2.12.2, so maybe the issue is independent of R. Yes. I think it's independent of R. In any case, there's been a bug in the (Unix/Linux/teTeX/) texi2dvi sh script, a bug which I think typically only bites if you work in non-ASCII locales -- as you and I, eg. Here's the patch that I have had in place for quite a while : MM@lynne$ diff -ubBw /usr/bin/texi2dvi /usr/local/bin/scripts/texi2dvi --- /usr/bin/texi2dvi 2011-01-11 15:33:52.0 +0100 +++ /usr/local/bin/scripts/texi2dvi 2010-07-09 08:32:36.25000 +0200 @@ -33,7 +33,7 @@ set -e # This string is expanded by rcs automatically when this file is checked out. -rcs_revision='$Revision: 1.135 $' +rcs_revision='$Revision: 1.135__mod.SfS_ETHZ $' rcs_version=`set - $rcs_revision; echo $2` program=`echo $0 | sed -e 's!.*/!!'` @@ -1683,7 +1683,7 @@ # If the COMMAND_LINE_FILENAME is not absolute (e.g., --debug.tex), # prepend `./' in order to avoid that the tools take it as an option. - echo $command_line_filename | $EGREP '^(/|[A-Za-z]:/)' 6 \ + echo $command_line_filename | $EGREP '^(/|[[:alpha:]]:/)' 6 \ || command_line_filename=./$command_line_filename # See if the file exists. If it doesn't we're in trouble since, even MM@lynne$ Best regards, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-alpha typo in ?replicate ?
Thank you, Ben. I'm committing the fixes. Martin Ben Bolker bbol...@gmail.com on Mon, 21 Mar 2011 23:09:29 -0400 writes: simplify: logical or character string; should the result be simplified to a vector, matrix or higher dimensional array if possible? The default, ‘TRUE’, returns a vector or matrix if appropriate, whereas ‘signify = array’, rather recommended typically, the result may be an ‘array’ of “rank” (=‘length(dim(.))’) one higher than the result of ‘FUN(X[[i]])’. Should this read ... whereas if 'simplify=array', typically recommended, the result ... ? Also, ?scan says: multi.line: logical. Only used if ‘what’ is a list. If ‘FALSE’, all of a record must appear on one line (but more than one record can appear on a single line). Note that using ‘fill = TRUE’ implies that a record will terminated at the end of a line. I think a be is missing between will and terminated __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] core Matrix package segfaulted on R CMD check --use-gct
Douglas Bates ba...@stat.wisc.edu
on Mon, 28 Mar 2011 09:24:39 -0500 writes:
Can you provide the output from sessionInfo()
so we can know the platform? Also, did you configure R
with --enable-strict-barrier or set the C compilation flag
-DTESTING_WRITE_BARRIER? I think that run-time error
message can only be thrown under those circumstances (not
that it isn't an error, it's just not checked for in other
circumstances).
interesting.
In the mean time, I *did* run --- for several hours! ---
your code example below,
and it did *not* segfault for me (64-bit, Linux Fedora 13).
Martin
Douglas Bates ba...@stat.wisc.edu
on Mon, 28 Mar 2011 09:24:39 -0500 writes:
Can you provide the output from
sessionInfo()
so we can know the platform? Also, did you configure R with
--enable-strict-barrier or set the C compilation flag
-DTESTING_WRITE_BARRIER? I think that run-time error message can only
be thrown under those circumstances (not that it isn't an error, it's
just not checked for in other circumstances).
On Sat, Mar 26, 2011 at 5:21 PM, Hin-Tak Leung hintak_le...@yahoo.co.uk
wrote:
Current core/Recommended Matrix package (0.999375-48) has been
segfaulting against R 2.13-alpha/2.14-trunk for the last week or so (since
R-2.13 was branched, when I started trying) when run with R CMD check
--use-gct:
--
pkgname - Matrix
source(file.path(R.home(share), R, examples-header.R))
gctorture(TRUE)
options(warn = 1)
library('Matrix')
Loading required package: lattice
Error : .onLoad failed in loadNamespace() for 'Matrix', details:
call: fun(...)
error: unprotected object (0x2768b18) encountered (was REALSXP)
Error: package/namespace load failed for 'Matrix'
Execution halted
---
I traced to this because R CMD check --use-gct snpStats (both 1.1.13
and 1.1.12) segfaults with the same message, and before that, the snpMatrix
1.15.8.4 which includes some of David's newly written ld() ( which depends on
Matrix.)
If the Matrix package segfaults, David's new ld() isn't useable.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] core Matrix package segfaulted on R CMD check --use-gct
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL Douglas Bates wrote:
I isolated the problem and tested then committed a fix. I am going to
ask Martin to upload the new release as I have gotten out of sync with
some of his recent changes and he will, I hope, reconcile the branches
and trunk. If you need the fixed version immediately, say for
testing, the changes are in the file Matrix/src/chm_common.c You can
visit the SVN archive for the project,
https://r-forge.r-project.org/scm/?group_id=61, click on the link to
Browse Subversion Repository and go to pkg/Matrix/src/chm_common.c
I made the mistake that I chastised others for making, performing an
operation on the result of a call to install and another value that
may have required allocation of memory. The first time install is
called on a particular string it allocates and SEXPREC, which may
cause a garbage collection.
HL Matrix-for-R-2.13@2659 (0.999375-49) has the problem at a different
place:
pkgname - Matrix
source(file.path(R.home(share), R, examples-header.R))
gctorture(TRUE)
options(warn = 1)
options(error=dump.frames)
library('Matrix')
HL Loading required package: lattice
HL Error in regexpr(package:, envName, fixed = TRUE) :
HL unprotected object (0x2fe5818) encountered (was INTSXP)
HL Error: package/namespace load failed for 'Matrix'
HL That aside - with R 2.13 only about a week to go, which version of
Matrix will
HL it ship?
Well, R-2.13.0 is in Release Candidate ('RC') stage, after having
passed the alpha and beta stages.
So, almost surely, the current CRAN version of Matrix, also part
of all recent R-2.13.0 tarballs will be shipped along.
If we can reproduce your problem, we will fix it, hopefully
pretty soon, and release a version of Matrix, 0.9996875-0
close to the release time of R-2.13.0;
but for stability reasons (of R-2.13.0 and all its testing on
all platforms), it would not ship with 2.13.0 and only people
who explicitly update.packages(...) [after R-2.13.0
installation] will get it.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] core Matrix package segfaulted on R CMD check --use-gct
Martin Maechler maech...@stat.math.ethz.ch
on Thu, 7 Apr 2011 12:24:32 +0200 writes:
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL Douglas Bates wrote:
I isolated the problem and tested then committed a fix. I am
going to ask Martin to upload the new release as I have gotten
out of sync with some of his recent changes and he will, I
hope, reconcile the branches and trunk. If you need the fixed
version immediately, say for testing, the changes are in the
file Matrix/src/chm_common.c You can visit the SVN archive for
the project, https://r-forge.r-project.org/scm/?group_id=61,
click on the link to Browse Subversion Repository and go to
pkg/Matrix/src/chm_common.c
I made the mistake that I chastised others for making,
performing an operation on the result of a call to install and
another value that may have required allocation of memory.
The first time install is called on a particular string it
allocates and SEXPREC, which may cause a garbage collection.
HL Matrix-for-R-2.13@2659 (0.999375-49) has the problem at a different
place:
Are you sure that you really took 0.999375-49 and not its
predecessor ???
I haven't been able to reproduce the problem (on 32-bit Linux,
R-2.13.0 RC, after running your code snippet below for a couple
of hours, I got the prompt back, and things continued working..)
and Doug Bates has had a strong suspicion that the error message
below looks like the problem that he fixed just between *-48 and *-49.
pkgname - Matrix
source(file.path(R.home(share), R, examples-header.R))
gctorture(TRUE)
options(warn = 1)
options(error=dump.frames)
library('Matrix')
HL Loading required package: lattice
HL Error in regexpr(package:, envName, fixed = TRUE) :
HL unprotected object (0x2fe5818) encountered (was INTSXP)
HL Error: package/namespace load failed for 'Matrix'
Can you give more exact info about the platform ?
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] core Matrix package segfaulted on R CMD check --use-gct
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 07 Apr 2011 19:31:35 +0100 writes:
HL Martin Maechler wrote:
Martin Maechler maech...@stat.math.ethz.ch on Thu,
7 Apr 2011 12:24:32 +0200 writes:
HL == Hin-Tak Leung ht...@users.sourceforge.net
on Thu, 7 Apr 2011 07:51:44 +0100 writes:
HL Douglas Bates wrote:
I isolated the problem and tested then committed a
fix. I am going to ask Martin to upload the new
release as I have gotten out of sync with some of his
recent changes and he will, I hope, reconcile the
branches and trunk. If you need the fixed version
immediately, say for testing, the changes are in the
file Matrix/src/chm_common.c You can visit the SVN
archive for the project,
https://r-forge.r-project.org/scm/?group_id=61, click
on the link to Browse Subversion Repository and go to
pkg/Matrix/src/chm_common.c
I made the mistake that I chastised others for
making, performing an operation on the result of a
call to install and another value that may have
required allocation of memory. The first time
install is called on a particular string it allocates
and SEXPREC, which may cause a garbage collection.
HL Matrix-for-R-2.13@2659 (0.999375-49) has the problem at
HL a different place:
Are you sure that you really took 0.999375-49 and not its
predecessor ???
HL The two errors look similiar but different (the previous
HL one was about a REALSXP), and both are fairly
HL reproducible.
well, in my experience such problems typically don't show
exactly at the same place, and so the exact instance at which
an unprotected object is GC'ed also changes, and
hence I guesed it could be a REALSXP once and an INTSXP next
time.
HL As much as I can be sure, I guess. I overwrote
HL src/library/Recommended and library/Matrix to be sure.
??? But the prerelease version of R-2.13.0 *contains* already
Matrix_0.999375-49 the one you claim has the bug.
[[and you still haven't told use the exact R version you were using]]
I haven't been able to reproduce the problem (on 32-bit
Linux, R-2.13.0 RC, after running your code snippet below
for a couple of hours, I got the prompt back, and things
continued working..) and Doug Bates has had a strong
suspicion that the error message below looks like the
problem that he fixed just between *-48 and *-49.
pkgname - Matrix
source(file.path(R.home(share), R,
examples-header.R)) gctorture(TRUE)
options(warn = 1) options(error=dump.frames)
library('Matrix')
HL Loading required package: lattice Error in
HL regexpr(package:, envName, fixed = TRUE) : unprotected
HL object (0x2fe5818) encountered (was INTSXP) Error:
HL package/namespace load failed for 'Matrix'
Can you give more exact info about the platform ?
HL fedora 14 x86_64.
export DEFS='-DUSE_TYPE_CHECKING_STRICT -DR_MEMORY_PROFILING'
./configure --enable-memory-profiling --enable-strict-barrier \
--enable-byte-compiled-packages --with-valgrind-instrumentation=2
aah, ok. Well of course that's not an R version I just have at
my disposal ... ... but I'm building it now
(for R-2.13.0 RC, i.e. the R-2-13-branch in R's subversion
tree, revision 55350), and start your test - with R's own
(=CRAN's) Matrix before finishing for today.
HL Matrix-for-R-2.13@2659 was the one I was playing with.
HL I am currently testing Matrix trunk@2666, since you
HL seems to have put something relevant in r2661.
That was really something else, also an important clean up step,
but entirely unrelated to protection and garbage collection...
and ... that version will definitely not make it into R-2.13.0
since it has too many changes compared with the one R-2.13.0
RC has been shipping with.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build now removes empty dirs
Pages, Herve hpa...@fhcrc.org on Tue, 29 Mar 2011 23:56:47 -0700 (PDT) writes: Hi, It's unfortunate that with recent revisions of R 2.13 (this appeared in revision 54640, March 2), 'R CMD build' now removes empty dirs in the package. People might have good reasons for having empty dirs in their packages. For example, in Bioconductor, we have some tools to automatically generate annotation packages and those tools are implemented in software packages that use templates for the annotation packages to be generated. Those package templates are stored under the inst/ folder of the software package. One of those software packages is the AnnotationDbi package: it contains 41 package templates under inst/: [hpages@latitude Rpacks]$ ls AnnotationDbi/inst/AnnDbPkg-templates/ AFFYHUEX.DB CHIMP.DB MALARIA.DB WORM.DB ANOPHELES.DB COELICOLOR.DB MOUSECHIP.DB XENOPUSCHIP.DB ARABIDOPSISCHIP.DB ECOLICHIP.DB MOUSE.DB XENOPUS.DB ARABIDOPSIS.DB ECOLI.DB ORGANISM.DB YEASTCHIP.DB BASEPKG.DB FLYCHIP.DB PFAM.DB YEAST.DB BOVINECHIP.DB FLY.DB PIGCHIP.DB YEASTNCBI.DB BOVINE.DB GO.DB PIG.DB ZEBRAFISHCHIP.DB CANINECHIP.DB HUMANCHIP.DB RATCHIP.DB ZEBRAFISH.DB CANINE.DB HUMAN.DB RAT.DB CHICKENCHIP.DB INPARANOID.DB RHESUS.DB CHICKEN.DB KEGG.DB WORMCHIP.DB Those package templates are just the skeletons of the hundreds of annotation packages that we generate. Of course, each of them contains empty subfolders. Having 'R CMD build' remove those empty subfolders breaks all the tools that make use of those package templates. Maybe I've missed it but I didn't see any mention of this feature on this list and the fact that it was added only 6 weeks before the next R and Bioconductor releases is only making this worse. I hope this feature can be reverted. Why would people or our build system need to start using R CMD build --keep-empty-dirs just to get a source tarball right? Thanks, H. PS: This page http://stat.ethz.ch/R-manual/R-devel/doc/html/NEWS.html (referenced from http://developer.r-project.org/) has not been updated for months. Thank you, Herve. I've only now read your e-mail. (and I now also agree that --keep-empty-dirs should *not* be needed to keep an empty inst/ !) Thanks for the heads up about NEWS.html. It's finally current again, and hopefully remains so: It got outdated accidentally, as it was removed from the default 'make' target, and now needs an extra make call. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] core Matrix package segfaulted on R CMD check --use-gct
Fantastic. Thanks a lot, Luke!
I can close the thread just to say the finalit wasn't
Matrix after all!
;-)
On Fri, Apr 8, 2011 at 20:48, luke-tier...@uiowa.edu wrote:
Fixed in R-devel by 55385 and R-2-113-branch by 55386.
The problem was a call to install() in the C srouce code without
protecting another value before the install call. This particular
issue was very unlikely to cause a problem outside of a gctorture
context, but in that context with the memory checking enabled by the
strict barrier it will get caught.
Quick notes in case someone else needs to track this sort of thing
down: When gctorture is used in conjuction with the memory checks
enabled by the strict barrier it is very likely that an error will be
detected and signaled very close to where the problem in the C code
actually is, which is why I tried an example using only regexpr when
the error was being signaled there. Once a reproducable example is
found, setting a breakpoint in memory.c:CHK on the line that signals
the error gives a stack trace of the C calls involved, and in this
case the culprit was pretty easy to find at that point.
luke
On Fri, 8 Apr 2011, Hin-Tak Leung wrote:
--- On Fri, 8/4/11, peter dalgaard pda...@gmail.com wrote:
On Apr 7, 2011, at 23:57 , Hin-Tak Leung wrote:
Oh, I am tracking both R and Matrix via git-svn and
retrieves all revisions to all branches daily (or at least,
regularly). I.e. R svn head. 2.13.0 only forked off
recently and most of the trunk-2.13.0rc differences
are so far mostly documentation-related. I could switch to
track R 2.13.x branch if you insist.
Please do. It's the branch that is supposed to stabilize
during prerelease times.
Also, please check the prerelease tarballs, errors in make
dist are not caught when building from svn.
Just so that there is no doubt, here is the recipe with the latest rc tar
ball, cutting-and-pasting from my command history:
wget -m
http://cran.r-project.org/src/base-prerelease/R-rc_2011-04-07_r55373.tar.gz
cd /tmp
tar -zxpvf
~/cran.r-project.org/src/base-prerelease/R-rc_2011-04-07_r55373.tar.gz
cd R-rc/
export DEFS='-DUSE_TYPE_CHECKING_STRICT -DR_MEMORY_PROFILING' ;
./configure --enable-memory-profiling --enable-strict-barrier
--enable-byte-compiled-packages --with-valgrind-instrumentation=2 ; make
cd src/library/
cd Recommended/
../../../bin/R CMD check --use-gct Matrix_0.999375-49.tar.gz
--
...
Running examples in ‘Matrix-Ex.R’ failed
The error occurred in:
R version 2.13.0 RC (2011-04-07 r55373)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
...
pkgname - Matrix
source(file.path(R.home(share), R, examples-header.R))
gctorture(TRUE)
options(warn = 1)
library('Matrix')
Loading required package: lattice
Error in regexpr(package:, envName, fixed = TRUE) :
unprotected object (0x3be2ba8) encountered (was INTSXP)
Error: package/namespace load failed for 'Matrix'
Execution halted
-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD build --resave-data
Hervé Pagès hpa...@fhcrc.org on Tue, 12 Apr 2011 22:21:58 -0700 writes: On 11-04-12 07:06 PM, Simon Urbanek wrote: On Apr 12, 2011, at 8:53 PM, Hervé Pagès wrote: Hi Uwe, On 11-04-11 08:13 AM, Uwe Ligges wrote: On 11.04.2011 02:47, Hervé Pagès wrote: Hi, More about the new --resave-data option As mentioned previously here https://stat.ethz.ch/pipermail/r-devel/2011-April/060511.html 'R CMD build' and 'R CMD INSTALL' handle this new option inconsistently. The former does --resave-data=gzip by default. The latter doesn't seem to support the --resave-data= syntax: the --resave-data flag must either be present or not. And by default 'R CMD INSTALL' won't resave the data. Also, because now 'R CMD build' is resaving the data, shouldn't it reinstall the package in order to be able to do this correctly? Here is why. There is this new warning in 'R CMD check' that complains about files not of a type allowed in a 'data' directory: http://bioconductor.org/checkResults/2.8/bioc-LATEST/Icens/lamb1-checksrc.html The Icens package also has .R files under data/ with things like: bet- matrix(scan(CMVdata, quiet=TRUE),nc=5,byr=TRUE) i.e. the R code needs to access some of the text files located in the data/ folder. So in order to get rid of this warning I tried to move those text files to inst/extdata/ and I modified the code in the .R file so it does: CMVdata_filepath- system.file(extdata, CMVdata, package=Icens) bet- matrix(scan(CMVdata_filepath, quiet=TRUE),nc=5,byr=TRUE) But now 'R CMD build' fails to resave the data because the package was not installed first and the CMVdata file could not be found. Unfortunately, for a lot of people that means that the safe way to build a source tarball now is with R CMD build --keep-empty-dirs --no-resave-data Hervé, actually is makes some sense to have these defaults from a CRAN maintainer's point of view: --keep-empty-dirs: we found many packages containing empty dirs unnecessarily and the idea is to exclude them at the build state rather than at the later installation stage. Note that the package maintainer is supposed to run build (and knows if the empty dirs are to be included, the user who runs INSTALL does not). --no-resave-data: We found many packages with unsufficiently compressed data. This should be fixed when building the package, not later when installing it, since the reduces size is useful in the source tarball already. So it does make some sense to have different defaults in build as opposed to INSTALL from my point of view (although I could live with different, tough). If you deliberately ignore the fact that 'R CMD INSTALL' is also used by developers to install from the *package source tree* (by opposition to end users who use it to install from a *source tarball*, .. for a good reason, IMHO no serious developer would do that for obvious reasons - This sounds like saying that no serious developer working on a big project involving a lot of files to compile should use 'make'. I mean, serious developers like you *always* do 'make clean' before they do 'make' on the R tree when they need to test a change, even a small one? And this only takes a fraction of second for them? Hey, I'd love to be able to do that too! ;-) H. you'd be working on a dirty copy creating many unnecessary problems and polluting your sources. The first time you'll spend an hour chasing a non-existent problem due to stale binary objects in your tree you'll learn that lesson ;). The fraction of a second spent in R CMD build is well worth the hours saved. IMHO the only valid reason to run INSTALL on a (freshly unpacked tar ball) directory is to capture config.log. Cheers, Simon even though they don't use it directly), then you have a point. So maybe I should have been more explicit about the problem that it can be for the *developer* to have 'R CMD build' and 'R CMD INSTALL' behave differently by default. Of course I'm not suggesting that 'R CMD INSTALL' should behave differently (by default) depending on whether it's used on a source tarball (mode 1) or a package source tree (mode 2). I'm suggesting that, by default, the 3 commands (R CMD build + R CMD INSTALL in mode 1 and 2) behave consistently. With the latest changes, and by default, 'R CMD INSTALL' is still doing the right thing, but not 'R CMD build' anymore. I
Re: [Rd] Dangerous Bug with IF function of R
salmajj salm...@softhome.net on Mon, 18 Apr 2011 11:11:28 -0700 (PDT) writes: Thanks a lot Petr it works!!! of course .. You know for someone who is used to work with matlab it is not so obvious:) well, what do you mean with that? I'm intrigued. After such a blatantly wrong claim about a bug in R... what exactly are you claiming about Matlab here? That it implements (software) decimal arithmetic on top of the cpu-internal binary arithmetic ? probably rather not ... So? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] FW: [Rcpp-devel] Question on 5.6 Interfacing C++ code
Simon Urbanek simon.urba...@r-project.org on Thu, 21 Apr 2011 10:57:19 -0400 writes: On Apr 21, 2011, at 10:52 AM, Sean Robert McGuffee wrote: Thanks, That's great, but I don't know how to determine what foo is. It's the name of your package. How do I declare the name of the package? in DESCRIPTION: Package: name and the directory of your package has to have the same name - that is no longer true ( since .. rough guess ... about two years). And that's actually quite an important feature to me. E.g., I can have a directory, say lme4_MM_2001-04-18/ with a particularly hacked version version, and then simply do R CMD check lme4_MM_2001-04-18 which will install and check it in lme4_MM_2001-04-18.Rcheck/ please do read http://r.research.att.com/man/R-exts.html#Creating-R-packages so indeed, we should cancel the sentence The package subdirectory should be given the same name as the package. in there, or maybe rather replace it by The package subdirectory typically has the same name as the package. Martin Cheers, Simon On 4/21/11 7:16 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 11-04-20 11:33 AM, Sean Robert McGuffee wrote: Hi, apparently I sent my question about using R and C++ to the wrong list, ironically seeing as that list was called Rcpp. Anyway, I was directed to post my question here. To summarize my current question, I have found two commands that I want to be able to put into a package. The commands are 'R CMD SHLIB X.cc X_main.cc' and 'dyn.load(paste(X,.Platform$dynlib.ext,sep=)),' which I would like to run when my package is installed and maybe have the second command run again when my package is to be used. I've been trying to figure out the documentation and learn through examples, but I'm just not getting it and have been trying for weeks. Does anyone on this site have any suggestions for me? Assuming those lines work on their own, just do the following: 1. Put those *.cc files into the src directory of your package. (You may need to create it.) 2. Put useDynLib(foo) into the NAMESPACE file of your foo package. 3. Call those functions using .C(X, args, PACKAGE=foo). That's it. Duncan Murdoch Thanks, Sean |On 20 April 2011 at 10:20, Sean Robert McGuffee wrote: | | | Hi, thanks! | |On 4/20/11 10:03 AM, Steve Lianogloumailinglist.honey...@gmail.com wrote: | Hi, | | On Wed, Apr 20, 2011 at 9:49 AM, Sean Robert McGuffee | sean.mcguf...@gmail.com wrote: | Hi, I have a quick couple of questions about some of the documentation on | the web page: | http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-fro n | t_002dends-to-R | under the heading: | 5.6 Interfacing C++ code | | Question 1: | If I’m at a terminal, I can type the instructions they suggest: | R CMD SHLIB X.cc X_main.cc | If I wanted a package to do this, how would I tell the package to do that | same thing? | | Just to make sure we're all on the same page, you want an R package to | compile some source code into a shared library/dll from inside R? | | Not sure if there's a baked in way for that to happen, but maybe you | can invoke `R CMD WHATEVER` from inside R using the `system` function: | | R ?system | | | ok, so where in the package would I put the system call in the package to | have it run when installing the package? You don't. As I said, 'R CMD INSTALL' et all do that. Download an existing package with source, install it. Study its sources, study the 'Writing R Extensions' manual. Ask on r-devel. Basic R questions are off-topic here. | Would I use the same command and just include it in a file somewhere in the | package? | If so, which file? | | Hmm ... I'm curious what you're trying to do, exactly? | | I'm trying to figure out how take commands such as R CMD SHLIB X.cc | X_main.cc followed by dyn.load(paste(X, .Platform$dynlib.ext, sep = | )), which are commands I can get to work for myself as a human | interactively, and put the commands into a package to be automatically run | when installing the package. I mean, it's great if I can compile a c++ file | and then use it inside R, but I'm only doing that so I can let other people | do that via a package. As much as I read this documentation, I keep missing Again, I like working from an existing, working package. As I said, there are almost 1000 to pick from. Please direct follow-ups that have no bearing on Rcpp to r-devel. Dirk I've tried to figure this
Re: [Rd] An update of the Distribustions man page
Christophe Dutang duta...@gmail.com
on Tue, 19 Apr 2011 16:03:06 +0200 writes:
Dear list, I would like to suggest a small update the
?Distributions man page of the stats package. The current
version contains the following line.
The CRAN package \pkg{SuppDists} for additional distributions.
I think it would be better to put in this man page a link to the
CRAN task view on Distributions
http://cran.r-project.org/web/views/Distributions.html. It is
not true that the SuppDists package alone contains distributions
which are not implemented in R base.
Could it be possible to modify this sentence?
Yes, I have done so now.
The Distributions task view is indeed much more comprehensive
than just the SuppDists package ... which indeed used to be the
first (or one of the..) CRAN package extending distributions
functionality.
I don't know if there are other overview man pages in R related
to other task views? But a link to the task views on those man
pages could increase the popularity of the CRAN task views.
Good point Up to now I haven't take time to look through the
R sources for such candidate pages.
Suggestions are welcome.
Kind regards
Christophe
Thank you for the suggestion, Christophe!
Martin Maechler,
ETH Zurich
--
Christophe DUTANG
Ph. D. student at ISFA, Lyon, France
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] request for R-exts addition
Ben Bolker bbol...@gmail.com on Thu, 28 Apr 2011 10:06:01 -0400 writes: would it be possible / make sense to copy some of the information in ?news into the R-exts manual, where package writers are most likely (?) to look for it? sure... The information therein seems more appropriate for the extensions manual ... you mean when we (R core) add extensions to package handling, Rd syntax, the C API, ... and only report it in NEWS instead of also updating the R Extensions manual? Well, that happens as you can imagine. In some cases, the entry in NEWS will say that a feature is experimental, so we don't want to document it yet in stone, as we expect the details to change. But apart from those, I'm sure it will also happen otherwise, since most of R core have more fun writing code than manuals but when we are called to duty we typically eventually oblige ;-) So, yes indeed, it makes very much sense to keep the manual as up-to-date as possible, and some of us consider the manual to be an important part of R's source tarball. So, patches and even other (concrete!) proposals for improvement are welcome. Ideally using texinfo syntax or even better a patch towards a current version of the manual Rsource/doc/manual/R-exts.texi from subversion, a nightly tarball, or simply https://svn.r-project.org/R/trunk/doc/manual/R-exts.texi With many thanks in advance, Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] median and data frames
Paul Johnson pauljoh...@gmail.com on Thu, 28 Apr 2011 00:20:27 -0500 writes: On Wed, Apr 27, 2011 at 12:44 PM, Patrick Burns pbu...@pburns.seanet.com wrote: Here are some data frames: df3.2 - data.frame(1:3, 7:9) df4.2 - data.frame(1:4, 7:10) df3.3 - data.frame(1:3, 7:9, 10:12) df4.3 - data.frame(1:4, 7:10, 10:13) df3.4 - data.frame(1:3, 7:9, 10:12, 15:17) df4.4 - data.frame(1:4, 7:10, 10:13, 15:18) Now here are some commands and their answers: median(df4.4) [1] 8.5 11.5 median(df3.2[c(1,2,3),]) [1] 2 8 median(df3.2[c(1,3,2),]) [1] 2 NA Warning message: In mean.default(X[[2L]], ...) : argument is not numeric or logical: returning NA The sessionInfo is below, but it looks to me like the present behavior started in 2.10.0. Sometimes it gets the right answer. I'd be grateful to hear how it does that -- I can't figure it out. Hello, Pat. Nice poetry there! I think I have an actual answer, as opposed to the usual crap I spew. I would agree if you said median.data.frame ought to be written to work columnwise, similar to mean.data.frame. apply and sapply always give the correct answer apply(df3.3, 2, median) X1.3 X7.9 X10.12 2 8 11 [...] exactly mean.data.frame is now implemented as mean.data.frame - function(x, ...) sapply(x, mean, ...) exactly. My personal oppinion is that mean.data.frame() should never have been written. People should know, or learn, to use apply functions for such a task. The unfortunate fact that mean.data.frame() exists makes people think that median.data.frame() should too, and then var.data.frame() sd.data.frame() mad.data.frame() min.data.frame() max.data.frame() ... ... all just in order to *not* to have to know sapply() No, rather not. My vote is for deprecating mean.data.frame(). Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Kendall's tau code
S == SeshanV sesh...@mskcc.org on Sat, 30 Apr 2011 11:20:59 -0400 writes: I discovered that the Kendall's tau calculation in R uses all pairwise comparisons which is O(n^2) and takes a long time for large vectors. I implemented a O(n*log(n)) algorithm based on merge-sort. Is this of interest to be included in core R? Yes, quite a bit of interest! I know about the O(n^2) feature for quite a while, and it is indeed a considerable problem in copula modelling which has become an interest of mine in the recent year. The code (fortran and R wrapper) is available in my package clinfun v0.9.7 (not exported in NAMESPACE). Thank you! Yes, I see you've put them there quite recently. I see the Fortran code uses modern allocate / deallocate constructs (that I don't know). As I think we'd want to use this in the C code which is also underlying cor(*, method=kendall) I'll eventually want a C version, not the least because we may look into dealing with NA 's in the same -- flexible -- way that they are handled currently via the 'use = ...' argument. I may contact you privately for more. Thanks again, Martin Maechler, ETH Zurich (and R Core Team). Thanks, Venkat -- Venkatraman E. Seshan, Ph.D. | Attending Biostatistician Director of Biostatistics Computer-Intensive Support Services Department of Epidemiology and Biostatistics | MSKCC 307 E 63rd St 3rd Floor | New York, NY 10065 Phone: 646-735-8126 | Fax: 646-735-0010 __ 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 CMD check and Suggests Packages
Hervé Pagès hpa...@fhcrc.org
on Mon, 02 May 2011 11:55:08 -0700 writes:
Hi, On 11-04-28 07:00 PM, Dario Strbenac wrote:
Hello,
In my description file, I have an example data package in
Suggests: that I've deleted from my library to test what
the user who doesn't have it will experience.
However, R CMD check won't even pass my package :
* checking package dependencies ... ERROR
Package required but not available: RepitoolsExamples
confusing!
Wouldn't a message like
Package required for full checking but not available:
RepitoolsExamples
be more appropriate and avoid a confusion that we've seen
for a very long time now?
Sure. But such messages are already produced in current
versions of R, .. at least they are there in the package checking
source, see
format.check_package_depends() in
src/library/tools/R/QC.R
which has e.g.,
if(length(bad - x$suggests_but_not_installed) 1L) {
c(gettext(Packages suggested but not available for checking:),
and similar for 'Enhances' in lieu of 'Suggests'.
If Dario really uses R 2.13.0 (or newer),
and he gets the above error message for a package that is not
required but only suggested,
I think we'd need a clear, ideally simple,
reproducible example, here.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Add See Also: missing to help('exists')?
SpGMight it be feasible to add, See Also: missing
SpG to the help page for exists?
SpGCurrently, one can spend hours studying the help
SpG page for exists without getting a clue to the answer
SpG to the post copied below.
Yes. I've added such a link now...
though quite disillusioned with a very vague hope that useRs
would read the help page so thoroughly ...
Martin Maechler, ETH Zurich
SpGThanks, Spencer
SpG On 5/14/2011 3:30 AM, David Winsemius wrote:
On May 14, 2011, at 3:30 AM, utkarshsinghal wrote:
Hi all,
I want to define a function such that one of its argument if passed
do one
thing and if not passed do the second thing.
?missing
So basically, I have to check
whether the argument is passed or not inside the function. I am
trying to
use 'exists' function to do this.
f = function(a,b){exists(b)}
f(a=3, b=4)
[1] TRUE
This is working as expected.
But if I do the following:
f(a=3)
[1] TRUE
Can anybody explain why this function is returning TRUE here.
--
Many thanks,
Utkarsh
...
David Winsemius, MD
West Hartford, CT
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (no subject)
Simon Urbanek simon.urba...@r-project.org on Tue, 28 Jun 2011 11:31:58 -0400 writes: On Jun 28, 2011, at 9:58 AM, Michelle.Carey wrote: Hi, I am trying to write code in C for an R package. I need high precision in the form of the mpfr and gmp packages. gmp is available as R package http://cran.r-project.org/web/packages/gmp/index.html do you really need it at a lower level than that? and so is MPFR: Package 'Rmpfr' (both on CRAN and R-forge) .. and I am asking the same question as Simon: Are you sure you need to use your own C code, instead of simply using the R packages 'gmp' and 'Rmpfr' and work with R code? -- Martin Maechler, ETH Zurich I have installed mpfr and gmp under the instructions of the following website http://pauillac.inria.fr/cdrom_a_graver/prog/pc/mpfr/eng.htm and I get no errors. I have put the header files (mpfr.h and gmp.h) in the folder C:\Program Files\R\R-2.13.0\include; That doesn't sound right - the instructions you quote install in the default location which is presumably /usr/local so you should simply set your flags to use that location. allowing my c code to identify the header files by incorporating includegmp.h and includempfr.h. Unfortunately when I try to include any of the functions listed in the header file I get compile error stating that these functions are undeclared, That doesn't sound plausible, either - undeclared function don't cause errors (not in C). Undefined functions do and you have to make sure you link the libraries installed above. even though the source code is in the same directory as my c code that I am trying to compile. That bears no meaning - as you said you installed the libraries, so you have to use those. Source code of gmp/mpfr has no effect on your code and should not be anywhere near it. Cheers, Simon Any help on this matter would be greatly appreciated. Kind Regards, Michelle Carey __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] short documentation suggestion for by --- reference simplify2array and ave
iw == ivo welch ivo.we...@gmail.com
on Fri, 8 Jul 2011 20:47:08 -0700 writes:
iw in the documentation for by, please change the See
iw also section to \seealso{\code{\link{tapply}},
iw \code{\link{simplify2array}}, \code{\link{ave}}}
iw (simplify2array, by, and ave should probably also be
iw mentioned in the See also section of apply.)
iw hope this helps.
Yes, thank you.
I did (something like) that.
--
Martin Maechler, ETH Zurich
iw /iaw Ivo Welch (ivo.we...@gmail.com)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] heatmap documentation typo
Jonathan Dushoff dush...@mcmaster.ca
on Thu, 30 Jun 2011 14:09:30 -0400 writes:
Under Details, the documentation says [if Rowv or Colv] is 'NULL',
_no reordering_ will be done for the corresponding side. In fact, as
explained elsewhere in the documentation, 'NA' is required, not
'NULL'.
An anonymous expert suggested that I should attach an svn diff file to
this report, so I will.
Not necessary. I've now committed the fix.
Thank you, Jonathan, for the report.
Martin Maechler, ETH Zurich
--
Index: heatmap.Rd
===
--- heatmap.Rd(revision 56237)
+++ heatmap.Rd(working copy)
@@ -94,7 +94,7 @@
If either is missing, as by default, then the ordering of the
corresponding dendrogram is by the mean value of the rows/columns,
i.e., in the case of rows, \code{Rowv - rowMeans(x, na.rm=na.rm)}.
- If either is \code{\link{NULL}}, \emph{no reordering} will be done for
+ If either is \code{\link{NA}}, \emph{no reordering} will be done for
the corresponding side.
By default (\code{scale = row}) the rows are scaled to have mean
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Same class name, different package
John Chambers j...@r-project.org on Sun, 24 Jul 2011 14:58:23 -0700 writes: A point that has come up a couple of times with the new test is that two classes from two packages may be the same class. Should that turn on duplicate classes? One situation where the answer seems to be No is when the two classes are identical declarations of S3 classes, via setOldClass(). A recent update (rev. 56492) tries to check for equivalent classes, with some special leeway for that case, and does not turn on the duplicate class flag. It's not clear what is really needed or wanted in all circumstances, so further experience will be helpful. If duplicate classes do exist, a utility findDuplicateClasses(details = FALSE) will give the names of the duplicated classes. It's not yet exported so you need to call methods:::findDuplicateClasses() John I haven't yet looked into the many situations that are out there for CRAN and Bioconductor packages and am just speaking from my own S4-using perspective: I think ImportClassesFrom(...) should be much more widely used, in order to diminish such class conflicts. Wherever the new code produces warnings (does it?) about duplicate class names, it would be good to advertize the ImportClassesFrom() clause for those cases where the two class definitions look to be identical. Martin On 7/21/11 10:29 AM, John Chambers wrote: In principle, two separately developed packages could use the same class name, and a user could then attach both and attempt to use methods for both classes. That has never worked, but some changes have been added to r-devel to handle this case. The changes involve extending the signature class to include package information. For compatibility, packages will need to be re-installed from a version of R labelled 56466 or later, although an attempt is made to fill in missing information. John __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'data.frame' method for base::rep()
David Winsemius dwinsem...@comcast.net
on Tue, 2 Aug 2011 10:14:59 -0400 writes:
On Aug 2, 2011, at 7:55 AM, Liviu Andronic wrote:
Dear R developers Would you consider adding a
'data.frame' method for the base::rep function? The need
to replicate a df row-wise can easily arise while
programming, and rep() is unable to handle such a
case. See below.
x - iris[1, ]
x[ rep(1,2), ] # works
Yes, indeed, and that I think is my definitive answer
to the proposal.
Defining a rep() method for data frames seems much less sensible
First because one simple substitute exists (namely indexing,
see above), and to me, not the least because there are several problems /
questions that would have to be answered
- Why should rep() for data frame necessarily replicate rows and
not columns?
- If some rows should be resampled, why each row exactly the
same number of times?
- any solution that is not compatible tox [ rep(i, k) , ]
would be unsatisfactory
- What rownames should the new data frame get in case of real
rownames (i.e., not the fast 1:n pseudo-rownames)?
The informal definition of a data frame says that the rownames
must be unique.
-- and of course, the indexing solution
xx - iris[ rep(1:nrow(iris), 3) , ]
does implement one sensible way of producing unique row.names,
{though, I must say, not the optimal one if the issue is efficiency}
Rather keep using [,] and let's not get into having to maintain
yet another data.frame method ..
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
Hi Rolf, please excuse a short top-reply: As I see you are using an operating system (instead of Win..), can you try in the shell echo 'X11.options()$type' | R --vanilla --slave and does that really *not* report [1] cairo ?? (and BTW: Your subject had tolower(LL) instead of 11 ) Rolf Turner r.tur...@auckland.ac.nz on Mon, 8 Aug 2011 12:49:44 +1200 writes: This question seemed to me to be more appropriate for r-devel than for r-help. My apologies if this is not the case. Recently I installed ``cairo'' on my lap-top so that I could make use of the (newish) polypath() function, with on-screen graphics. (The polypath() function does not work with X11(type=Xlib).) The installation went smoothly, X11(type=cairo) works just fine, and polypath() works just fine. However the default type for X11() remains Xlib rather than cairo. The help for X11.options() says (in respect of type): Default cairo where available and reliable, otherwise Xlib. Now cairo is definitely available: capabilities()[cairo] cairo TRUE and moreover it works (just fine!) when I do X11(type=cairo) explicitly. I know that I can set the default to be cairo in my .Rprofile, but I am curious as to why cairo does not become the default automatically. Is it the case that cairo is ``not reliable'' under my system? It ***seems*** to be reliable. sessionInfo() R version 2.13.1 Patched (2011-07-17 r56404) Platform: i686-pc-linux-gnu (32-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] datasets utils stats graphics grDevices methods base other attached packages: [1] misc_0.0-13 gtools_2.6.2 spatstat_1.23-1 deldir_0.0-15 [5] mgcv_1.7-6 fortunes_1.4-2 MASS_7.3-13 loaded via a namespace (and not attached): [1] grid_2.13.1 lattice_0.19-30 Matrix_0.999375-50 nlme_3.1-101 cheers, Rolf Turner __ 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] X11.options().
Uwe Ligges lig...@statistik.tu-dortmund.de on Mon, 8 Aug 2011 21:38:06 +0200 writes: On 08.08.2011 10:20, Martin Maechler wrote: Hi Rolf, please excuse a short top-reply: As I see you are using an operating system (instead of Win..), can you try in the shell echo 'X11.options()$type' | R --vanilla --slave Martin, given the R on my non-OS had X11.options, I'd rather written: R --slave --vanilla -e X11.options()$type Don't know why you have to type more on your OS. :-) touché, Uwe! Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matrix bands
Jeremy David Silver j...@dmu.dk
on Fri, 26 Aug 2011 13:23:43 +0200 writes:
Dear R developers, I was looking for a function analogous
to base::diag() for getting and setting bands of a
matrix. The closest I could find was Matrix::band(), but
this was not exactly what I wanted for two
reasons. Firstly, Matrix::band() returns a matrix rather
than just the specified band. Secondly, Matrix::band()
cannot be used for setting the values for a matrix band.
Yes, but did you not look at help(band)
or not look carefully enough ?
---
See Also:
‘bandSparse’ for the _construction_ of a banded sparse matrix
directly from its non-zero diagonals.
Setting or getting a matrix band could be of interest for
sufficiently many users that you might consider including
it in base R. Alternatively, something like this could be
included in the Matrix package.
well, see above and let us know if you see anything lacking in
bandSparse().
Till now we haven't got much feedback about it, and there may
well be room for improvement.
Martin Maechler, ETH Zurich and co- maintainer(Matrix)
I have included two versions of these functions, a simple
and naive version, and a more efficient version. The band
index, n, is positive for bands above the diagonal and
negative for bands below the diagonal.
Regards, Jeremy Silver
###
## less clear formulation - more efficient
band - function(x,n = 0){ dx - dim(x) if(length(dx) !=
2L) stop(only matrix bands can be accessed)
max.dx - max(dx) n - as.integer(n)
ij - cbind(i = seq(1,max.dx) - n, j = seq(1,max.dx))
ij - ij[1 = ij[,1] ij[,1] = dx[1] 1 = ij[,2]
ij[,2] = dx[2],,drop=FALSE]
if(nrow(ij) == 0) stop('cannot access this matrix
band')
x[ij] }
'band-' - function(x,n = 0, value){ dx - dim(x)
if(length(dx) != 2L) stop(only matrix bands can be
replaced)
max.dx - max(dx) n - as.integer(n)
ij - cbind(i = seq(1,max.dx) - n, j = seq(1,max.dx))
ij - ij[1 = ij[,1] ij[,1] = dx[1] 1 = ij[,2]
ij[,2] = dx[2],,drop=FALSE]
if(nrow(ij) == 0) stop('cannot replace this matrix
band')
x[ij] - value
x }
## simple, clear formulation - not very efficient band2 -
function(x, n = 0) { x[col(x) - row(x) == as.integer(n)] }
'band2-' - function(x, n = 0, value) { x[which(col(x) -
row(x) == as.integer(n))] - value x }
## here are some examples to show that it works
## define a test matrix
A - matrix(rnorm(12),3,4) A
[,1] [,2] [,3] [,4] [1,] -1.5560200 0.6452762
1.072565 0.1923451 [2,] 0.7940685 1.2441817 1.699486
-0.2998814 [3,] -0.7762252 -0.4824173 -0.981055 -0.9265627
## access some of the bands
band(A,1)
[1] 0.6452762 1.6994858 -0.9265627
band(A,-2)
[1] -0.7762252
band(A,2)
[1] 1.0725649 -0.2998814
## set one of the bands
band(A,2) - 2:1 A
[,1] [,2] [,3] [,4] [1,] -1.5560200 0.6452762
2.00 0.1923451 [2,] 0.7940685 1.2441817 1.699486
1.000 [3,] -0.7762252 -0.4824173 -0.981055 -0.9265627
## another example - a single column
A - matrix(1:10) A
[,1] [1,] 1 [2,] 2 [3,] 3 [4,] 4 [5,] 5 [6,] 6 [7,]
7 [8,] 8 [9,] 9 [10,] 10
band(A,0)
[1] 1
band(A,1)
Error in band(A, 1) : cannot access this matrix band
band(A,-1)
[1] 2
band(A,-5)
[1] 6
## compare the results from the two versions of the
function
for(i in -2:3){print(band(A,i));print(band2(A,i))}
[1] -0.7762252 [1] -0.7762252 [1] 0.7940685 -0.4824173 [1]
0.7940685 -0.4824173 [1] -1.556020 1.244182 -0.981055 [1]
-1.556020 1.244182 -0.981055 [1] 0.6452762 1.6994858
-0.9265627 [1] 0.6452762 1.6994858 -0.9265627 [1] 2 1 [1]
2 1 [1] 0.1923451 [1] 0.1923451
## show that the naive version is very slow for large
matrices
N - 1e4 M - matrix(0,N,N) system.time(band(M,2))
user system elapsed 0.005 0.003 0.007
system.time(band2(M,2))
user system elapsed 18.509 2.121 20.754
__
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] matrix bands
Jeremy David Silver j...@dmu.dk
on Fri, 26 Aug 2011 15:08:03 +0200 writes:
Thanks for the suggestion, Martin! I looked at both
Matrix::band and Matrix::bandSparse. Maybe I misunderstand the
help pages and the examples, but from what I can see neither of
them provides the functionality I was looking for.
For the getter version of the function I was looking for, I
can't use Matrix::band (by extracting the non-zero elements)
because this would require the assumption that the specified
band is entirely non-zero, e.g.:
band3 - function(x,n){
x - Matrix::band(x,n,n)
x[x!=0] ## works for a dense matrix, but not if band n has zeroes
}
As for the setter version of the function I was looking for, it should
set the values of a specified band in an existing matrix to be the
vector of values provided. As far as I understand, Matrix::bandSparse
constructs a matrix rather than modifying the values of an existing matrix.
Yes, you are right. The current bandSparse() doesn't do that...
and while you could use constructions like
diag(A[,-1]) - dd
there will probably better (more efficient) alternatives.
The functions included in my last post filled this gap. If Matrix::band
and Matrix::bandSparse can set/get bands in this way, I would like to
see how this can be done. If not, then perhaps they could be extended to
achieve this functionality.
That's a good suggestion, and I'll look at it,
further I'll look at your examples of getting ...
and at the moment I'm still a bit curious why, i.e., to what end
/ in what application you need them [ rather than band(*,.,.) ].
We may e-talk about this off-public if you want.
Martin
On 2011-08-26 14:08, Martin Maechler wrote:
Jeremy David Silverj...@dmu.dk
on Fri, 26 Aug 2011 13:23:43 +0200 writes:
Dear R developers, I was looking for a function analogous
to base::diag() for getting and setting bands of a
matrix. The closest I could find was Matrix::band(), but
this was not exactly what I wanted for two
reasons. Firstly, Matrix::band() returns a matrix rather
than just the specified band. Secondly, Matrix::band()
cannot be used for setting the values for a matrix band.
Yes, but did you not look at help(band)
or not look carefully enough ?
---
See Also:
‘bandSparse’ for the _construction_ of a banded sparse matrix
directly from its non-zero diagonals.
Setting or getting a matrix band could be of interest for
sufficiently many users that you might consider including
it in base R. Alternatively, something like this could be
included in the Matrix package.
well, see above and let us know if you see anything lacking in
bandSparse().
Till now we haven't got much feedback about it, and there may
well be room for improvement.
Martin Maechler, ETH Zurich and co- maintainer(Matrix)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] An example of very slow computation
Michael Lachmann lachm...@eva.mpg.de
on Fri, 19 Aug 2011 02:08:48 +0200 writes:
On my trials, after eliminating all the extra matrix-dgeMatrix
conversions, using expm() and the method below were equally fast.
Michael
I'm sorry I hadn't time to get into this thread when it was
hot..
and I have told Ravi in the mean time what I would have said
*VERY* early here:
1) There's an 'expm' package --- which will be mentioned on the
Matrix::expm help page in the next version of Matrix ---
that has better and faster algorithms (notably also some
which work with *sparse* matrices!) than the one in Matrix.
2) Matrix::expm() is really more reliable than one of the 19
dubious ways that Peter mentioned correctly,
and, it is really typically not a good idea to use a faster
but considerably less reliable method.
Reliability is *much* *much* more important
than speed, *really*
and we (R-core) have always tried to emphasize this approach
in all contexts.
3) Thanks to Ravi, an upcoming version of the 'expm' package
will also contain a (Krylov space) version of expm()
which is faster for the special case of evaluating
expm(A * t) %*% v{A matrix, v vector, t scalar}
and *still* numerically reliable.
Martin Maechler, ETH Zurich
Which is why I said it applies when the system is diagonalizable.
It won't work for non-diagonalizable matrix A, because T (eigenvector
matrix) is singular.
Ravi. From: peter dalgaard
[pda...@gmail.com] Sent: Thursday, August 18, 2011 6:37 PM To: Ravi
Varadhan Cc: 'cbe...@tajo.ucsd.edu'; r-de...@stat.math.ethz.ch;
'nas...@uottawa.ca' Subject: Re: [Rd] An example of very slow
computation
On Aug 17, 2011, at 23:24 , Ravi Varadhan wrote:
A principled way to solve this system of ODEs is to use the idea of
fundamental matrix, which is the same idea as that of
diagonalization of a matrix (see Boyce and DiPrima or any ODE text).
Here is the code for that:
nlogL2 - function(theta){ k - exp(theta[1:3]) sigma -
exp(theta[4]) A - rbind( c(-k[1], k[2]), c( k[1], -(k[2]+k[3])) ) eA
- eigen(A) T - eA$vectors r - eA$values x0 - c(0,100) Tx0 - T
%*% x0
sol - function(t) 100 - sum(T %*% diag(exp(r*t)) %*% Tx0) pred -
sapply(dat[,1], sol) -sum(dnorm(dat[,2], mean=pred, sd=sigma,
log=TRUE)) } This is much faster than using expm(A*t), but much
slower than by hand calculations since we have to repeatedly do the
diagonalization. An obvious advantage of this fuunction is that it
applies to *any* linear system of ODEs for which the eigenvalues are
real (and negative).
I believe this is method 14 of the 19 dubious ways... (Google for
it) and doesn't work for certain non-symmetric A matrices.
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns
Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Ravi Varadhan
Sent: Wednesday, August 17, 2011 2:33 PM
To: 'cbe...@tajo.ucsd.edu'; r-de...@stat.math.ethz.ch;
'nas...@uottawa.ca'
Subject: Re: [Rd] An example of very slow computation
Yes, the culprit is the evaluation of expm(A*t). This is a lazy way of
solving the system of ODEs, where you save analytic effort, but you pay for it
dearly in terms of computational effort!
Even in this lazy approach, I am sure there ought to be faster ways to
evaluating exponent of a matrix than that in Matrix package.
Ravi.
---
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns
Hopkins University
Ph. (410) 502-2619
email: rvarad...@jhmi.edu
-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of cbe...@tajo.ucsd.edu
Sent: Wednesday, August 17, 2011 1:08 PM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] An example of very slow computation
John C Nash nas...@uottawa.ca writes:
This message is about a curious difference in timing between two ways
of computing the
same function. One uses expm, so is expected to be a bit slower, but
a bit turned out to
be a factor of 1000. The code is below. We would be grateful if
anyone can point out any
egregious bad practice in our code, or enlighten us on why one
approach is so much slower
than the other.
Looks like A*t in expm(A*t
Re: [Rd] repeatable segfault - on Mac
David Winsemius dwinsem...@comcast.net on Tue, 6 Sep 2011 00:38:13 -0400 writes: I can reproduce: eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T) *** caught segfault *** address 0x102d0e028, cause 'memory not mapped' Traceback: 1: .Call(La_rs_cmplx, x, only.values, PACKAGE = base) 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T) ## after restart sessionInfo() R version 2.13.1 (2011-07-08) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base With OSX 10.5.8 Also happens with 32 bit R [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0] It does not happen on Linux (different versions) nor Windows (2.13.1 patched, early August). As this is calling LAPACK code, I guess that this is yet another case where the Mac version of optimized BLAS / LAPACK is playing wrongly. Martin Maechler David Winsemius On Sep 6, 2011, at 12:12 AM, robin hankin wrote: Hi. macosx 10.6.8 With R-2.13.1 and also revision 56948 I get the following repeatable segfault: wt118:~% R --vanilla --quiet R.Version() $platform [1] x86_64-apple-darwin9.8.0 $arch [1] x86_64 $os [1] darwin9.8.0 $system [1] x86_64, darwin9.8.0 $status [1] $major [1] 2 $minor [1] 13.1 $year [1] 2011 $month [1] 07 $day [1] 08 $`svn rev` [1] 56322 $language [1] R $version.string [1] R version 2.13.1 (2011-07-08) eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T) *** caught segfault *** address 0x1038000a8, cause 'memory not mapped' Traceback: 1: .Call(La_rs_cmplx, x, only.values, PACKAGE = base) 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: 2 wt118:~% -- Robin Hankin Uncertainty Analyst hankin.ro...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD Heritage Laboratories West Hartford, CT __ 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] repeatable segfault - on Mac
Simon Urbanek simon.urba...@r-project.org on Thu, 8 Sep 2011 09:33:23 -0400 writes: On Sep 8, 2011, at 4:01 AM, Martin Maechler wrote: David Winsemius dwinsem...@comcast.net on Tue, 6 Sep 2011 00:38:13 -0400 writes: I can reproduce: eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T) *** caught segfault *** address 0x102d0e028, cause 'memory not mapped' Traceback: 1: .Call(La_rs_cmplx, x, only.values, PACKAGE = base) 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T) ## after restart sessionInfo() R version 2.13.1 (2011-07-08) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base With OSX 10.5.8 Also happens with 32 bit R [R.app GUI 1.41 (5874) i386-apple-darwin9.8.0] It does not happen on Linux (different versions) nor Windows (2.13.1 patched, early August). As this is calling LAPACK code, I guess that this is yet another case where the Mac version of optimized BLAS / LAPACK is playing wrongly. Nope, this is R's BLAS / LAPACK! yes, it seems, as Peter is confirming as well. *BUT* as far as we currently know, the problem was never seen outside of MacOS X , right? Martin Maechler David Winsemius On Sep 6, 2011, at 12:12 AM, robin hankin wrote: Hi. macosx 10.6.8 With R-2.13.1 and also revision 56948 I get the following repeatable segfault: wt118:~% R --vanilla --quiet R.Version() $platform [1] x86_64-apple-darwin9.8.0 $arch [1] x86_64 $os [1] darwin9.8.0 $system [1] x86_64, darwin9.8.0 $status [1] $major [1] 2 $minor [1] 13.1 $year [1] 2011 $month [1] 07 $day [1] 08 $`svn rev` [1] 56322 $language [1] R $version.string [1] R version 2.13.1 (2011-07-08) eigen(crossprod(matrix(1:2000, 50)) + (0+0i), T, T) *** caught segfault *** address 0x1038000a8, cause 'memory not mapped' Traceback: 1: .Call(La_rs_cmplx, x, only.values, PACKAGE = base) 2: eigen(crossprod(matrix(1:2000, 50)) + (0 + (0+0i)), T, T) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: 2 wt118:~% -- Robin Hankin Uncertainty Analyst hankin.ro...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel David Winsemius, MD Heritage Laboratories West Hartford, CT __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should dir(all=TRUE) return . and ..?
William Dunlap wdun...@tibco.com on Fri, 23 Sep 2011 15:49:43 + writes: dir(all=TRUE) returns the file names . and .. while dir(recursive=TRUE, all=TRUE, include.dirs=TRUE) does not. I always filter out the . and .. entries and was wondering if anyone would mind if dir(all=TRUE) just omitted them? It might make recursive file operations like cleaning out a directory safer, as unlink(recursive=TRUE, dir(all=TRUE, dirToClean)) might start attacking dirToClean/.., then dirToClean/../.., etc., until your disk is empty. :-) Thank you, Bill. I agree that there is a problem. It seems wrong to me that dir(all.files=TRUE, recursive=TRUE, include.dirs=TRUE) *omits* the (symbolic) directories '.' and '..' when simple dir(all.files=TRUE) includes them. However, from a strict description (of the argument names, and also the help file) I would have expected that both would *include* rather than omit them. But then --the scenario abov, and also more general reasoning -- would rather suggest to follow your proposal. Martin dir.create(tdir - tempfile(tdir)) file.create(file.path(tdir, c(.dotFile, noDotFile))) [1] TRUE TRUE dir.create(file.path(tdir, .dotDir)) file.create(file.path(tdir, .dotDir, c(noDotFileInDotDir, .dotFileInDotDir))) [1] TRUE TRUE dir(tdir, all=TRUE) # omit . and .. here? [1] . .. .dotDir .dotFile [5] noDotFile dir(tdir, all=TRUE, recursive=TRUE, include.dirs=TRUE) [1] .dotDir .dotDir/.dotFileInDotDir [3] .dotDir/noDotFileInDotDir .dotFile [5] noDotFile Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken save(..., compress=xy)
Hervé Pagès hpa...@fhcrc.org
on Fri, 23 Sep 2011 11:44:32 -0700 writes:
On 11-09-23 11:02 AM, Sarah Goslee wrote:
Hi,
2011/9/23 Hervé Pagèshpa...@fhcrc.org:
Hi,
With current R devel and R 2.13.1:
aa=1:5 save(aa, file=aa.rda, compress=xy)
Error in identical(compress, gzip) || compress :
invalid 'y' type in 'x || y'
The options for compress are gzip bzip2 or xz (and
not xy), at least on my linux system. Are you sure you
want xy?
Right, I wanted xz, sorry... Maybe error handling could
be improved though so a typo in the input doesn't break
the code?
well, what every ' break the code ' means,
you are right that a more informative error message makes sense
here (though, the code now is slightly longer).
I've committed such a change {svn rev 57057}.
Martin
Thanks, H.
Sarah
Thanks! H.
sessionInfo()
R version 2.13.1 (2011-07-08) Platform:
x86_64-unknown-linux-gnu (64-bit)
locale: [1] LC_CTYPE=en_CA.UTF-8 LC_NUMERIC=C [3]
LC_TIME=en_CA.UTF-8 LC_COLLATE=en_CA.UTF-8 [5]
LC_MONETARY=C LC_MESSAGES=en_CA.UTF-8 [7]
LC_PAPER=en_CA.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
LC_TELEPHONE=C [11] LC_MEASUREMENT=en_CA.UTF-8
LC_IDENTIFICATION=C
attached base packages: [1] stats graphics grDevices
utils datasets methods base
--
--
Hervé Pagès
Program in Computational Biology Division of Public Health
Sciences Fred Hutchinson Cancer Research Center 1100
Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA
98109-1024
E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax: (206)
667-1319
__
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] load.R patch suggestion
Ben Bolker bbol...@gmail.com
on Thu, 15 Sep 2011 11:03:26 +0200 writes:
Inspired by
http://stackoverflow.com/questions/7487778/could-you-tell-me-what-this-error-means
I wrote the following very small (one-line) patch which
returns an *informative* error message when R tries to
load a zero-byte file rather than
Error in if (!grepl(RD[AX]2\n, magic)) { : argument is
of length zero
I would guess that error messages with the word magic
in them would be disturbing to new users, who are probably
worried already that R is magic ...
:-) indeed...
While it would not be a good idea to program around such error
messages in general, as each extra if(...) is executed everytime
the function is called, i.e. has a (albeit *very small*) penalty for
every correct call just for the sake of that message in the
erronous call case,
I do agree that it is worth here and so have added it (for
R-devel only).
Thank you, Ben.
Ben Bolker
--
Index: load.R
===
--- load.R(revision 56743)
+++ load.R(working copy)
@@ -25,6 +25,7 @@
## Since the connection is not open this opens it in binary mode
## and closes it again.
magic - readChar(con, 5L, useBytes = TRUE)
+if (length(magic)==0) stop(empty (zero-byte) file)
if (!grepl(RD[AX]2\n, magic)) {
## a check while we still know the call to load()
if(grepl(RD[ABX][12]\r, magic))
--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] are arithmetic comparison operators binary?
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Mon, 23 Feb 2009 19:29:31 +0100 writes:
WK Martin Maechler wrote:
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Mon, 23 Feb 2009 12:06:32 +0100 writes:
Thank you, Wacek,
though .. wrong mailing list
WK apologies. i was actually asking for explanation, assuming that it
WK might be my misunderstanding, rather than reporting a bug.
( yes; but it is really a technical topic, also touching on
extending R [below], hence -- R-devel )
WK the man page for relational operators (see, e.g., ?'') says:
WK
WK Binary operators which allow the comparison of values in atomic vectors.
WK Arguments:
WK x, y: atomic vectors, symbols, calls, or other objects for which
WK methods have been written.
WK
WK it is somewhat surprizing that the following works:
WK ''(1)
WK # logical(0)
WK ''()
WK # logical(0)
WK ''(1,2,3)
WK # TRUE
a bit surprising (sic!), indeed, even for me.
Thanks for your notice and report!
WK you're welcome.
WK shouldn't the tests have captured it? i think you should have a check
WK for every feature following from the docs.
yes, we should.
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to ..
.
R is a collaborative project with many contributors.
I think we'd gladly accept well-written commented extra
R-x.y.z/tests/foo.R
files or patches to existing ./tests/*.R
particularly if the contributor shows the new tests are
systematically covering currently untested areas...
Again: this really belongs to R-devel
-- I'm CCing there {and write a quick reply on R-help about
the mailing list redirection}
WK plus those undocumented, but assumed by the developers.
;-) :-)
Indeed, we are also grateful for (concise!) patches to man/*.Rd
help files.
If you'd looked a bit in the sources, you'd seen that they
really are supposed to be binary only.
WK it wouldn't be nonsensical to let them be of arbitrary arity (in a
WK well-documented manner), though it might confuse users.
Yes (to the latter). One of the beauties of S and R is the
syntax closeness to mathematical notation.
Many of us know that Lisp has beauties that S can never have,
but that's really in different beauty-space.
A very small change in the sources does accomplish this, passes
the standard checks (and I cannot imagine reasonable code that
would have relied on the more lenient behavior), so
this will have changed in one of the next versions of R-devel.
WK thanks.
WK just a question (i haven't checked the sources, maybe i should): what
WK is it that happens when one of the operators is called with n = 0 or 1
WK argument? how does it come up with logical(0) rather than NA?
In some of the cases e.g.
''(1)
it basically does [empty] 1 and hence returns the same as
NULL 1
Regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Semantics of sequences in R
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no on Tue, 24 Feb 2009 11:31:13 +0100 writes: WK Dimitris Rizopoulos wrote: in my opinion the point of the whole discussion could be summarized by the question, what is a design flaw? This is totally subjective, and it happens almost everywhere in life. Take human languages as an example and in particular, English. I do not know the history of the English language but I can guess at some point some people decided that the past tense for give should be gave and not gived according to the standard rule, possibly because they thought it has better acoustic. Is this a design flaw of English? Some might argue yes, maybe they would think gived does not have a that bad acoustic or they could have come up with another possibility than gave. Does this confuse new users of English? Of course it does -- I had to spent many hours learning the past tense and past particle of the irregular verbs. Should it be changed? Then almost all existing code (i.e., English texts) should be rewritten, which I think demonstrates why some people are a bit reluctant in design changes. To close I'd like to share with you a Greek saying (maybe also a saying in other parts of the world) that goes, for every rule there is an exception. The important thing, in my opinion, is that these exceptions are documented. WK all this is true; however, programming languages are not natural WK languages, there are substantial differences, and conclusions valid for WK natural languages are not necessarily valid for programming languages. You are are right, Wacek. However, Dimitris' comparison is still a valuable one, and I think I know that you don't quite agree : The S language has a long history and a relatively large user base that goes back many years (say 20). As you know, the vast majority are not professional programmers, not even semi-professional ones. Rather applied statisticians, scientists in many fields, also mathematicians, most very happy about how productively they can apply the S language by using R. The books they have written do exist however (namely mostly collections of R script files), and for almost all of them it would just lead to considerable frustration if one of the exceptions in the language was replaced by the rule in a way that makes their books contain typos. We very occasionally do this, i.e., back-incompatible improvements to R, inspite, but only rarely, when we are convinced that the costs (user frustration, need to re-write books) seem to be outweighed by the benefits. I think this is one of the big differences between (S and) R and other computer languages you've mentioned. So, indeed, Dimitris' parabola was more to the point than you may have appreciated. Hmm, but now let's return to something a bit more productive, please... Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected side effect of the ::: operator on the value of isGeneric
Wolfi == Wolfgang Huber hu...@ebi.ac.uk on Wed, 25 Feb 2009 18:15:03 + writes: Wolfi Hi, Wolfi when running the following on a fresh R, Wolfi library(IRanges) Wolfi annotation Wolfi showMethods(annotation) Wolfi Biobase:::annotation Wolfi showMethods(annotation) Wolfi I get (see the ^ marked output at the bottom): library(IRanges) Wolfi Carico il pacchetto richiesto: 'IRanges' Wolfi The following object(s) are masked from package:base : Wolfi cbind, Wolfi order, Wolfi pmax, Wolfi pmax.int, Wolfi pmin, Wolfi pmin.int, Wolfi rbind, Wolfi rep.int, Wolfi table annotation Wolfi standardGeneric for annotation defined from package IRanges Wolfi function (x, ...) Wolfi standardGeneric(annotation) Wolfi environment: 0x1a302b0 Wolfi Methods may be defined for arguments: x Wolfi Use showMethods(annotation) for currently available ones. showMethods(annotation) Wolfi Function: annotation (package IRanges) Wolfi x=AnnotatedList Biobase:::annotation Wolfi standardGeneric for annotation defined from package Biobase Wolfi function (object) Wolfi standardGeneric(annotation) Wolfi environment: 0x205cee0 Wolfi Methods may be defined for arguments: object Wolfi Use showMethods(annotation) for currently available ones. showMethods(annotation) Wolfi Function annotation: Wolfi not a generic function Wolfi ^^^ Wolfi It seems that the value of isGeneric(annotation), when it is called Wolfi within showMethods, is FALSE, while it is TRUE when called outside. Hi Wolfgang, I have looked at the NAMESPACE files of the two packages Biobase and IRanges, (the Bioconductor development version in SVN), and I think the problem might result from the fact that IRanges does export the annotation generic, does not exportMethods( ... annotation ...). OTOH, Biobase exportMethods( annotation ) only [but not the generic]. and then both packages do not at all mention each other, neither in DESCRIPTION nor NAMESPACE. Either you are talking about conceptually the same generic annotation(); in that case one package needs to import*() it from the other, or then you have two completely different animals, but then (masking) problems are unavoidable -- in spite of the fact that I vaguely remember that some Bioconductor developers repeatedly emphasize that these problems are not problems for them Martin sessionInfo() Wolfi R version 2.9.0 Under development (unstable) (2009-02-25 r48007) Wolfi x86_64-unknown-linux-gnu Wolfi locale: Wolfi LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C Wolfi attached base packages: Wolfi [1] stats graphics grDevices utils datasets methods base Wolfi other attached packages: Wolfi [1] IRanges_1.1.40 Wolfi loaded via a namespace (and not attached): Wolfi [1] Biobase_2.3.10 Wolfi Best wishes Wolfi Wolfgang Wolfi -- Wolfi Wolfgang Huber EBI/EMBL Cambridge UK http://www.ebi.ac.uk/huber Wolfi __ Wolfi R-devel@r-project.org mailing list Wolfi 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] Unexpected side effect of the ::: operator on the value of isGeneric
Wolfi == Wolfgang Huber hu...@ebi.ac.uk on Sat, 28 Feb 2009 18:01:19 + writes: Wolfi Dear Martin name masking is a separate issue, which I Wolfi do not want to explore here. Wolfi If one accepts the notion that unrelated generics of Wolfi the same name may exist in different namespaces (user Wolfi confusion aside, I don't see a technical reason why Wolfi one shouldn't), then I find the behaviour of R in the Wolfi below case puzzling: the value of Wolfi showMethods(something) called from the global Wolfi environment depends on whether or not the expression Wolfi package::something has previously been Wolfi evaluated. The value of isGeneric(something) is Wolfi different when called from top-level and when called Wolfi within showMethods. Wolfi Best wishes Wolfgang Wolfi PS1: I do apologize if this behaviour is intentional, Wolfi and documented somewhere. I would then be puzzled Wolfi even more though. Wolfi PS2: My code example used :::, and there are some Wolfi vague warnings in its man page that ::: is Wolfi dangerous. The problem also occurs with ::. Thank you, Wolfgang (and Martin Morgan), for the clarification, here and off-line. Just for a public summary: You have convinced me that this is indeed pointing to a bug in the current R implementation, and IIUC, at least one expert (JMC) is looking at a fix. Regards, Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] array subsetting of S4 object that inherits from array
BB == Bradley Buchsbaum bbuchsb...@berkeley.edu on Thu, 5 Mar 2009 21:16:40 -0500 writes: BB Hi, BB I have an S4 class that inherits from array but does not add generic BB implementations of the [ method. BB A simplified example is: BB setClass(fooarray, contains=array) BB If I create a fooarray object and subset it with a one-dimensional BB index vector, the return value is of class fooarray. Other variants BB (see below), however, return primitive values consistent with BB ordinary array subsetting. BB x - new(fooarray, array(0,c(10,10,10))) BB class(x[1,1,1])# prints numeric BB class(x[1,,]) # prints matrix BB class(x[1]) # prints fooarray BB class(x[1:10])# prints fooarray BB This behavior seems to have been introduced in R2.8.1 as I have not BB encountered it before. I tested it on R.2.7.0 and confirmed that BB class(x[1]) returned numeric. BB In my case, the desired behavior is for array subsetting in all cases BB to return primitive data structures, so if there is a way to override BB the new behavior I would opt for that. Yes, the new behavior was introduced (into R 2.8.0) by me, and ... coincidence ?! ... two days ago, in e-talking with John Chambers, I have been convinced, that the new feature really has been a mis-feature. Consequentley, yesterday (!) I'v committed changes to both R-patched (2.8.1 patched) and R-devel which we revert the mis-feature. So, the override is to use 2.8.1 patched (or newer). I'm sorry for my thinko that may also affect other R-S4-programmers [of course I hope not, but then there's Murphy's law]. Regards, Martin Maechler, ETH Zurich BB Regards, BB Brad Buchsbaum BB R version 2.8.1 (2008-12-22) BB i386-pc-mingw32 BB locale: BB LC_COLLATE=English_United States.1252;LC_CTYPE=English_United BB States.1252;LC_MONETARY=English_United BB States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 BB attached base packages: BB [1] stats graphics grDevices utils datasets methods base BB -- BB Bradley R. Buchsbaum BB Rotman Research Institute BB 3560 Bathurst St. BB Toronto, ON Canada M6A 2E1 BB email: bbuchsb...@rotman-baycrest.on.ca BB __ BB R-devel@r-project.org mailing list BB 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] Putting demo shell scripts, text files, and RScript files with a package?
DR == David Rosenberg dro...@stat.berkeley.edu
on Tue, 17 Mar 2009 13:25:46 -0400 writes:
DR I've written a package to assist with using R in Hadoop Streaming.
DR The main point of the package is to help make command-line runnable
DR RScript files. I'd like to provide a demo RScript file, a demo data
DR file (e.g. a plaintext file, not something already processed by R) ,
DR as well as demo bash shell scripts that demonstrate how to run the job
DR from the command line and in a Hadoop cluster.
DR My best idea so far for distributing these files is to package the
DR contents of these files as a list of strings in a data file in the
DR data directory, and include a function in the package, say
DR generateDemoFolder(targetDir), that writes the files to a user-
DR specified directory, ready for use from the command line.
I think you've overlooked the possibility of sourcePkg/inst/
I would use something like sourcePkg/inst/scripts/
which will become installedPkg/scripts/
[accessible from within R by system.file(scripts, package= yourPkg)
One famous example being the R scripts for VenablesRipley's
MASS book, available from all R installations via
system.file(scripts, package=MASS)
e.g.
list.files(system.file(scripts, package=MASS))
[1] ch01.R ch02.R ch03.R ch04.R ch05.R ch06.R ch07.R ch08.R
ch09.R
[10] ch10.R ch11.R ch12.R ch13.R ch14.R ch15.R ch16.R
or
source(system.file(scripts, ch01.R, package=MASS))
{ which ends in an error: It's not made for source();
it might well be source()able if
'if(interactive()) ' where replaced by
'if(dev.interactive()) '
}
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion/request: install.packages and unnecessary file modifications
Thank you, Mark,
I've now committed (a version of) your suggestion to R-devel
(destined to become R 2.9.0 on April 17).
Martin Maechler, ETH Zurich
mark.braving...@csiro.au
on Tue, 10 Mar 2009 21:52:30 +1100 writes:
Dear R-devel
When 'install.packages' runs, it updates all html files in all packages.
Mostly, there seems to be no actual change to the html file contents, but the
date/time does change. This has causing been me a bit of trouble, because I
keep synchronized versions of R on several different machines, and whenever I
install a package, many MB of file transfers are required; my slow upload link
can't cope.
The culprit appears to be 'utils:::fixup.package.URLs'. Adding the
commented lines below, near the end of the function, avoids the unnecessary
rewrite.
Mark Bravington
CSIRO
Hobart
Australia
for (f in files) {
page - readLines(f)
old.page - page # MVB
page - gsub(olddoc, doc, page, fixed = TRUE, useBytes = TRUE)
page - gsub(oldbase, base, page, fixed = TRUE, useBytes = TRUE)
page - gsub(oldutils, utils, page, fixed = TRUE, useBytes = TRUE)
page - gsub(oldgraphics, graphics, page, fixed = TRUE,
useBytes = TRUE)
page - gsub(oldstats, stats, page, fixed = TRUE, useBytes = TRUE)
page - gsub(olddata, datasets, page, fixed = TRUE, useBytes = TRUE)
page - gsub(oldgrD, grD, page, fixed = TRUE, useBytes = TRUE)
page - gsub(oldmeth, meth, page, fixed = TRUE, useBytes = TRUE)
if( identical( page, old.page)) # MVB
next # MVB
out - try(file(f, open = w), silent = TRUE)
if (inherits(out, try-error)) {
warning(gettextf(cannot update '%s', f), domain = NA)
next
}
writeLines(page, out)
close(out)
}
return(TRUE)
}
__
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] incoherent treatment of NULL
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no on Mon, 23 Mar 2009 09:52:19 +0100 writes: WK somewhat related to a previous discussion [1] on how 'names-' would WK sometimes modify its argument in place, and sometimes produce a modified WK copy without changing the original, here's another example of how it WK becomes visible to the user when r makes or doesn't make a copy of an WK object: WK x = NULL WK dput(x) WK # NULL WK class(x) = 'integer' WK # error: invalid (NULL) left side of assignment does not happen for me in R-2.8.1, R-patched or newer So you must be using your own patched version of R ? WK x = c() WK dput(x) WK # NULL WK class(x) = 'integer' WK dput(x) WK # integer(0) WK in both cases, x ends up with the value NULL (the no-value object). in WK both cases, dput explains that x is NULL. in both cases, an attempt is WK made to make x be an empty integer vector. the first fails, because it WK tries to modify NULL itself, the latter apparently does not and succeeds. WK however, the following has a different pattern: WK x = NULL WK dput(x) WK # NULL WK names(x) = character(0) WK # error: attempt to set an attribute on NULL WK x = c() WK dput(x) WK # NULL WK names(x) = character(0) WK # error: attempt to set an attribute on NULL WK and also: WK x = c() WK class(x) = 'integer' WK # fine WK class(x) = 'foo' WK # error: attempt to set an attribute on NULL WK how come? the behaviour can obviously be explained by looking at the WK source code (hardly surprisingly, because it is as it is because the WK source is as it is), and referring to the NAMED property (i.e., the WK sxpinfo.named field of a SEXPREC struct). but can the *design* be WK justified? can the apparent incoherences visible above the interface be WK defended? WK why should the first example above be unable to produce an empty integer WK vector? WK why is it possible to set a class attribute, but not a names attribute, WK on c()? WK why is it possible to set the class attribute in c() to 'integer', but WK not to 'foo'? WK why are there different error messages for apparently the same problem? WK vQ WK [1] search the rd archives for 'surprising behaviour of names-' WK __ WK R-devel@r-project.org mailing list WK https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
