Re: [Rd] Minimum of an ordered factor
> Martin Maechler writes:
I have 3 comments:
> Thaler, Thorn, LAUSANNE, Applied Mathematics
>
> 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.
Same for me.
>> Of course I can do something like
>> sort(z[u>4])[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))) {
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]
>> 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)
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.
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.
Best
-k
> Thank you, Thorn!
> With regards,
> Martin Maechler, ETH Zurich
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scoping/non-standard evaluation issue
the following seems an easy solution:
f1 <- function(mod){
subs <- 1:10
toeval <- quote(update(mod, subset=subs))
toeval$subset<-subs
eval(toeval)
}
f1(mod.2)
When experimenting with this I once had (by mistake):
mod.2 <- lm(update(mod.1, . ~ . - Year + Year)) # instead of just
update(this)
... and this helped, too, i.e. f(mod.2) worked.
Best regards,
Kenn
Kenn Konstabel
Department of Chronic Diseases
National Institute for Health Development
Hiiu 42
Tallinn, Estonia
On Tue, Jan 4, 2011 at 11:35 PM, John Fox wrote:
> Dear r-devel list members,
>
> On a couple of occasions I've encountered the issue illustrated by the
> following examples:
>
> - snip ---
>
> > mod.1 <- lm(Employed ~ GNP.deflator + GNP + Unemployed +
> + Armed.Forces + Population + Year, data=longley)
>
> > mod.2 <- update(mod.1, . ~ . - Year + Year)
>
> > all.equal(mod.1, mod.2)
> [1] TRUE
> >
> > f <- function(mod){
> + subs <- 1:10
> + update(mod, subset=subs)
> + }
>
> > f(mod.1)
>
> Call:
> lm(formula = Employed ~ GNP.deflator + GNP + Unemployed + Armed.Forces +
>Population + Year, data = longley, subset = subs)
>
> Coefficients:
> (Intercept) GNP.deflator GNPUnemployed Armed.Forces
> 3.641e+03 8.394e-03 6.909e-02-3.971e-03-8.595e-03
> Population Year
> 1.164e+00-1.911e+00
>
> > f(mod.2)
> Error in eval(expr, envir, enclos) : object 'subs' not found
>
> - snip ---
>
> I *almost* understand what's going -- that is, clearly mod.1 and mod.2, or
> the formulas therein, are associated with different environments, but I
> don't quite see why.
>
> Anyway, here are two "solutions" that work, but neither is in my view
> desirable:
>
> - snip ---
>
> > f1 <- function(mod){
> + assign(".subs", 1:10, envir=.GlobalEnv)
> + on.exit(remove(".subs", envir=.GlobalEnv))
> + update(mod, subset=.subs)
> + }
>
> > f1(mod.1)
>
> Call:
> lm(formula = Employed ~ GNP.deflator + GNP + Unemployed + Armed.Forces +
>Population + Year, data = longley, subset = .subs)
>
> Coefficients:
> (Intercept) GNP.deflator GNPUnemployed Armed.Forces
> 3.641e+03 8.394e-03 6.909e-02-3.971e-03-8.595e-03
> Population Year
> 1.164e+00-1.911e+00
>
> > f1(mod.2)
>
> Call:
> lm(formula = Employed ~ GNP.deflator + GNP + Unemployed + Armed.Forces +
>Population + Year, data = longley, subset = .subs)
>
> Coefficients:
> (Intercept) GNP.deflator GNPUnemployed Armed.Forces
> 3.641e+03 8.394e-03 6.909e-02-3.971e-03-8.595e-03
> Population Year
> 1.164e+00-1.911e+00
>
> > f2 <- function(mod){
> + env <- new.env(parent=.GlobalEnv)
> + attach(NULL)
> + on.exit(detach())
> + assign(".subs", 1:10, pos=2)
> + update(mod, subset=.subs)
> + }
>
> > f2(mod.1)
>
> Call:
> lm(formula = Employed ~ GNP.deflator + GNP + Unemployed + Armed.Forces +
>Population + Year, data = longley, subset = .subs)
>
> Coefficients:
> (Intercept) GNP.deflator GNPUnemployed Armed.Forces
> 3.641e+03 8.394e-03 6.909e-02-3.971e-03-8.595e-03
> Population Year
> 1.164e+00-1.911e+00
>
> > f2(mod.2)
>
> Call:
> lm(formula = Employed ~ GNP.deflator + GNP + Unemployed + Armed.Forces +
>Population + Year, data = longley, subset = .subs)
>
> Coefficients:
> (Intercept) GNP.deflator GNPUnemployed Armed.Forces
> 3.641e+03 8.394e-03 6.909e-02-3.971e-03-8.595e-03
> Population Year
> 1.164e+00-1.911e+00
>
> - snip ---
>
> The problem with f1() is that it will clobber a variable named .subs in the
> global environment; the problem with f2() is that .subs can be masked by a
> variable in the global environment.
>
> Is there a better approach?
>
> Thanks,
> John
>
>
> John Fox
> Senator William McMaster
> Professor of Social Statistics
> Department of Sociology
> McMaster University
> Hamilton, Ontario, Canada
> web: socserv.mcmaster.ca/jfox
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scoping/non-standard evaluation issue
On Jan 6, 2011, at 13:11 , Kenn Konstabel wrote:
> the following seems an easy solution:
>
> f1 <- function(mod){
> subs <- 1:10
> toeval <- quote(update(mod, subset=subs))
> toeval$subset<-subs
> eval(toeval)
> }
>
> f1(mod.2)
Tere, Kenn!
Yes, enforcing pass-by-value by pre-evaluating the argument will certainly
defeat the nonstandard evaluation issues. Another version of the same idea is
eval(bquote(update(mod, .(subs)))
The only thing is that if the argument is ever deparsed, you might get a messy
display. E.g., try eval(bquote(plot(.(rnorm(20)
-pd
--
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
Re: [Rd] Minimum of an ordered factor
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]
Yes definitely. This line is in fact just a relic from a previous idea I
had.
> 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.
>
> 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.
Sounds reasonable. Ack.
BR Thorn
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo in R language definition manual
on line 1714 of R-lang.texi (current SVN of R-devel, 53919)
@code{x$aa} will match @code{x$aabb} if @code{x} does not a component
should probably have "contain" or "have" inserted after "not"
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formula(model.frame(y~.^2, data=d)) does not return formula from terms attribute of the model.frame
In R 2.12.0 I get
> d <- data.frame(x=1:10, y=log(1:10), f3=LETTERS[rep(1:3,c(3,3,4))])
> m <- model.frame(y~.^2, data=d)
> formula(m)
y ~ x + f3
In S+ formula(m) gives formula given to model.frame(),
but in R you have to do the following get that formula:
> formula(attr(m, "terms"))
y ~ (x + f3)^2
Would it break anything to add to the top of formula.data.frame
something like
if (!is.null(tms <- attr(x, "terms"))) {
return(formula(tms))
}
so that formula() would retrieve the formula buried
in model.frame's output?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Indexing request
I just tried ?Constants at the console and was disappointed that the so-named base help page would not come up. > ?Constants No documentation for 'Constants' in specified packages and libraries: you could try '??Constants' Seems like there should have been a match. I was looking for the month abbreviations, failing to hit the right name 4 times and then failing 3 more times on variations of what I remembered to be the name of that page and finally ended up typing: ?letters -- David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Indexing request
Yes, odd that ?Constants doesn't work, given that there is a page labeled
Constants {base}.
On a happier note, these all work now on my Mac R version 2.11.1
> ?base
> ?stats
> ?utils
though Constants is not an entry in the index.
R help gurus - is it possible to have entries such as "Constants"
for such help pages that discuss multiple functions?
On further poking around I do see an index entry for "assignOps"
for page assignOps {base} so the answer is obviously "yes".
I guess it's now a matter of providing a patch or convincing
an R developer to do so in his copious spare time :)
Steven McKinney
Statistician
Molecular Oncology and Breast Cancer Program
British Columbia Cancer Research Centre
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of David Winsemius [dwinsem...@comcast.net]
Sent: January 6, 2011 9:08 PM
To: r-de...@stat.math.ethz.ch
Subject: [Rd] Indexing request
I just tried ?Constants at the console and was disappointed that the
so-named base help page would not come up.
> ?Constants
No documentation for 'Constants' in specified packages and libraries:
you could try '??Constants'
Seems like there should have been a match. I was looking for the month
abbreviations, failing to hit the right name 4 times and then failing
3 more times on variations of what I remembered to be the name of that
page and finally ended up typing:
?letters
--
David Winsemius, MD
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
