[#20127] protected_instance_methods(true) — Shin-ichiro HARA <sinara@...>
原です。
4 messages
2003/05/01
[#20163] Numeric#step — Koji Arai <JCA02266@...>
新井です。
13 messages
2003/05/05
[#20165] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20167] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20169] Re: Numeric#step
— Minero Aoki <aamine@...>
2003/05/05
青木です。
[#20171] Re: Numeric#step
— Koji Arai <JCA02266@...>
2003/05/05
新井です。
[#20172] Re: Numeric#step
— Masahiro TANAKA <masa@...>
2003/05/06
At Tue, 6 May 2003 02:55:54 +0900,
[#20197] ARGF.filename — Koji Arai <JCA02266@...>
新井です。
6 messages
2003/05/17
[#20209] /()*\1/ =~ "" — Tanaka Akira <akr@...17n.org>
元ネタは BTS および Matzにっきなのですが、Matzにっきの調子が悪くてつっ
5 messages
2003/05/19
[#20227] dyna_vars problem? — Tanaka Akira <akr@...17n.org>
しばらく前から、稀に Ruby が core を吐くという問題を追いかけているので
15 messages
2003/05/19
[#20234] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/19
まつもと ゆきひろです
[#20236] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/19
In article <1053363181.529491.30320.nullmailer@picachu.netlab.jp>,
[#20245] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20248] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053422521.786672.22712.nullmailer@picachu.netlab.jp>,
[#20250] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20251] Re: dyna_vars problem?
— Tanaka Akira <akr@...17n.org>
2003/05/20
In article <1053424909.383731.24667.nullmailer@picachu.netlab.jp>,
[#20255] Re: dyna_vars problem?
— matz@... (Yukihiro Matsumoto)
2003/05/20
まつもと ゆきひろです
[#20268] splat restary — nobu.nakada@...
なかだです。
5 messages
2003/05/21
[#20303] [Oniguruma] possessive quantifier — kkosako@...
強欲な繰り返し演算子を実装してみたんですが、
1 message
2003/05/28
[#20307] [Oniguruma] intersection of char class — kkosako@...
Javaの正規表現で実現されている
4 messages
2003/05/30
[ruby-dev:20225] Re: /()*\1/ =~ ""
From:
Tanaka Akira <akr@...17n.org>
Date:
2003-05-19 10:46:03 UTC
List:
ruby-dev #20225
In article <5FD2F0CF7F5D7F44B00F36870B9E78B508DE5024@SBG-EX4>,
kkosako@softbank.co.jp writes:
> こういう場合があるんですね。考えていませんでした。
> 選択肢の数だけの繰り返しは、必ず試すように変更すれば良いような気がしますが、
> それだけでどのようなパターンにも対応できるのか、わかりません。
> 誰か教えてください。
考えてみました。
基本的には全部試すことになります。
ただ、本当に全部試すと無限ループになることがあるので、それを検査する必
要があって、そこが微妙です。
その検査は、繰り返しを一回進めて状態が変化しない場合はそれ以降は試さな
いというのが基本的な条件になります。たぶん。
ここで、状態というのは、
(1) マッチにおける現在位置
(2) capture した場所の開始・終了位置
というのの直積です。
なんでこれで無限ループにならないのかというと、マッチにおける現在位置と
capture の開始・終了位置は単調に変化し、決して減少しないからです。決し
て減少しない上に、さらに上の条件で同じ状態が続くことがなくなります。ま
た、対象の文字列は有限ですから、位置がだんだん増加していけばそのうち終
ります。
ただ、実装上は (2) を
(2) capture した文字列
と変えて効率を稼いだほうがいいかもしれません。
こうしても対象文字列全体がマッチするかどうかには影響を与えません。なぜ
かというと、backreference は位置を参照しないからです。
また、こうしても終了することは同じです。これは開始・終了位置が等しけれ
ばその文字列も同じなので、文字列が違うときには常に位置が変わっているこ
とから示せます。
ただ、これをやると、MatchData#{begin,end} がちょっと変わるかも知れない
という気もします。
--
[田中 哲][たなか あきら][Tanaka Akira]