|
Posted by spydox on April 14, 2008, 1:08 pm
Please log in for more thread options
I'm trying to find a repeated number in a string, like 122345 finds
22.
This works:
/(\d)/
This doesn't:
/(\d)/
I guess LLR parsing is to blame, but shouldn't the second example
first try to FIND a $1 then check to see if there is a , and repeat
that process moving L to R?
I though Perl sort of went to and fro trying to do matching. To me,
there IS a /(\d)/ in the string since $1 is 2, and there is a = 2
preceeding it.
I was a little surprized this didn't work although I can sort of see
why in a way too. In some ways it seems to me that regexes should be
*disconnected* from parsing - just answer the question does this
match?
|
|
Posted by A. Sinan Unur on April 14, 2008, 2:37 pm
Please log in for more thread options
spydox@gmail.com wrote in
news:093bf887-729d-4400-8750-
6c91b21b478e@w4g2000prd.googlegroups.com
:
> I'm trying to find a repeated number in a string, like 122345
> finds 22.
>
> This works:
>
> /(\d)/
>
> This doesn't:
>
> /(\d)/
>
> I guess LLR parsing is to blame,
...
> I was a little surprized this didn't work although I can sort of
> see why in a way too. In some ways it seems to me that regexes
> should be *disconnected* from parsing - just answer the question
> does this match?
I don't look at this as a parsing issue. Rather, it is a "the
universe must make sense" kind of issue: The first match does not
exist before the first match. That makes sense to me. It may not
make sense to you.
Sinan
--
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
|
|
Posted by spydox on April 14, 2008, 2:57 pm
Please log in for more thread options .
.
.
>
> > I guess LLR parsing is to blame,
>
.
.
>
> I don't look at this as a parsing issue. Rather, it is a "the
> universe must make sense" kind of issue: The first match does not
> exist before the first match. That makes sense to me. It may not
> make sense to you.
>
To me, like conventional pattern-recognition, of say two tanks next to
each other, the system should accept it whether the match is described
either way:
find a tank with another identical tank to it's left
*or*
find a tank with another identical tank to it's right
The system should have no *context-sensitivity* where only one of the
two matches. Sure, internally an algorithm may be scanning L to R or R
to L or whatever, but the user should not even be concerned with that,
at least in this case. I still think it gave up too soon- it should
have tried R to L (backtracking) when L to R failed.
Just IMHO, thank-you for your thoughts. This area seems just a bit
gray to me I'd be very interested in Damain or Mark's thoughts.
|
|
Posted by J.D. Baldwin on April 14, 2008, 3:51 pm
Please log in for more thread options
> > > I guess LLR parsing is to blame,
> >
> .
> .
> >
> > I don't look at this as a parsing issue. Rather, it is a "the
> > universe must make sense" kind of issue: The first match does not
> > exist before the first match. That makes sense to me. It may not
> > make sense to you.
> >
>
> To me, like conventional pattern-recognition, of say two tanks next to
> each other, the system should accept it whether the match is described
> either way:
>
> find a tank with another identical tank to it's left
>
> *or*
>
> find a tank with another identical tank to it's right
A better phrasing:
find a tank, then find another one to its right
*or*
find another one to its left, then find a tank
One of these phrasings makes sense; the other does not. Or, rather,
the other doesn't and one of the phrasings makes sense.
If you want a more formal justification, here's what the Camel Book
says about these. Note the two instances of the word "later":
1.7.4. Backreferences
[...] A pair of parentheses around a part of a regular
expression causes whatever was matched by that part to be
remembered for later use. It doesn't change what the part
matches, so /\d+/ and /(\d+)/ will still match as many digits
as possible, but in the latter case they will be remembered in
a special variable to be backreferenced later.
--
_+_ From the catapult of |If anyone disagrees with any statement I make, I
_|70|___:)=}- J.D. Baldwin |am quite prepared not only to retract it, but also
\ / baldwin@panix.com|to deny under oath that I ever made it. -T. Lehrer
***~~~~-----------------------------------------------------------------------
|
|
Posted by xhoster on April 14, 2008, 5:58 pm
Please log in for more thread options news@baldwin.users.panix.com wrote:
> >
> > find a tank with another identical tank to it's left
> >
> > *or*
> >
> > find a tank with another identical tank to it's right
>
> A better phrasing:
>
> find a tank, then find another one to its right
>
> *or*
>
> find another one to its left, then find a tank
>
> One of these phrasings makes sense; the other does not. Or, rather,
> the other doesn't and one of the phrasings makes sense.
>
> If you want a more formal justification, here's what the Camel Book
> says about these. Note the two instances of the word "later":
I think that that is his point, an objection to the notion that
left and right typographically equate to "earlier" and "later"
chronologically.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
|
| Similar Threads | Posted | | please splain dis scoping issure | June 22, 2007, 12:34 pm |
| Ways to find MTU and MSS | February 22, 2006, 12:25 am |
| Hrs of work on regex: please help | July 26, 2004, 6:51 pm |
| Regex won't work | February 9, 2006, 5:14 pm |
| Hidden overload and It is a better ways to save to Mysql, it is? | October 5, 2005, 11:51 pm |
| Regex: Backreferences do not work inside quantifiers? | March 7, 2006, 1:56 pm |
| regex bug (comments within regex not as robust) | October 27, 2005, 12:01 pm |
| FAQ 4.6 Why doesn't & work the way I want it to? | May 13, 2005, 5:03 am |
| FAQ 4.6: Why doesn't & work the way I want it to? | November 7, 2004, 6:03 am |
| FAQ 4.6: Why doesn't & work the way I want it to? | December 2, 2004, 12:03 pm |
|
XML Sitemap