Re: [Rd] rank(, ties.method="last")
Den 2015-10-09 kl. 12:14, skrev Martin Maechler:
I ran into a problem where I actually need rank(, ties.method="last"). It would
be great to have this feature in base and it's also simple to get (see below).
Thanks & cheers,
Marius
rank2 <- function (x, na.last = TRUE, ties.method = c("average",
"first", "last", # new "last"
"random", "max", "min"))
{
nas <- is.na(x)
nm <- names(x)
ties.method <- match.arg(ties.method)
if (is.factor(x))
x <- as.integer(x)
x <- x[!nas]
y <- switch(ties.method, average = , min = , max = .Internal(rank(x,
length(x), ties.method)), first = sort.list(sort.list(x)),
last = sort.list(sort.list(x, decreasing=TRUE), decreasing=TRUE), #
change
random = sort.list(order(x, stats::runif(sum(!nas)
if (!is.na(na.last) && any(nas)) {
yy <- NA
NAkeep <- (na.last == "keep")
if (NAkeep || na.last) {
yy[!nas] <- y
if (!NAkeep)
yy[nas] <- (length(y) + 1L):length(yy)
}
else {
len <- sum(nas)
yy[!nas] <- y + len
yy[nas] <- seq_len(len)
}
y <- yy
names(y) <- nm
}
else names(y) <- nm[!nas]
y
}
## MWE
x <- c(10, 11, 11, 12, 12, 13)
rank(x, ties.method="first")
rank2(x, ties.method="last")
Indeed, this makes sense to me, and is easy enough to document
and maintain, and preferable to asking useRs to use rev(.) and
similar "easy" (but somewhat costly for large data!)
transformations to get the same
Or have (Marius Hofert and I) overlooked something obvious ?
I think so: the code above doesn't seem to do the right thing. Consider
the following example:
> x <- c(1, 1, 2, 3)
> rank2(x, ties.method = "last")
[1] 1 2 4 3
That doesn't look right to me -- I had expected
> rev(sort.list(x, decreasing = TRUE))
[1] 2 1 3 4
Henric Winell
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] rank(, ties.method="last")
On Tue, Oct 20, 2015 at 10:26 AM, Henric Winell wrote: > Den 2015-10-09 kl. 12:14, skrev Martin Maechler: > I think so: the code above doesn't seem to do the right thing. Consider > the following example: > > > x <- c(1, 1, 2, 3) > > rank2(x, ties.method = "last") > [1] 1 2 4 3 > > That doesn't look right to me -- I had expected > > > rev(sort.list(x, decreasing = TRUE)) > [1] 2 1 3 4 > Indeed, well spotted, that seems to be correct. > > Henric Winell > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conditional importFrom (roxygen?)
>> This has been submitted as an issue at >> >> https://github.com/klutometis/roxygen/issues/378 >> >> closely related: >> >> https://github.com/klutometis/roxygen/issues/371 >> >> my current hacky solution to this is to use a Makefile that >> post-processes the NAMESPACE after it's roxygenized, e.g. search >> for "getRversion" in >> >> https://github.com/glmmTMB/glmmTMB/blob/master/Makefile > > Hadley has the right idea (allow roxygen to specify some uninterpreted > text to drop into the NAMESPACE file), but it doesn't go far enough. > Really this is a design flaw in roxygen: being able to enter NAMESPACE > and help page info in source files is a great feature, but being forced > to go all or nothing is a flaw. > > If base R adds something new to the NAMESPACE or .Rd files (or has some > obscure feature that roxygen authors didn't notice), it's really hard > for roxygen users to make use of it. It should much easier in the dev version - you can use @rawRd and @rawNamespace to insert literal Rd code and NAMESPACE directives without any interpretation by roxygen. > A better design would be to allow content from both sources: some > manually entered NAMESPACE stuff, and some automatically generated stuff. I think you can now mostly do this - it might be possible to do more intermingling, but it starts to get really hard to figure out which is the authoritative version and to respond usefully to conflicts. I'm not opposed to the idea, but it's a hard problem and unfortunately not very high on my priority list. > A really nice design would be to read the manually entered stuff and > show (some of?) it in the .R files, but that would be really tricky to > get right. I think it would need to be supported by a GUI, it wouldn't > be reasonable to expect people to type it all properly in a dumb editor. > Maybe Hadley knows someone who has written a GUI? Nope, sorry :P More seriously, again I think it would be possible, and it's not that I'm opposed to it, but realistically, it's unlikely to ever get high enough up our priority list to get implemented. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rank(, ties.method="last")
Marius Hofert-4-- > Den 2015-10-09 kl. 12:14, skrev Martin Maechler: > I think so: the code above doesn't seem to do the right thing. Consider > the following example: > > > x <- c(1, 1, 2, 3) > > rank2(x, ties.method = "last") > [1] 1 2 4 3 > > That doesn't look right to me -- I had expected > > > rev(sort.list(x, decreasing = TRUE)) > [1] 2 1 3 4 > Indeed, well spotted, that seems to be correct. > > Henric Winell > -- In the particular example (of length 4), what is really wanted is the following. ind <- integer(4) ind[sort.list(x, decreasing=TRUE)] <- 4:1 ind The following gives the desired result: sort.list(rev(sort.list(x, decreasing=TRUE))) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
