/ 最近 .rdf 追記 編集 設定 本棚

脳log[20090703] > 500円弱の弱ってどう言う意味? - Yahoo!知恵袋 | XRegExp-1.0.1と Firefoxの /(?!)/



2009年07月03日 (金) 時計回り、反時計回りはわかる。右回り、左回りはどっちがどっちかわからない。目の付け所が恣意的ではないか、と小学生のころ思っていた。<< 円を正面から見るのでなく、中心に立ってみればよかったのだ。(やっと訪れた理解)

最終更新: 2009-08-23T05:42+0900

> 500円弱の弱ってどう言う意味? - Yahoo!知恵袋

500円弱の弱ってどう言う意味?

例えば、500円弱って言う場合は、490円(500円より若干少ない)ですか? それとも510円(500円より若干多い)ですか? 前者だとばかりずっと思っていましたが、知人は後者だと思ってたそうです。

国語大辞典によれば、ある数の端数を切り上げたとき、示す数よりは少し、不足があることをいうために、数字のあとに弱を付けて用いる。「一万円弱」。

とあります。ですから、後者が正解ですね。

最近、通じてないな、と感じた経験がある。相手がこの言い方を知らないのならその場で言い換えるチャンスもあるけど、○○弱といったとき○○だけあるのかないのか、という部分をさらっと勘違いされていた。

回答をひとつだけ取り上げたけど、辞典を引いてさえ後者といわれては言葉がない。490円をきりのいい 500円に切り上げる、でも実際の金額がそれより少ないことを示すために弱をくっつけて 500円弱という、んじゃないの。辞典が示してるのは前者でしょ。

500円弱を「500円より少し上」に割り当ててしまったら 500円強の行き場は?「500円より大幅に上」とか?聞いてみたい。

最終更新: 2009-08-25T02:45+0900

[正規表現][Firefox] XRegExp-1.0.1と Firefoxの /(?!)/

20090628p01で書いた Firefoxのバグっぽいものが XRegExpに影響するみたい。

// Firefox 3.0.11 + XRegExp 1.0.1 での実行結果
alert( XRegExp("[]").test("a") ); //=> true
alert(  RegExp("[]").test("a") ); //=> false

[] と [^] の意味するところってなんでしょうね。[] は空の文字集合だから「どれでもない一文字」とマッチする(=空文字列にもマッチせず必ず失敗する)。[^] は空の文字集合の補集合だから「任意の一文字」だろうか。

参考ページを見つけた > 文字クラス(http://suika.fam.cx)

結局、こういうことだ。

  • 主要 4ブラウザのうち [][^] が使えないのは IEだけ。
  • Opera(9.61)は [][^] がおかしい(他と違う)。
  • Firefox(3.0.11, 3.5RC3)は (?!)(?=) がおかしい(他と違うし、自分自身の (?!|)(?=|) とも違う)。

(IEの件を除いて)どのパターンも規格上の正解やデファクトスタンダードがなくて混乱してんじゃないかなあ。こういうのには近づかないに限る。


 追記@2009-07-04 04:44: 内容確認。

正しくコメントが読めてるといいんだけど……。

IEが空の文字セット [] を処理しないのは(ECMAScriptの仕様をすっとばして) Perlその他、JavaScript以外の多くの実装にならっているもので、[ に続く最初の文字を文字通りの文字 ] だとしているから。だから []][\]] と同じ意味になる。

Firefoxで (?!) の代わりに (?!|)(?=) の代わりに (?=|) を使うのは良くなくて、つまりこれらの結果は同じになるべきだけど、どちらになるかは将来の Firefox次第だから。バックトラックの発生にもつながって効率的にも不利。だから (?!) の代わりは \b\B(?=) の代わりは (?:) が良い。

\b\B というのは覚えておこう。


 追記@2009-07-04: はずしてた。

冒頭の指摘ははずしてる。考える前に、気付いたことをただ書いたせいだ。

XRegExpの目的の一つは、ブラウザごとにまちまちな挙動を見せる JavaScriptの正規表現に関するメソッドを仕様に準拠させることだったと思う(String.split()とか RegExp.lastIndexとか)。

だから空の文字セット( [][^] )を提供する第一の目的は 5ブラウザ(IE, Fx, Opera, Safari, Google Chrome)のうち不当にこれを受け付けない IEにおいて、仕様で許された正規表現パターンを利用可能にすること、かもしれない。

