search for: regmatches

A very common use case for regmatches is to extract regex matches into a new column in a data.frame (or data.table, etc.) or otherwise use the extracted strings alongside the input. However, the default behavior is to drop empty matches, which results in mismatches in column length if reassignment is done without subsetting. For consi...

Changing the default behavior of regmatches would break its use with gregexpr, where the number of matches per input element faries, so a zero-length character vector makes more sense than NA_character_. > x <- c("John Doe", "e e cummings", "Juan de la Madrid") > m <- gregexpr("[A-Z]", x)...

...(under review) about regular expression packages, https://raw.githubusercontent.com/tdhock/namedCapture-article/master/RJwrapper.pdf Comments/suggestions welcome. On Thu, Aug 15, 2019 at 12:15 AM Cyclic Group Z_1 via R-devel < r-devel at r-project.org> wrote: > A very common use case for regmatches is to extract regex matches into a > new column in a data.frame (or data.table, etc.) or otherwise use the > extracted strings alongside the input. However, the default behavior is to > drop empty matches, which results in mismatches in column length if > reassignment is done without su...

I think that's a good reason for not including this in regmatches; you're right, its name is somewhat suggestive of yielding matches. Also, that sounds like a great design for strcapture with an atomic prototype. Best, CG

Dear r-help members, I have a number in the form of a string, say: a<-"-01020.909200" I'd like to extract "1020." as well as ".9092" Front<-grep(pattern="[1-9]+[0-9]*\\.", value=TRUE, x=a, fixed=FALSE) End<-grep(pattern="\\.[0-9]*[1-9]+", value=TRUE, x=a, fixed=FALSE) However, both strings give "-01020.909200", exactly

Thank you, I am aware that there are packages that can accomplish this. I mentioned stringr::str_extract as a function that does not drop empty matches. I think that the behavior of regmatches(..., regexpr(...))?in base R should permit an option to prevent dropping of empty matches both for sake of consistency with the rest of the language (missing data does not yield a dropped index in other sorts of R functions, and an empty match conceptually corresponds with missing data) and facilit...

After some discussion within R core, we decided that a "nomatch" argument on regmatches() may be a good initial step. We might add a new function later that combines the regexpr() and regmatches() steps. The gregexpr() and regexec() inputs are both lists so it's not clear whether a "nomatch" value would be relevant (the elements are empty) in those cases. On Mon, Sep 2,...

...chael On Thu, Aug 29, 2019 at 2:20 PM Cyclic Group Z_1 via R-devel <r-devel at r-project.org> wrote: > > Thank you, I am aware that there are packages that can accomplish this. I mentioned stringr::str_extract as a function that does not drop empty matches. I think that the behavior of regmatches(..., regexpr(...)) in base R should permit an option to prevent dropping of empty matches both for sake of consistency with the rest of the language (missing data does not yield a dropped index in other sorts of R functions, and an empty match conceptually corresponds with missing data) and facilit...

...s=character(), stringsAsFactors=FALSE)) Name Address 1 Groucho groucho at marx.com 2 chico at marx.com 3 Harpo Bill Dunlap TIBCO Software wdunlap tibco.com On Thu, Aug 15, 2019 at 1:04 PM William Dunlap <wdunlap at tibco.com> wrote: > I don't care much for regmatches and haven't tried strextract, but I think > replacing the character(0) by NA_character_ is almost always inappropriate > if the match information comes from gregexpr. > > I think strcapture() does a pretty good job of what I think you are trying > to do. Perhaps adding an argume...

Thank you! I greatly appreciate your consideration, though of course it is up to you. I think many people switch to stringr/stringi simply because functions in those packages have some consistent design choices, for example, they do not drop empty/missing matches, which facilitates array-based programming. For example, in the cases where one needs to make a new column in a data.frame (data.table,

I don't care much for regmatches and haven't tried strextract, but I think replacing the character(0) by NA_character_ is almost always inappropriate if the match information comes from gregexpr. I think strcapture() does a pretty good job of what I think you are trying to do. Perhaps adding an argument to map no match to NA...

Just started thinking about this. The name of regmatches() suggests that it will only extract the matches but not return anything for the non-matches. We might need another function that returns a value for non-matches. Perhaps the value should be the empty string for non-matches and NA for matches to NA. The rationale is that we delegate to regexpr() (a...

http://bugs.freedesktop.org/show_bug.cgi?id=20298 Summary: Nouveau doesn't allow my modeline because of hardcoded value Product: xorg Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

I do think keeping the default behavior is desirable for backwards compatibility; my suggestion is not to change default behavior but to add an optional argument that allows a different behavior. Although this can be implemented in a user-defined function, retaining empty matches facilitates programmatic use, and seems to be something that should be available in base R. It is available, for

Full_Name: Ei-ji Nakama Version: R-2.5.0 OS: any Submission from: (NULL) (219.117.236.5) problem by operation of gsub in the locale of CP932 and SJIS. The inconvenient character code which used 0x5c after the first byte. --- R-2.5.0.orig/src/main/character.c 2007-04-03 11:05:05.000000000 +0900 +++ R-2.5.0/src/main/character.c 2007-06-24 22:31:06.000000000 +0900 @@ -986,6 +986,17 @@

Full_Name: Roger Bivand Version: 0.99.0 OS: RH Linux 6.1 Submission from: (NULL) (158.37.60.152) I am working on an interface between R and the GRASS geographical information system, written in R, with no dynamically loaded code. I have written full examples, and tested then under R 0.90.1, both by entering example() for each function and R CMD check, both of which worked without problem. Under

Under RSPython and rpy, the regexec C function is returning nonsensical results leading to segmentation faults. This is happening in some situations under R 1.4.1 and (more often?) under R 1.5.0 on my Solaris 8 box. R 1.4.1 was compiled with gcc 2.95.2, and I've tried 1.5.0 with both gcc 2.95.2 and gcc 3.0.3. The error appears to be exactly the same under both python tools and both

Hi Folks, I'm trying to extract just the backreferences from a regex. > temp = "abcd1234abcd1234" > regmatches(temp, gregexpr("(?:abcd)(1234)", temp)) [[1]] [1] "abcd1234" "abcd1234" What I would like is: [1] "1234" "1234" Note: I know I can just match 1234 here, but the actual example is complicated enough that I have to match a larger string, and just wa...

...o do it. R program: # Read in the entire file and convert all words in text to lower case words.txt<-tolower(scan("text_file","character",sep="\n")) # Extract words pattern <- "(\\b[A-Za-z]+\\b)" match <- gregexpr(pattern,words.txt) words.txt <- regmatches(words.txt,match) # Create a vector from the list of words words.txt<-unlist(words.txt) # Calculate word frequencies words.txt<-table(words.txt,dnn="words") # Sort by frequency, not alphabetically words.txt<-sort(words.txt,decreasing=TRUE) # Put into some readable form, "...

http://bugs.freedesktop.org/show_bug.cgi?id=14567 Summary: Randr 1.2 fails on nv17 lvds in a Dell Inspiron 8100 (continued from 14491) Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau