I have problem with a simple negative lookahead Reqular Expression

[intrader]

The regular expression is /(?!((00000)|(11 111)))/ in oRe. That is
oRE=/(?!((00000)|(11 111)))/
The test strings are 92708, 00000, 11111 in checkStr
The expression used is checkStr.search (oRE). The values returned are
are 0,1,1 - the values should be 0,-1,-1.

The positive lookahead expressiono RE=/(?=((00000)|(11 111)))/ returns
-1, 0, 0 respectively - this is correct
The javascript used is Microsoft Javascript 1.5

[Julian Turner]

in******@aol.co m wrote:

The regular expression is /(?!((00000)|(11 111)))/ in oRe. That is
oRE=/(?!((00000)|(11 111)))/
The test strings are 92708, 00000, 11111 in checkStr
The expression used is checkStr.search (oRE). The values returned are
are 0,1,1 - the values should be 0,-1,-1.

The positive lookahead expressiono RE=/(?=((00000)|(11 111)))/ returns
-1, 0, 0 respectively - this is correct
The javascript used is Microsoft Javascript 1.5

Hi

I think 0, 1, 1 is correct.

Firstly, remember that ?! is non-consuming. I.e. "Lookaheads do not
consume characters, that is, after a match occurs, the search for the
next match begins immediately following the last match, not after the
characters that comprised the lookahead."

Secondly, remember that a look-ahead is testing not for a character,
but what characters follows from a given point in the string.

Conceptually, one way I like to understand a look-ahead is to consider
it as an imaginary "cursor" in the string, looking at what follows that
cursor.

Thus with your RegExp /(?!((00000)|(11 111)))/ and given the string
"0000", I will use ' | ' to refer to the cursor:

1. The cursor starts at the beginning of the input: |0000

This is insertion point ' 0 '

In that case the match fails, so because ?! is non-consuming, the
cursor moves forward one position, and the test is run again:-

2. The cursor is now here: 0|000

This is insertion point ' 1 '

Here only three ' 0 ' characters that follow the cursor, so the match
succeeds.

Hence why it returns 1, because at position 1 there are only 3 zeros in
the look-ahead.

If my string were composed of 5 zeros "00000", then the match would be
at position 2 --- 00|000

Hope this helps

Regards
Julian Turner

[intrader]

Most helpful,
However, in my opinion shows an inconsistency in the search result. It
should return 0 for the string "92708" as it does not find "92708" at
cursor position 0 and the RegExp is a negative lookahead.
Then for "00000" it should return -1 as it does find the string but the
negative should then return -1.

I hope these expectations are OK

Thanks

P.S. Otherwise, I must write a different test depending on the RegExp I
have. Not a nice condition.

Julian Turner wrote:

in******@aol.co m wrote:

The regular expression is /(?!((00000)|(11 111)))/ in oRe. That is
oRE=/(?!((00000)|(11 111)))/
The test strings are 92708, 00000, 11111 in checkStr
The expression used is checkStr.search (oRE). The values returned are
are 0,1,1 - the values should be 0,-1,-1.

The positive lookahead expressiono RE=/(?=((00000)|(11 111)))/ returns
-1, 0, 0 respectively - this is correct
The javascript used is Microsoft Javascript 1.5

Hi

I think 0, 1, 1 is correct.

Firstly, remember that ?! is non-consuming. I.e. "Lookaheads do not
consume characters, that is, after a match occurs, the search for the
next match begins immediately following the last match, not after the
characters that comprised the lookahead."

Secondly, remember that a look-ahead is testing not for a character,
but what characters follows from a given point in the string.

Conceptually, one way I like to understand a look-ahead is to consider
it as an imaginary "cursor" in the string, looking at what follows that
cursor.

Thus with your RegExp /(?!((00000)|(11 111)))/ and given the string
"0000", I will use ' | ' to refer to the cursor:

1. The cursor starts at the beginning of the input: |0000

This is insertion point ' 0 '

In that case the match fails, so because ?! is non-consuming, the
cursor moves forward one position, and the test is run again:-

2. The cursor is now here: 0|000