その過程で、Firefoxがネイティブに処理する空の文字セットと、XRegExpの提供する空の文字セットの挙動が食い違ってしまっている(1行目 1、2列)、というのが冒頭の指摘。でもこれは重要ではないし、同様の指摘を Operaについても行うことができる(3行目 1、2列と 3、4列)。

そうではなくて、ライブラリ利用者として「仕様に準拠した」「ブラウザ間で統一された」機能を望む視点から、XRegExpの提供する空の文字セットが Firefoxにおいてのみ違う意味になること(2列目)をこそ指摘すべきだった。(実際そうしたんだけど、日記の内容だけが古かったのでこうして追記している)

1列目2列目3列目4列目
RegExp("[]")XRegExp("[]")RegExp("[^]")XRegExp("[^]")
1行目Firefox(3.0.11, 3.5RC3)必ず失敗必ず成功成功したり失敗したり(後述)任意の一文字任意の一文字
2行目IE(8.0)例外必ず失敗例外任意の一文字
3行目Opera(9.64)任意の一文字必ず失敗必ず失敗任意の一文字
4行目Safari(4.0)必ず失敗必ず失敗任意の一文字任意の一文字
5行目Chrome(2.0.172.33)必ず失敗必ず失敗任意の一文字任意の一文字
 すごくおかしな Firefox(3.0.11)の (?!)

全てのパターンに (?!) が含まれているから、本当は全て falseになってほしい。

/(?!)/.test("abc")     //=> true!
/(?!)(?!)/.test("abc") //=> false

/^(?!)/.test("abc")    //=> false
/(?!)$/.test("abc")    //=> true!

/a(?!)/.test("abc")    //=> false
/(?!)a/.test("abc")    //=> true!

/\b(?!)/.test("abc")   //=> false
/(?!)\b/.test("abc")   //=> true!

/(?:)(?!)/.test("abc") //=> true!
/(?!)(?:)/.test("abc") //=> true!

(?!) が実質的にパターンの先頭にあるときだけ、存在しないかのように振る舞っているような。すごく限定された状況でのみ発動するんだったんだ。

ここまで書いてなかったことに気付いたけど、これが XRegExp("[]") に影響するのはこのパターンが内部的に (?!) に書き換えられるから。XRegExp (1.1.0, 2009-07-04)では \b\B に置き換えられるようになっていて、Firefoxのおかしな挙動に影響されて他のブラウザと違う結果になることはなくなっている


もう書かれてた! > http://blog.stevenlevithan.com/archives/xregexp-1-0/comment-page-1#comment-37653


 追記@2009-07-05 04:40: XRegExp-1.0の設計の良さを示す好例 > 20090703c02

自身の機能を XRegExp.addToken()で提供しており、ユーザーも同じ方法で拡張できる。トークンの有効範囲が文字セット [……] の内か外か、その両方かは addToken()の第3引数のビットフラグ( XRegExp.INSIDE_CLASS, XRegExp.OUTSIDE_CLASS )で指定できるし、エスケープシークェンスは予め処理されているので \(?!) を \\b\B に置き換えてしまう心配もない。簡単でしょう。

でも鬼車の \g を追加しようとして、名前付きキャプチャ内部のパターンを手に入れられず、中断。


 追記@2009-07-05 04:40: \gの実装サンプルを見てみた。

その \gの利用例が次。

XRegExp("(?<any_backref>\\3|\\4){0}     \
         (?<smiles>(?::-[D)])+){0}      \
         ([ab]) ([12]) \\g<any_backref>+\
         \\g<smiles>                    ", "x").test("a22aaa:-):-D"); // true

解説すると、まず名前付きキャプチャを使って再利用を前提としたパターンを定義する(any_backrefと smiles)。ポイントは量指定子{0}の存在で、現状ではこれが必ず必要になる。これによりこの名前付きキャプチャはマッチに参加せず、一文字も消費せずに成功する。その存在意義は \g<smiles> のように、後で名前を使ってパターンを再利用できること。

上の例で、実際に文字を消費するパターンは後半分、次の部分だけ。

    /([ab])([12])\g<any_backref>+\g<smiles>/

Rubyで同じ意図を持って書くとこういうふうになる。

