This was a deliberate change for R 2.4.0 with SVN log:
r38145 | rgentlem | 2006-05-20 23:58:14 +0100 (Sat, 20 May 2006) | 2 lines
fixing gregexpr infelicity
So it seems the author of gregexpr believed that the bug was in 2.3.1, not
2.5.1.
On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote:
Of=20
[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 8:36 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Rd] gregexpr (PR#9965)
=20
Full_Name: Peter Dolan
Version: 2.5.1
OS: Windows
Submission from: (NULL) (128.193.227.43)
=20
=20
gregexpr does not find all matching
Yes, we had originally wanted it to find all matches, but user
complaints that it did not perform as Perl does were taken to prevail.
There are different ways to do this, but it seems the notion that one
not start looking for the next match until after the previous one is
more common. I did
Yes, we had originally wanted it to find all matches, but user
complaints that it did not perform as Perl does were taken to prevail.
There are different ways to do this, but it seems the notion that one
not start looking for the next match until after the previous one is
more common. I did
Full_Name: Peter Dolan
Version: 2.5.1
OS: Windows
Submission from: (NULL) (128.193.227.43)
gregexpr does not find all matching substrings if the substrings overlap:
gregexpr(abab,ababab)
[[1]]
[1] 1
attr(,match.length)
[1] 4
It does work correctly in Version 2.3.1 under linux.
PROTECTED]
Sent: Wednesday, October 10, 2007 8:36 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Rd] gregexpr (PR#9965)
Full_Name: Peter Dolan
Version: 2.5.1
OS: Windows
Submission from: (NULL) (128.193.227.43)
gregexpr does not find all matching substrings
