similar to: Regular Expression and Pmatch

On Aug 28, 2009, at 1:53 AM, Daniel Dunbar wrote: > Nice! > > This looks good to me but probably Chris or someone else should sign > off on it. This seems ok to me, please commit. One minor comment: +++ b/lib/Support/Regex.cpp + // Allocate pmatch with at least one element. + pmatch = new llvm_regmatch_t[nmatch > 0 ? nmatch : 1]; + pmatch[0].rm_so = 0; + pmatch[0].rm_eo =

The pmatch help (see also section 4.3.2 in the R Language Definition) claims that pmatch with duplicates.ok=FALSE provides the same functionality as R's argument matching algorithm, modulo how empty strings are matched. Here's an undocumented inconsistency between pmatch and R's argument matching algorithm: > sessionInfo() R version 3.0.1 (2013-05-16) Platform:

I am using R0.64.1 under Windows 95. The help for `pmatch' states that: If `duplicates.ok' is false multiple matches will result in the value of `nomatch' being returned, and if it is true, the index of the first matching value will be returned. The help for pmatch gives the following examples: pmatch("m", c("mean",

Nice! This looks good to me but probably Chris or someone else should sign off on it. There were two minor warnings on Darwin: -- In file included from /Volumes/Data/Users/ddunbar/llvm/lib/Support/regexec.c:81: /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc: In function 'sbackref': /Volumes/Data/Users/ddunbar/llvm/lib/Support/regengine.inc:665: warning: control reaches end of

Hello R Helpers, Business - 64 bit windows 7, R 2.11.1 I am trying to match the character contents of one list, called 'exclude', to those of a second list, called 'dataset' dataset is a list of file names with folder locations, and looks like this when called: > dataset [1] "A/10-10-29a-13.cdf" "A/10-10-29a-14.cdf" "A/10-10-29a-15.cdf"

I observed the following: match.arg("white", colors()) yields 'white', but match.arg("whit", colors()) yields: `Error in match.arg("whit", colors()) : 'arg' should be one of "white", "aliceblue", '... this message actually comes from `pmatch'. using a suitable subset of `colors()' works OK. the precise length

Hi, Somebody asked me to make sure that all the machines running the in our lab (XP and Linux, both running 2.0) have R installed and that A) All the packages are installed and B) kept up-to-date. Obediently, I began to modify a shared Rprofile so that once a week it checks for new packages and updates to the current version of the installed packages on CRAN. Sounds simple enough. Plus some

On 2009-08-30 03:55, Chris Lattner wrote: > > On Aug 28, 2009, at 1:53 AM, Daniel Dunbar wrote: > >> Nice! >> >> This looks good to me but probably Chris or someone else should sign >> off on it. > > This seems ok to me, please commit. One minor comment: Committed. It would be useful if someone could test if this works on Windows, the msvc buildbot was all

On 2009-08-25 21:18, Daniel Dunbar wrote: > Woot! Thanks a bunch Edwin! > > Some comments on the patch: > -- > I'm not sure if it makes sense to import the man pages, if we only > expose Regex.h. > I'd like to keep re_format.7, it describes the format of the regex as accepted by this implementation. I'll remove regex.3 since its not exposed. > >>

Woot! Thanks a bunch Edwin! Some comments on the patch: -- I'm not sure if it makes sense to import the man pages, if we only expose Regex.h. > diff --git a/include/llvm/Support/Regex.h b/include/llvm/Support/Regex.h > new file mode 100644 > index 0000000..314bff4 > --- /dev/null > +++ b/include/llvm/Support/Regex.h > @@ -0,0 +1,49 @@ > +//===-- Regex.h - Regular

2009/8/25 Török Edwin <edwintorok at gmail.com>: > On 2009-08-25 21:18, Daniel Dunbar wrote: >> Woot! Thanks a bunch Edwin! >> >> Some comments on the patch: >> -- >> I'm not sure if it makes sense to import the man pages, if we only >> expose Regex.h. >> > > I'd like to keep re_format.7, it describes the format of the regex as >

On 2009-08-27 09:06, Daniel Dunbar wrote: > 2009/8/25 Török Edwin <edwintorok at gmail.com>: > >> On 2009-08-25 21:18, Daniel Dunbar wrote: >> >>> Woot! Thanks a bunch Edwin! >>> >>> Some comments on the patch: >>> -- >>> I'm not sure if it makes sense to import the man pages, if we only >>> expose Regex.h.

On Wed, 13 Dec 2023 09:04:18 +0100 Hilmar Berger via R-devel <r-devel at r-project.org> wrote: > Still, I feel that default partial matching cripples the functionality > of data.frame for larger tables. Changing the default now would require a long deprecation cycle to give everyone who uses `[.data.frame` and relies on partial matching (whether they know it or not) enough time to

Hi Hilmar and Ivan, I have used your code examples to write a blog post about this topic, which has figures that show the asymptotic time complexity of the various approaches, https://tdhock.github.io/blog/2023/df-partial-match/ The asymptotic complexity of partial matching appears to be quadratic O(N^2) whereas the other approaches are asymptotically faster: linear O(N) or log-linear O(N log N).

Hi folks, Can anyone suggest an efficient way to do "matching without replacement", or "one-to-one matching"? pmatch() doesn't quite provide what I need... For example, lookupTable <- c("a","b","c","d","e","f") matchSample <- c("a","a","b","d") ##Normal match()

On 2009-08-24 20:14, Chris Lattner wrote: > On Aug 23, 2009, at 11:59 PM, Török Edwin wrote: >> If LLVM is going to have an integrated regex library I suggest using it >> regardless if the platform has one. >> The LLVM integrated regex library will provide consistent behaviour and >> execution time, the system one will not. > > Hi Edwin, > > Can you propose

Hi, A noobie question: I'm simply trying to run a conditional statement that evaluates if a substring is found within a larger string. I find that if it IS found, my function returns TRUE (great!), but if not, the condition does not evaluate to FALSE. ex): if( grep("hi", "hop", fixed = TRUE) ) print('yes, your substring is in your string') else

On Aug 23, 2009, at 11:59 PM, Török Edwin wrote: > If LLVM is going to have an integrated regex library I suggest using > it > regardless if the platform has one. > The LLVM integrated regex library will provide consistent behaviour > and > execution time, the system one will not. Hi Edwin, Can you propose the openbsd implementation as a patch to lib/support? -Chris

Hi all, This occurred in R-2.11.0 (WinXP). The R-help page of .[ says that: "Character indices can in some circumstances be partially matched (see pmatch) to the names or dimnames of the object being subsetted (but never for subassignment). Unlike S (Becker et al p. 358)), R has never used partial matching when extracting by [, and as from R 2.7.0 partial matching is not by default used by

Hi, I have the following error when building a package * creating vignettes ... ERROR Error: chunk 3 Error in pmatch(x, table, duplicates.ok) : argument is not of mode character Error in buildVignettes(dir = ".") : Error: chunk 3 Error in pmatch(x, table, duplicates.ok) : argument is not of mode character Execution halted I use R-2.0.1 under debian linux 2.6.9