Regular Expression(正規表現) Part16

[過去ﾛｸﾞ] Regular Expression(正規表現) Part16 (1002ﾚｽ)
上下前次1-新
抽出解除ﾚｽ栞

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

29(16): デフォルトの名無しさん [sage] 2021/11/17(水)01:31 ID:vtK5EVRE(1/3)
[・ー└]|( ){3,}　→　合ってる
[・ー└( ){3,}]　→　間違い
[・ー└(( ){3,})] 　→　間違い

文字コードが uft-8 以外で書かれている文書を扱ってるとか？
そうなら　python 文字コード　でググって文書を uft-8 に変換してから split

31: デフォルトの名無しさん [sage] 2021/11/17(水)04:06 ID:PbEjqT95(1)
>>29
そもそも単文字なんだしグループにする必要なくね？

38: 29 [sage] 2021/11/17(水)11:01 ID:vtK5EVRE(2/3)
this[ ]is[ ]a[ ]pen

proxomitronのフィルタ職人をやってるときはこうやってた
今だと this\ is\ a\ pen かな？使ったことないけどｗ
\s は環境によっては全角スぺにマッチするから気を付けないとね

42(2): 29 [sage] 2021/11/19(金)20:58 ID:rZqXBgxj(1/2)
これの検証してみた

Absence operator is broken #150
https://github.com/k-takata/Onigmo/issues/150

・検証コード (ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x64-mingw32])
p /(?~a.*[bv].*c)/.match("000a111v222c333b444c555")

・結果
#<MatchData "000a111v222c333b444">

a〜v〜c を含んでしまってるのでバグで確定
原因は最初にマッチした段階で検索を打ち切ってしまっていて
別のパターンを見逃している

別のパターンを見つける必要があることは非包含オペレータ提案者さんの論文で
図付きで説明されてるけどこれを見落としてしまったオチ？

直すには論文通りに実装すれば良いだけなので直せないことは無さそう
自分がプログラミング出来れば直したいけどミジンコなので手も足も出ず..
-------------------------------------------------------
>>41 おつー

43: 29 [sage] 2021/11/19(金)23:35 ID:rZqXBgxj(2/2)
ついでにもう１つだけ

Use of \K when the string to match after \K can be empty #152
https://github.com/k-takata/Onigmo/issues/152

これは \K を使ってゼロ幅マッチになった場合に次の検索開始位置が
予期せず1つ進んでしまう問題のようだ

gsubの仕様かなと思ったけど (?<=\w) と \w\K の2つが違う結果になるのは
違和感ある、\K でのゼロ幅マッチ後の pos を進まないようにすれば直りそう

takata先生の代わりにちゃちゃっと始末してくれるスーパーハカーさん募集

44: 29 [sage] 2021/11/20(土)00:06 ID:dCkHZW0G(1/2)
\K より前で文字を消費していない場合は pos は進まないようだ
/\K/　 → pos進まず
/.\K/　→ 予期せずpos進んでしまう

46: 29 [sage] 2021/11/20(土)14:09 ID:dCkHZW0G(2/2)
>>45 そうなんだよね、だから気になってた

-------------------------------------------------
>>42 とは別の検証をしてみた

p /(?~a.*b.*c|222)/.match("000a111b222c333")
#<MatchData "000a111b22">

これは期待通りにマッチした、これが正しく動くということは
論文の読み落としではないね、失礼しました

問題は同一posでマッチ文字数が最短になるマッチを見つけなければいけないが
それをしていないことみたいだ
この処理って結構な処理量になりそうだけど大丈夫なのかな？

オペレータ提案者さんのサンプルコードではどうなってるんだろ？
プログラムが読めないから対応出来てるのか分からない..

あまりに重いようなら量指定子を使えるようにしたほうが良いかもしれない
.*　を　.{0,1000}　に書き換えて処理量を限定させるのと同じで
(?~abc){0,1000}　みたいな指定が出来るようにすれば..

47(1): 29 [sage] 2021/11/25(木)18:40 ID:QsU6pq8j(1/2)
Onigmo のバグの原因となった個所が判明したので書いておこう

正規表現における非包含オペレータの提案
https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf

この論文のサンプルコードに下記のメソッドがある

def try_alt(r1, r2, str, pos, &block)
try(r1, str, pos, &block)
try(r2, str, pos, &block)
end

これは正規表現で言うと r1|r2 の "|" にあたる動作をする部分のメソッドだが
このサンプルコードでは r1 のマッチが成功した後でも必ず r2 を試す仕様になっている

しかし Onigmo の検索方式では r1 がマッチした後に正規表現の最後までマッチが
成立した場合には r2 が試されない仕様になっている
これにより r2 を通る一部パターンが見落とされる結果となりバグとして出現した

論文中の非包含オペレータのメソッドである def try_absent(r, str, pos) は
上記の def try_alt を使う前提で書かれたものなのでこれをそのまま Onigmo には移植出来ない

サンプルコード方式での処理量を考えるとおそらくこれとはまったく別のアルゴリズムで動く
動作の軽いメソッドを自作しないと Onigmo には導入出来ないのではないだろうか..

48: 29 [sage] 2021/11/25(木)19:06 ID:QsU6pq8j(2/2)
論文3ページ目の右半分に表３がある

r1r2　　｜　　[:seq, r1, r2]

