#あと少しですね。
#gosh> (#/.*b/ #`",(make-string 5038)b")
*** ERROR: stack overrun during matching regexp #/.*b/
#エラーになってしまいます．
#それは現在のregexpエンジンの限界だなあ。NFAエンジンでは #/.*b/ というのは非常に効率が悪い正規表現なので、そもそも長い文字列にマッチさせるべきではないんだけど、golfだと避けがたいかも。#/[^b]*b/ のように前に'b'を含まない式であればずっと効率良くなります。「bはいくつも現れるけど、最後に現れるbまで探したい」というのなら今のGaucheでは明示的にstring-index-rightとか使ってもらうのが推奨。
#golfじゃなく普通に長さ12000くらいの文字列にマッチさせようとしてました．今回は .*? で済むことに気付いたのでそれで回避しました．string-index-right は文字列で検索できないんですね，bの所は実際には数文字あるので…あれ，string-scan-right みたいなものって無いんでしょうか
#あー、string-scan-rightは無いなあ。もともと文字列というのはリストの特殊なもので、右から見るべきではないっていう考えが背景にはあります。でもユーティリティ関数としてstring-scan-rightを作っておくのは良いかも (左から探していって最後のものを返す、という動作)
#文字列だと右から見たいこともあるような気がします．今回も右から見た方が自明だったので .* で書いてました．
#Rubyなら s1.rindex(s2) で済むのに…とか考えてしまいます(世界観の違いはありますが，配列中心だったり)．あと上の例も長さ100000でも大丈夫でした．
#「最右マッチを探す」のと「右から見る」はちょっと違うんですね。「最右マッチを探す」のが必要な場面があるのはわかります。「右から見る」はその実装方法のひとつ。
#はい．でも最右マッチを探すなら右から見た方が効率がいいですよね…と思ったけど，右からバイト列で見たらインデックスが分からないしインデックスアクセスだったら遅い…
#string-scan-right が左から探すというのは，そういうことですか？
#文字列としてのインデックス，です
#単純文字列なら右から見られるんですが、それは内部的な最適化のひとつで、一般的なイメージとしては文字列はリストみたいに先頭から数珠つなぎになってると考えておいた方がいいんじゃないかな、ってことです。string-scan-rightについては今考えてるんですが、少なくともutf-8なら右から探して困ることはないかも。
#さっきまでちょっとベクタみたいなノリだったことに気付きました．string-scan-rightはshift-jisだと駄目文字の関係で右からだと面倒だったりするんですかね…
#駄目文字というか1バイトの文字か2バイト文字の2バイト目かそのバイト見ただけじゃ区別できなかったと思うので
#はい。ちょい面倒です。あと、例えば単語の境界とかってちゃんとやろうとすると左からスキャンしないとだめだったりとか、わりと高次の操作では左からが前提になることが多いんですよね。
#なるほどー．勉強になりました．
#string-scan-right 足しました。
Gauche > Archives > 2012/05/27