This is insertion point ' 1 '

Here only three ' 0 ' characters that follow the cursor, so the match
succeeds.

Hence why it returns 1, because at position 1 there are only 3 zeros in
the look-ahead.

If my string were composed of 5 zeros "00000", then the match would be
at position 2 --- 00|000

Hope this helps

Regards
Julian Turner

[Julian Turner]

in******@aol.co m wrote:

Most helpful,
However, in my opinion shows an inconsistency in the search result. It
should return 0 for the string "92708" as it does not find "92708" at
cursor position 0 and the RegExp is a negative lookahead.
Then for "00000" it should return -1 as it does find the string but the
negative should then return -1.

I hope these expectations are OK

Thanks

P.S. Otherwise, I must write a different test depending on the RegExp I
have. Not a nice condition.

Hi

Hmm, I still think the results you are getting are correct,
unfortunately for you.

Remember that you have two different tests,

one negative (?!) (which is a very wide set of INFINITY-1 items, i.e.
looking for NOT "0000", means that everything else in the universe
other than "0000" matches).

one positive (?=) (which is a very narrow set of 1 item, i.e.
everything which is "0000")

So with the string "92708"

The positive test (?=) you are looking for "a point followed by 0000"
somewhere in the string. You would expect to produce a failure -1,
because at no point in the string can you say that "0000" follows.
I.e. if I put an imaginary cursor at each point in the string |92708
9|2708 92|708 927|08 9270|8 and look ahead, there is no following
pattern of "0000".

The negative test (?!) you are looing for "a point NOT followed by
0000" . You would expect to produce a successful result ' 0 ', in the
string "92708", because |92708 is the FIRST POINT at which this test
is satisfied and you can say that the point is NOT followed by 0000.

Regards

Julian Turner

[Julian Turner]

[snip]

in******@aol.co m wrote:
The expression used is checkStr.search (oRE). The values returned are

are 0,1,1 - the values should be 0,-1,-1.
[/snip]

Hi again

What exactly are you trying to achieve here? It may be that
look-aheads are not the best answer.

Regards

Julian Turner

[intrader]

This is part of a validation suite where coders may provide a regular
expression; in this case someone coded the negative lookahead to
validate zip codes and it validation suite failed (zip codes 00000 and
11111 are syntactically correct but not valid). The test is done via
the string search method and I expected the same behavior for this
'negative lookahead' RegExp as with other regular expressions.

Very interesting subject; I have not looked at the philosophical side
of the whole thing.

Thanks

Julian Turner wrote:

[snip]

in******@aol.co m wrote:
The expression used is checkStr.search (oRE). The values returned are

are 0,1,1 - the values should be 0,-1,-1.
[/snip]

Hi again

What exactly are you trying to achieve here? It may be that
look-aheads are not the best answer.

Regards

Julian Turner

[ron.h.hall]

On Jan 17, 4:17 pm, [e-mail] m wrote:

The regular expression is /(?!((00000)|(11 111)))/ in oRe. That is
oRE=/(?!((00000)|(11 111)))/
The test strings are 92708, 00000, 11111 in checkStr
The expression used is checkStr.search (oRE). The values returned are
are 0,1,1 - the values should be 0,-1,-1.

The 0,1,1 result appears to be correct, as the regular expression is
not anchored.

Perhaps /^(?!((00000)|(1 1111)))/ was intended?

../rh

[intrader]

When I change the RegExp to /^(?!((00000)|(1 1111)))/ I get the intended
results 0,-1-1.

Thanks

ro********@gmai l.com wrote:

On Jan 17, 4:17 pm, [e-mail] m wrote:

The regular expression is /(?!((00000)|(11 111)))/ in oRe. That is
oRE=/(?!((00000)|(11 111)))/
The test strings are 92708, 00000, 11111 in checkStr
The expression used is checkStr.search (oRE). The values returned are
are 0,1,1 - the values should be 0,-1,-1.

The 0,1,1 result appears to be correct, as the regular expression is
not anchored.

Perhaps /^(?!((00000)|(1 1111)))/ was intended?

../rh