[過去ﾛｸﾞ]
Regular Expression(正規表現) Part16 (1002ﾚｽ)
Regular Expression(正規表現) Part16 http://mevius.5ch.net/test/read.cgi/tech/1635936601/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
29: デフォルトの名無しさん [sage] 2021/11/17(水) 01:31:56.09 ID:vtK5EVRE [・ー└]|( ){3,} → 合ってる [・ー└( ){3,}] → 間違い [・ー└(( ){3,})] → 間違い 文字コードが uft-8 以外で書かれている文書を扱ってるとか？ そうなら python 文字コード でググって文書を uft-8 に変換してから split http://mevius.5ch.net/test/read.cgi/tech/1635936601/29
31: デフォルトの名無しさん [sage] 2021/11/17(水) 04:06:28.28 ID:PbEjqT95 >>29 そもそも単文字なんだしグループにする必要なくね？ http://mevius.5ch.net/test/read.cgi/tech/1635936601/31
38: 29 [sage] 2021/11/17(水) 11:01:36.46 ID:vtK5EVRE this[ ]is[ ]a[ ]pen proxomitronのフィルタ職人をやってるときはこうやってた 今だと this\ is\ a\ pen かな？ 使ったことないけどｗ \s は環境によっては全角スぺにマッチするから気を付けないとね http://mevius.5ch.net/test/read.cgi/tech/1635936601/38
42: 29 [sage] 2021/11/19(金) 20:58:09.22 ID:rZqXBgxj これの検証してみた 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 おつー http://mevius.5ch.net/test/read.cgi/tech/1635936601/42
43: 29 [sage] 2021/11/19(金) 23:35:42.78 ID:rZqXBgxj ついでにもう１つだけ 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先生の代わりにちゃちゃっと始末してくれるスーパーハカーさん募集 http://mevius.5ch.net/test/read.cgi/tech/1635936601/43
44: 29 [sage] 2021/11/20(土) 00:06:32.69 ID:dCkHZW0G \K より前で文字を消費していない場合は pos は進まないようだ /\K/ → pos進まず /.\K/ → 予期せずpos進んでしまう http://mevius.5ch.net/test/read.cgi/tech/1635936601/44
46: 29 [sage] 2021/11/20(土) 14:09:45.26 ID:dCkHZW0G >>45 そうなんだよね、だから気になってた ------------------------------------------------- >>42 とは別の検証をしてみた p /(?~a.*b.*c|222)/.match("000a111b222c333") #<MatchData "000a111b22"> これは期待通りにマッチした、これが正しく動くということは 論文の読み落としではないね、失礼しました 問題は同一posでマッチ文字数が最短になるマッチを見つけなければいけないが それをしていないことみたいだ この処理って結構な処理量になりそうだけど大丈夫なのかな？ オペレータ提案者さんのサンプルコードではどうなってるんだろ？ プログラムが読めないから対応出来てるのか分からない.. あまりに重いようなら量指定子を使えるようにしたほうが良いかもしれない .* を .{0,1000} に書き換えて処理量を限定させるのと同じで (?~abc){0,1000} みたいな指定が出来るようにすれば.. http://mevius.5ch.net/test/read.cgi/tech/1635936601/46
47: 29 [sage] 2021/11/25(木) 18:40:51.33 ID:QsU6pq8j Onigmo のバグの原因となった個所が判明したので書いておこう 正規表現における非包含オペレータの提案 ttps://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 には導入出来ないのではないだろうか.. http://mevius.5ch.net/test/read.cgi/tech/1635936601/47
48: 29 [sage] 2021/11/25(木) 19:06:15.35 ID:QsU6pq8j 論文3ページ目の右半分に 表３ がある r1r2 ｜ [:seq, r1, r2] ここの :seq は r1 と r2 を連接するという意味で使われているが サンプルコードでは :seq を使わず :cat になっている ここで疑問なのが何故違う名前を使うことになったのか？ である (仮説１) 非包含オペレータ提案者さんは猫が好き ごろにゃんしながらバックトラックにゃん である (仮説２) cat は Unix でよく使われる連結コマンドであり catenate から由来する これもなかなかの難問である http://mevius.5ch.net/test/read.cgi/tech/1635936601/48
55: 29 [sage] 2021/12/06(月) 21:53:22.08 ID:S5ugmQVz rubyのコードが読めたから調子に乗って鬼車のソースからのインストールと simple.c の実行に挑戦してみたら成功するまで10日くらいかかった win10 パソコンで VMware を動かして中に ubuntu 20.04 を入れて oniguruma 6.9.7 をインストした あとは C言語で書かれたサンプルコードを解析すれば oniguruma の 色々なオプションを試せるようになる.. Unix も C言語 も知らないしプログラマでもないミジンコだけどググりまくれば 意外と何とかなりそうだ、次は Onigmo を入れよう.. http://mevius.5ch.net/test/read.cgi/tech/1635936601/55
56: 29 [sage] 2021/12/07(火) 02:27:56.29 ID:gbEOg3vj 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 で同じコマンドだけど共通のコマンドなのかな？ 両方入れたからどっちの構成を確認してるのか分からない http://mevius.5ch.net/test/read.cgi/tech/1635936601/56
57: 29 [sage] 2021/12/07(火) 04:28:00.86 ID:gbEOg3vj ↑の構成確認の件はOnigmo の README.ja の 111 〜 114 行目 が oniguruma の説明のままなだけだった、takata先生更新を.. .ja が付いてない英語版も同様です github の Onigmo のトップページでは正しく "onigmo-config --cflags" と書いてありました http://mevius.5ch.net/test/read.cgi/tech/1635936601/57
58: 29 [sage] 2021/12/07(火) 15:13:24.06 ID:gbEOg3vj ↑ の件ですが 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 http://mevius.5ch.net/test/read.cgi/tech/1635936601/58
59: 29 [sage] 2021/12/14(火) 23:52:24.48 ID:hRBVXs3o 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 http://mevius.5ch.net/test/read.cgi/tech/1635936601/59
60: 29 [sage] 2021/12/15(水) 05:01:54.34 ID:+lf8SrwJ ・ {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} で定義するのは想定外？ http://mevius.5ch.net/test/read.cgi/tech/1635936601/60
61: 29 [sage] 2021/12/16(木) 22:14:43.92 ID:0VSoy2O4 onigurumaの非包含オペレータの動作が論文と違う 正規表現 ^(?~abc) をテキスト 0123abcd に対して検索して比較すると.. 論文の動作 ： 0123ab がマッチする onigurumaの動作 ： 0123 がマッチする 逆に Onigmo は分岐が含まれない正規表現なら論文通りに動作するので この場合は論文と同じ動作をする 動作的には ((?!abc).)* と同じなので論文で指摘されているように 形式言語理論から逸脱しているし、後ろに続く正規表現によっては マッチ出来ずに検索が終わってしまうケースが発生する 例、 ^(?~abc)c 非包含オペレータは提案から14年経ってもなお未完のままということに.. http://mevius.5ch.net/test/read.cgi/tech/1635936601/61
64: 29 [sage] 2021/12/17(金) 19:59:50.60 ID:t+q3CK3B >>62 それ反則ｗ ちなみにこんなのもある Perl正規表現雑技 : ある文字列を含まないものにマッチする正規表現 http://www.din.or.jp/~ohzaki/regex.htm#Without >>63 その解釈で間違ってないと思う、oniguruma の (?~abc) は仕様が 決まった時点で別物だね、(?:(?!abc).)* の拡張版と言ったほうがしっくりくる 実用上は oniguruma 版のほうが使いやすそうだしあえて変えたんだろうね http://mevius.5ch.net/test/read.cgi/tech/1635936601/64
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.035s