irb> any_backref = /\1|\2/
=> /\1|\2/
irb> smiles = /(?::-[D)])+/
=> /(?::-[D)])+/
irb> re = /([ab])([12])#{any_backref}+#{smiles}/
=> /([ab])([12])(?-mix:\1|\2)+(?-mix:(?::-[D)])+)/
irb> re.match( "a22aaa:-):-D" ).to_a
=> ["a22aaa:-):-D", "a", "2"]

さて、パターンの再利用が \g の利用法だけど、個人的にそれが最大の効果を発揮するのは、パターン定義の中でパターンを呼び出したとき、再帰的なパターンを定義できることだと思っている。20080111p01で既に書いているが、

 /%[Qq]?(?<brace>\{[^\{}]*(?:\g<brace>[^\{}]*)*})/

名前付きキャプチャ (?<brace>……) の中に \g<brace> がある。こういう GNUの命名のような再帰的定義ができてこそ \g を利用する価値があると個人的には思う。

addToken()で \g を定義する方法として考えていたのは「パターン文字列を、上限を決めて再帰的に展開する」というもの。このように。

  1. (?<brace>{\g<brace>})
  2. (?<brace>{(?:{\g<brace>})})
  3. (?<brace>{(?:{(?:{(?:{\g<brace>})}))})
  4. (?<brace>{(?:{(?:{(?:{(?:)})}))})

実際の手順は addTokenの第二引数が文字列を返す代わりに toString()を定義したオブジェクトを返し、xregexp.jsの下の引用部分、output.join("") の時点で、名前付きキャプチャ内のパターンを参照してパターン文字列を返そうというもの。

            regex = RegExp(output.join(""), real.replace.call(flags, /[^gimy]+/g, ""));
            regex._xregexp = {
                source:       pattern,

コードの枠組みはこんなの。もちろんこのままでは動かない。

function PatternOfNamedCapture(name) {
	this.name = name;
}
PatternOfNamedCapture.prototype.toString = function(){
	// ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
	if(MAX_RECURSION < count++) {
		return "(?:)";
	} else {
		return output.slice(
			defs[this.name].start,
			defs[this.name].end
		).join("");
	}
	// ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
};
XRegExp.addToken(
	/\\g<([$\w]+)>/,
	function(match) {
		return new PatternOfNamedCapture(match[1]);
	}
);
本日のツッコミ(全4件)
Steven Levithan 2009年07月04日 (土) 02:22 JST

Actually, IE treats [] and [^] like Perl and almost every regex flavor (other than JavaScript) does -- because "]" is the first character in the class, it is treated as a literal character and does not end the class. Thus, /[]]/.test("]") returns true in IE, just like /[\]]/.test("]") in other browsers.<br><br>(?!|) and (?=|) are bad alternatives to (?!) and (?=). They *should* work identically to (?!) and (?=), so the fact that they don't is a bug and might change in future versions of Firefox. Also, the "|" alternation operator is introducing unnecessary backtracking. Instead, I recommend the following:<br><br>- Use /\b\B/ instead of /(?!)/.<br>- Use /(?:)/ instead of /(?=)/.<br><br>Sorry I can't write in Japanese. :-(

Steven Levithan 2009年07月05日 (日) 03:15 JST

Thanks for finding and documenting the Firefox (?!) bugs. XRegExp 1.1.0 no longer uses (?!), so now [] correctly fails in all browsers.<br><br>If you want to fix the Firefox (?!) bugs in XRegExp, it's very easy:<br><br>XRegExp.addToken(/\(\?!\)/, function(){return "\\b\\B"});<br><br>After running that code, XRegExp("(?!)") will work the same in all browsers. Maybe I will include this fix in future versions of XRegExp.

Steven Levithan 2009年07月05日 (日) 06:36 JST

Regarding your latest update (dated 2009-07-05 04:40), Oniguruma's \g<...> subpattern definitions could be added using XRegExp.addToken, but the big problem is that you need to be able to match nested parentheses like (?<name>.(.(.))) for it to work with named capture -- unfortunately, this is not possible using JavaScript regular expressions. There is an example of something similar under the heading "Subpattern Definition (Non-Standard, Non-Nestable)" at http://xregexp.com/api/addtoken_examples/

Steven Levithan 2009年07月05日 (日) 07:22 JST

I just updated the example page I linked to so that the solution is more similar to Oniguruma-style. I also changed the heading--just search within the page for "Oniguruma". However, it still has some significant issues, such as not allowing nested subpattern definitions and not supporting capturing groups within the subpattern definitions. It might be interesting for you, though.