similar to: findInterval Documentation Suggestion

> On Friday, March 6, 2020, 8:56:54 AM EST, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > Note that the? * -> LaTex -> PDF rendered version looks a bitnicer. Ah yes, that does indeed look quite a bit nicer. > I wrote the function and that help page originally. And thank you for doing so. It is a wonderful function. (0 sarcasm here). > For that reason,

>>>>> brodie gaslam via R-devel >>>>> on Thu, 5 Mar 2020 22:18:33 +0000 (UTC) writes: > I've found over time that R documentation that comes off as terse at > first blush is usually revealed to be precise, concise, and complete > on close reading.? I'm sure this is also true of `?findInterval`, but > for whatever reason my

What should findInterval(x,vec,all.inside=TRUE) return when length(vec)<=1, so there are no inside intervals? R-3.3.0 gives a decreasing map of x->output when length(vec)==1 and -1's when length(vec)==0. Would '0' in all those cases be better? > findInterval(x=c(10, 11, 12), vec=11, all.inside=TRUE, rightmost.closed=FALSE, left.open=FALSE) [1] 1 0 0 >

Dear R users, the help for findInterval(x,vec) suggests a logarithmic dependence on N (=length(vec)), which would imply a binary search type algorithm. However, when I "test" this hypothesis, in the following manner: set.seed(-3645); l <- vector(); N.seq <- c(5000, 500000, 1000000, 10000000, 50000000);k <- 1 for (N in N.seq){ tmp <- sort(round(stats::rt(N, df=2), 2));

Hello Wise Ones... I need a clever way around a problem with findInterval. Consider: vec1 <- 1:10 vec2 <- seq(1, 10, by = 0.1) x1 <- c(2:3) a1 <- findInterval(x1, vec1); a1 # example 1 a2 <- findInterval(x1, vec2); a2 # example 2 In the problem I'm working on, vec* may be either integer or numeric, like vec1 and vec2. I need to remove one or more sections of this vector;

Dear R Community, I hope you might be able to assist with a small problem creating a function. I am working with water-quality data sets that contain the concentration of many different elements in water samples. I need to assign quality-control flags to values that fall into various concentration ranges. Rather than a web of nested if statements, I am employing the findInterval function to

On 27 November 2016 at 13:20, Duncan Murdoch wrote: | On 27/11/2016 11:34 AM, brodie gaslam via R-devel wrote: | > Minor issue, but the following changed as of R3.3.2 from: | > | > > a <- function() b() | > > a() | > Error in a() : could not find function "b" | > | > To (at least in R Under development (unstable) (2016-11-20 r71670)): | > |

Minor issue, but the following changed as of R3.3.2 from: > a <- function() b() > a() Error in a() : could not find function "b" To (at least in R Under development (unstable) (2016-11-20 r71670)): Error in b() : could not find function "b" Notice the "Error in **b**() :" part. The original error message seems more correct to me, although

Thanks Brodie, that's some nice detective work. If someone wanted to grant me access to Bugzilla, I'll be happy to post the bug and patch there (with your permission Brodie?) and help this bug get fixed. Mike. On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <brodie.gaslam at yahoo.com> wrote: > > > For what it's worth the following patch fixes that particular problem

Is there a generic binary search routine in a standard library which a) works for character vectors b) runs in O(log(N)) time? I'm aware of findInterval(x,vec), but it is restricted to numeric vectors. I'm also aware of various hashing solutions (e.g. new.env(hash=TRUE) and fastmatch), but I need the greatest-lower-bound match in my application. findInterval is also slow for

Hi all, I am writing some C code where I want to use the findInterval function documented in "Writing R extensions/Utility functions". i.e. the C-version not the R version. It all compiles but the shared library is causing seg-faults and I'm obviously stuffing something up. Has anyone got any examples of calling this function they'd be will to share? I've searched through

> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard <pdalgd at gmail.com> wrote: > > Expected, see FAQ 7.31. > > You just can't trust == on FP operations. Notice also Additionally, since you're implementing a "mean" function you are testing against R's mean, you might want to consider that R uses a two-pass calculation[1] to reduce floating

Hi there, using cbind with a numeric and raw argument produces an incorrect result. I've posted some details below, kind regards, Mike. e.g. > cbind(0, as.raw(0)) [,1] [,2] [1,] 0 6.950136e-310 A longer example shows that the result is not a rounding error, is not consistent, and repeated applications get different results. > cbind(0, as.raw(1:10))

I think there is a memory bug in `substr` that is triggered by a UTF-8 corner case: an incomplete UTF-8 byte sequence at the end of a string.? With a valgrind level 2 instrumented build of R-devel I get: > string <- "abc\xEE"??? # \xEE indicates the start of a 3 byte UTF-8 sequence > Encoding(string) <- "UTF-8" > substr(string, 1, 10) ==15375== Invalid read of

I noticed some problems that cropped in the latest versions of R-devel (2016-11-08 r71639 in my case) for one of my packages. I _think_ I have narrowed it down to the changes to what gets byte-compiled by default. The following example run illustrates the problem I'm having: compiler::enableJIT(0) fun <- function(x) local(as.list(parent.frame(2))) fun(1) ## $x ## [1] 1 ##

One of the things I often wish R would work with: When calling print() explicitly --- as I do not so rarely, e.g., specifying digits = <nd> --- it sometimes seems awkward that from the printing options() , one can specify 'digits' and it has default digits = NULL which is documented to be equivalent to digits = getOption("digits"), but one cannot specify 'width'

> On Friday, May 15, 2020, 12:13:04 PM EDT, Dirk Eddelbuettel <edd at debian.org> wrote: > On 15 May 2020 at 15:41, Martin Maechler wrote: > | <whining> > | > |??? Why does nobody anymore? help R development by working with > |??? "R-devel", or at least then the alpha, beta and the "RC" > |??? (Release Candidate) versions that we release daily

In 1.4 Contexts[1], should the following: > Note that whilst calls to closures and builtins set a context, > those to special internal functions never do. Be something like: > Note that whilst calls to closures always set a context, > those to builtins only set a context under profiling > or if they are of the foreign variety (e.g `.C` and similar), > and those to special

Luke, thanks for considering the issue.? I would like to try to separate the problem into two parts, as I _think_ your comments address primarily part 2 below: 1. How can we avoid significant and possibly crippling ?? stalls on error with these non-standard calls. 2. What is the best way to view these non-standard calls. I agree that issue 2. requires further thought and discussion under a

The build system rolled up R-4.0.2.tar.gz (codename "Taking Off Again") this morning. The list below details the changes in this release. You can get the source code from http://cran.r-project.org/src/base/R-4/R-4.0.2.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team, Peter Dalgaard