ここの :seq は r1 と r2 を連接するという意味で使われているが
サンプルコードでは :seq を使わず :cat になっている
ここで疑問なのが何故違う名前を使うことになったのか？である

(仮説１)　非包含オペレータ提案者さんは猫が好き

ごろにゃんしながらバックトラックにゃんである

(仮説２)　cat は Unix でよく使われる連結コマンドであり catenate から由来する

これもなかなかの難問である

55: 29 [sage] 2021/12/06(月)21:53 ID:S5ugmQVz(1)
rubyのコードが読めたから調子に乗って鬼車のソースからのインストールと
simple.c の実行に挑戦してみたら成功するまで10日くらいかかった

win10 パソコンで VMware を動かして中に ubuntu 20.04 を入れて
oniguruma 6.9.7 をインストした
あとは C言語で書かれたサンプルコードを解析すれば oniguruma の
色々なオプションを試せるようになる..

Unix も C言語も知らないしプログラマでもないミジンコだけどググりまくれば
意外と何とかなりそうだ、次は Onigmo を入れよう..

56(1): 29 [sage] 2021/12/07(火)02:27 ID:gbEOg3vj(1/3)
Onigmo もインスト出来たけど simple.c の実行結果がおかしい

// oniguruma の場合
match at 4
0: (4-14)
1: (5-13)

// Onigmo の場合
match at 4
0: (21474836484-55834574862)
1: (0-0)

インスト失敗か？

README_japanese に書いてある "onig-config --cflags" での構成確認は
oniguruma と Onigmo で同じコマンドだけど共通のコマンドなのかな？
両方入れたからどっちの構成を確認してるのか分からない

57: 29 [sage] 2021/12/07(火)04:28 ID:gbEOg3vj(2/3)
↑の構成確認の件はOnigmo の README.ja の 111 〜 114 行目が
oniguruma の説明のままなだけだった、takata先生更新を..
.ja が付いてない英語版も同様です

github の Onigmo のトップページでは正しく
"onigmo-config --cflags" と書いてありました

58: 29 [sage] 2021/12/07(火)15:13 ID:gbEOg3vj(3/3)
↑ の件ですが README.ja の 61 行目の

＞以下、鬼車の README.ja:

を見落としておりました、鬼車の説明書きのコピペだったのね..orz

>>56 の Onigmo の結果がおかしかったのも↓で正常動作しました

間違い： cc sample.c -L/usr/local/lib -lonig
正しい： cc sample.c -L/usr/local/lib -lonigmo

お騒がせして申し訳ありません m(__)m

59: 29 [sage] 2021/12/14(火)23:52 ID:hRBVXs3o(1)
perl5と鬼車、鬼雲の動作を比べて遊んでたらperl5の変な挙動を発見
\d{1} の {1} を付けるか消すかで結果が変わる

---------------------------
my $str = '12';
$str =~ s/(?<name>\d{1}){0}(?&name)/<match=$&>/;
print "$str\r\n";
---------------------------
↓{0} での定義を (?(DEFINE) ... ) に変えると正常動作する
---------------------------
my $str = '12';
$str =~ s/(?(DEFINE)(?<name>\d{1}))(?&name)/<match=$&>/;
print "$str\r\n";
---------------------------
perl 5, version 32, subversion 1 (v5.32.1) built for MSWin32-x64-multi-thread

60: 29 [sage] 2021/12/15(水)05:01 ID:+lf8SrwJ(1)
・ {0} での定義ではマッチせず
---------------------------
my $str = '123';
$str =~ s/(?<name>123){0}(?&name)/<match=$&>/;
print "$str\r\n";

・DEFINEを使うと正常動作する
---------------------------
my $str = '123';
$str =~ s/(?(DEFINE)(?<name>123))(?&name)/<match=$&>/;
print "$str\r\n";
---------------------------

perl5 では {0} で定義するのは想定外？

61(1): 29 [sage] 2021/12/16(木)22:14 ID:0VSoy2O4(1)
onigurumaの非包含オペレータの動作が論文と違う
正規表現　^(?~abc)　をテキスト　0123abcd　に対して検索して比較すると..

論文の動作　　　　：　0123ab　がマッチする
onigurumaの動作　：　0123　　がマッチする

逆に Onigmo は分岐が含まれない正規表現なら論文通りに動作するので
この場合は論文と同じ動作をする

動作的には　((?!abc).)*　と同じなので論文で指摘されているように
形式言語理論から逸脱しているし、後ろに続く正規表現によっては
マッチ出来ずに検索が終わってしまうケースが発生する　例、 ^(?~abc)c

非包含オペレータは提案から14年経ってもなお未完のままということに..

64: 29 [sage] 2021/12/17(金)19:59 ID:t+q3CK3B(1)
>>62 それ反則ｗ　ちなみにこんなのもある
Perl正規表現雑技 : ある文字列を含まないものにマッチする正規表現
http://www.din.or.jp/~ohzaki/regex.htm#Without

>>63 その解釈で間違ってないと思う、oniguruma の (?~abc) は仕様が
決まった時点で別物だね、(?:(?!abc).)*　の拡張版と言ったほうがしっくりくる
実用上は oniguruma 版のほうが使いやすそうだしあえて変えたんだろうね

上下前次1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.044s