On 02/10/2016 17:54, Pi wrote:
Hello.
It would be great if the grep function in R had the option to use the -m
parameter as the linux command does.
I guess you mean the non-standard flag of the GNU version of grep
(probably but not necessarily as used by Linux).
That the POSIX standard for
Hello.
It would be great if the grep function in R had the option to use the -m
parameter as the linux command does.
That would allow to stop a grep search as soon as something is found.
It would make many operations much faster.
[[alternative HTML version deleted]]
_
On Fri, 30 Sep 2011, Simon Urbanek wrote:
Jeff,
this is really a bug in PCRE since the length (0) is a multiple of 3 as
documented so PCRE should not be writing anything. Anyway, this has been now
fixed (by Brian).
Only in R-devel: R-2-13-branch is now closed (and was by the time I
read th
Jeff,
this is really a bug in PCRE since the length (0) is a multiple of 3 as
documented so PCRE should not be writing anything. Anyway, this has been now
fixed (by Brian).
Cheers,
Simon
On Sep 29, 2011, at 5:00 PM, Jeffrey Horner wrote:
> Hello,
>
> I think I've found a bug in the C functi
On Thu, Sep 29, 2011 at 2:00 PM, Jeffrey Horner
wrote:
> Hello,
>
> I think I've found a bug in the C function do_grep located in
> src/main/grep.c. It seems to affect both the latest revisions of
> R-2-13-branch and trunk when compiling R without optimizations and
> with it's own version of pcre
On Thu, Sep 29, 2011 at 4:00 PM, Jeffrey Horner
wrote:
> Hello,
>
> I think I've found a bug in the C function do_grep located in
> src/main/grep.c. It seems to affect both the latest revisions of
> R-2-13-branch and trunk when compiling R without optimizations and
> with it's own version of pcre
Hello,
I think I've found a bug in the C function do_grep located in
src/main/grep.c. It seems to affect both the latest revisions of
R-2-13-branch and trunk when compiling R without optimizations and
with it's own version of pcre located in src/extra, at least on ubuntu
10.04.
According to the
I forgot to mention the more obvious ;) - yes, it is a known issue in PCRE 8.13
which is hitting more people.
After re-reading the standard I think the problem was that PCRE did not require
enclosing [ to treat [. as special. This has been addressed in the PCRE trunk
since and it also has a com
Mark, quick googling gives the answer - [.] is not what you think it is, you
probably meant [\.]. Bracket expressions starting with [. are collating symbols
which is unsupported by PCRE (only [:xxx:] is supported, neither [=xxx=] nor
[.xxx.] is) but that's probably not what you intended. See POS
Problem below with PCRE grep in R-devel; works fine in R-patched. (Unless
there's been an absolutely massive change in rules for updated PCRE version
8.13; jeez I hope not)
> grep( '[.][.]', '', perl=TRUE)
Error in grep("[.][.]", "", perl = TRUE) :
invalid regular expression '[.][.]'
In additi
On Thu, 17 May 2007, Petr Savicky wrote:
>> strncasecmp is not standard C (not even C99), but R does have a substitute
>> for it. Unfortunately strncasecmp is not usable with multibyte charsets:
>> Linux systems have wcsncasecmp but that is not portable. In these days of
>> widespread use of UTF
> strncasecmp is not standard C (not even C99), but R does have a substitute
> for it. Unfortunately strncasecmp is not usable with multibyte charsets:
> Linux systems have wcsncasecmp but that is not portable. In these days of
> widespread use of UTF-8 that is a blocking issue, I am afraid.
On Fri, 11 May 2007, Petr Savicky wrote:
> On Wed, May 09, 2007 at 06:41:23AM +0100, Prof Brian Ripley wrote:
>> I suggest you collaborate with the person who replied that he thought this
>> was a good idea to supply patches against the R-devel sources for
>> scrutiny.
>
> A possible solution is t
On Wed, May 09, 2007 at 06:41:23AM +0100, Prof Brian Ripley wrote:
> I suggest you collaborate with the person who replied that he thought this
> was a good idea to supply patches against the R-devel sources for
> scrutiny.
A possible solution is to use strncasecmp instead of strncmp
in function
On Mon, 7 May 2007, Petr Savicky wrote:
> Dear R developers,
>
> I suggest to modify the behaviour of "grep" function with fixed=TRUE option.
>
> Currently, fixed=TRUE implies ignore.case=FALSE (overrides ignore.case=TRUE,
> if set by the user).
As it clearly says it does.
> I suggest to keep ig
Seems like a good idea to me.
Here is a workaround that works in any event which combines (?i), \Q and \E .
to get the same effect. (?i) gives case insensitive matches and \Q and \E
quote and endquote the intervening text disabling special characters:
x <- c("D.G cat", "d.g cat", "dog cat")
z <-
Dear R developers,
I suggest to modify the behaviour of "grep" function with fixed=TRUE option.
Currently, fixed=TRUE implies ignore.case=FALSE (overrides ignore.case=TRUE,
if set by the user).
I suggest to keep ignore.case as set by the user even if fixed=TRUE. Since
the default of ignore.case
On Tue, 2006-06-06 at 17:08 +0100, Prof Brian Ripley wrote:
> On Tue, 6 Jun 2006, Marc Schwartz (via MN) wrote:
>
> > On Tue, 2006-06-06 at 11:12 +0100, Prof Brian Ripley wrote:
> >> On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
> >>
> >>> Hi all,
> >>>
> >>> Based upon an offlist communicatio
On Tue, 6 Jun 2006, Marc Schwartz (via MN) wrote:
> On Tue, 2006-06-06 at 11:12 +0100, Prof Brian Ripley wrote:
>> On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
>>
>>> Hi all,
>>>
>>> Based upon an offlist communication this morning, I am somewhat confused
>>> (more than I usually am on most M
On Tue, 2006-06-06 at 11:12 +0100, Prof Brian Ripley wrote:
> On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
>
> > Hi all,
> >
> > Based upon an offlist communication this morning, I am somewhat confused
> > (more than I usually am on most Monday mornings...) about the use of
> > grep() with fa
On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
> Hi all,
>
> Based upon an offlist communication this morning, I am somewhat confused
> (more than I usually am on most Monday mornings...) about the use of
> grep() with factors as the 'x' argument.
>
> The argument guidance in ?grep indicates:
>
On 6/5/06, Bill Dunlap <[EMAIL PROTECTED]> wrote:
> On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
>
> > > > > grep("[a-z]", factor(letters))
> > > > numeric(0)
> > >
> > > I was recently surprised by this also. In addition, if
> > > R's grep did support factors in this way, what sort of
> > >
On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
> > > > grep("[a-z]", factor(letters))
> > > numeric(0)
> >
> > I was recently surprised by this also. In addition, if
> > R's grep did support factors in this way, what sort of
> > object (factor or character) should it return when value=T?
> > I
Marc Schwartz (via MN) wrote:
> On Mon, 2006-06-05 at 13:45 -0700, Bill Dunlap wrote:
>
>>On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
>>
>>
>>>Based upon an offlist communication this morning, I am somewhat confused
>>>(more than I usually am on most Monday mornings...) about the use of
>>>g
On Mon, 2006-06-05 at 13:45 -0700, Bill Dunlap wrote:
> On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
>
> > Based upon an offlist communication this morning, I am somewhat confused
> > (more than I usually am on most Monday mornings...) about the use of
> > grep() with factors as the 'x' argum
On Mon, 5 Jun 2006, Marc Schwartz (via MN) wrote:
> Based upon an offlist communication this morning, I am somewhat confused
> (more than I usually am on most Monday mornings...) about the use of
> grep() with factors as the 'x' argument.
> ...
> > grep("[a-z]", letters)
> [1] 1 2 3 4 5 6
Hi all,
Based upon an offlist communication this morning, I am somewhat confused
(more than I usually am on most Monday mornings...) about the use of
grep() with factors as the 'x' argument.
The argument guidance in ?grep indicates:
x, text a character vector where matches are sought. Coerced to
27 matches
Mail list logo
