脳log[2010-06-07～]

最終更新: 2010-07-10T01:01+0900

♪ [正規表現] requireEnd(), hitEnd()

hitEnd

public boolean hitEnd()

このマッチャーが行なった最前のマッチング操作によって、入力シーケンスの終わりに達していたら、trueを返します。

このメソッドがtrueを返したときは、さらに新たな入力を加えると最後のマッチの結果が変わる可能性があります。

requireEnd

public boolean requireEnd()

入力を新たに増やすことによって、それまでのマッチが不成功に変わるならtrueを返します。

マッチが見つかっていたときにこのメソッドがtrueを返したら、さら入力を増やすとそのマッチがなくなることを意味します。マッチが見つかっていたときにこのメソッドがfalseを返したら、さらに入力を増やすとマッチが変わるかもしれないが、マッチがなくなることはないことを意味します。マッチが見つかっていないときにrequireEndを呼ぶことは、無意味です。

まず 1.5 で導入された hitEnd メソッドと requireEnd メソッドですが、 hitEnd メソッドはドキュメントでは入力の末尾がヒットした場合にtrueを返すとありますが、入力というのは領域を指しているようなのですが、末尾というのが最後の文字なのか末尾の位置なのかよく分かりませんでした。例えば aa をマッチング対象の入力シーケンスとして正規表現 aa でマッチングを行った場合、入力シーケンス全体にマッチしますが、この場合に hitEnd は false を返します。つまり最後の文字がマッチしていても true にはならないようです。ところが正規表現 a+ や a* でマッチングを行うと aa と同様に入力シーケンス全体にマッチしますが、この場合は hitEnd は true となります。つまりマッチした部分だけでなく正規表現パターン自体も hitEnd の返す値に影響するようです。

どちらも入力が一つの文字列におさまっていないときに役に立つメソッド。

1. 二番目の引用内容と、
2. requireEnd()が trueを返した場合と hitEnd()が trueを返した場合の対比と、
3. 自分が行文字列のリストを対象に鬼車でマッチングを行うときに欲しい機能から、

hitEnd()について想像するなら、

search engineが遷移先を残したまま入力を消費し尽くしたときに hitEnd()が trueになる。それの意味することは、直前のマッチが成功していたのなら、さらなる入力によりマッチの範囲が延長される可能性があるということ。直前のマッチが失敗していたのなら、さらなる入力によりマッチが成功するかもしれないということ。

ところで、hitEnd()が trueかつ requireEnd()が trueの場合って存在するだろうか。あるとして、どんな入力とパターンになるだろう。

requireEnd()はなくても困りはしない。マッチの範囲が入力の末尾まで続いていれば無条件に入力を増やしてリトライすることで requireEnd()が trueだったのか falseだったのかは確かめられる。

hitEnd()も、マッチが成功していたときは重要ではない。真価は、マッチが不成功だったときに hitEnd()が falseを返した場合は、さらなる入力をつなげてもマッチが成功に変わることがないと確かにいえること。hitEnd()がなければすべての入力を連結せずにはマッチが存在しないことを断定できない。

そうそうこれこれ。>http://www.mail-archive.com/classpath-patches@gnu.org/msg08501.html

さらに、こっちのドキュメントは詳細だしバグにも触れてある。上のスレッドで報告されてるのとは別のバグみたいだけど。

boolean hitEnd()

(This method is unreliable in Java 1.5; a workaround is presented on page 392.)

This method indicates whether the regex engine tried to inspect beyond the trailing end of the input during the previous match attempt (regardless of whether that attempt was ultimately successful). This includes the inspection done by boundaries such as \b and $.

If hitEnd returns true, more input could have changed the result (changed failure to success, changed success to failure, or changed the span of text matched). On the other hand, false means that the results from the previous attempt were derived solely from the input the regex engine had to work with, and, as such, appending additional text could not have changed the result.

The common application is that if you have a successful match after which hitEnd is true, you need to wait for more input before committing to a decision. If you have a failed match attempt and hitEnd is true, you'll want to allow more input to come in, rather than aborting with a syntax error.

最終更新: 2010-05-29T18:05+0900

♪ 作業ログ的なコメント

1. だんだん積み重なって邪魔になっていく。
2. コミットログに代替させたい。
3. コミットログは調べようと思えば調べられるが手間。問題解決の手がかりではあるが、(過去の経緯から)問題になりそうな点を警告したり、歴史の繰り返しを未然に防いだりはできない。(作業ログ的なコメントはいやでも目に飛び込んでくるのでそれができる)
4. ある行に関わるコミットのログをリストアップしたい！

だれかやってないかなー

コマンドラインクライアントでのやり方を考える。

1. svn ann で目的の行が最後に変更されたリビジョンNを知る。
2. svn diff -r N で目的の行がその変更以前は何行目(から何行目)だったのかを知る。(新規追加行であれば終了)
3. これを途中で得られたすべての行について繰り返し、途中で得られたすべてのリビジョンのログをリビジョン番号順に表示すればいい。リビジョンと行番号の組を降順にソートして先頭から処理していけば svn annの回数を最小にできるし、処理したそばから逐次ログを表示していける。

コピーとかペグ・リビジョン(「現在のファイルがrevision Nのときそうだったもの」と「revision Nのときに現在のファイル名だったもの」を区別するためのもの)とか考えるの面倒くさそう。

最終更新: 2010-05-29T22:53+0900

♪ [C++] これは真実？

仮想関数は、仮想関数テーブルに関数ポインタを保持するため、仮想関数の定義分サイズが増えることに注意。仮想関数を増やせば増やしただけ、オブジェクトサイズが増大する。

太るのは vtblで、これはクラスにつき一つしか存在しないんじゃ。「オブジェクト」=インスタンスではなくて「オブジェクト」=*.objという話ならわからないけど。

最終更新: 2010-05-24T13:30+0900

♪ 「Togetter - まとめ「今日の「おまい自分が何言ってるかわかってんのか」リスト・きっこ編」」

はじめこの人は、殺される牛を TVなどで見てかわいそうと無責任な感想を口にする消費者を批判しているのかと思ったがどうもそうではなさそう。

私は「自分の手で殺せる生き物」しか食べないことにしています。釣った魚は自分で殺せるから食べます。でも猫や犬を殺せないように牛や豚や鶏も殺せないので食べません。「命を食べる」ということは「命を奪う」という現場にまで自分が責任を持つことだと思っています。

という考え方には敬意を表するし、

鶏でも豚でも牛でも「食べたいから」という理由で自分の手で殺せる人は食べれば良いのです。私はかわいそうで殺せないから食べないだけですよ。

これももっとも。(あ、「自分の手で」か。俺はできないけど気にせず食べるよ。肉を食べるという行為が意味することを「想像する」ことは必要だと思うけどそれだけで満足もしてる) でも現場の人間を非難する次の二つは疑問。

残酷な殺戮が嫌なら転職すればよいでしょう。生き物の命を奪って現金に換えるという罪深い生き方を選択しているのはご本人でしょう。

いったいどこが侮辱なのですか？今まで数え切れないほどの牛や豚を殺してきた人たちが、こんな時だけ殺すことを「かわいそう」だなんて、こんな詭弁は前代未聞ではありませんか。

ちょっと動物に同情しすぎているのではないか。

俺は、動物を食用などのために殺す人間は消費者の代理で殺している、と認識している。お金を払って髪を切ってもらう、野菜を買う、そんなときと同じように、対価を払っているとはいえ自分にない技術・価値を提供してもらうことに感謝こそすれ、罪深い生き方だという見かたは微塵もわいてこない。ともすれば傲慢な考えということになるのかもしれないけれど、その行為は自分が行っている・望んでいると考えるのだ。だからこそ最初に引用した部分には大きく同意した。

それと、何が「かわいそう」なのか想像してみると、人間の血肉になることもない無益な殺生だからかわいそうなんだろう。伝染病の蔓延というマイナスを、ゼロにする益のようなものがないとはいえないけれど、それで納得できるはずもなし。

最終更新: 2010-05-19T16:21+0900

♪ [正規表現] 鬼車。条件付き選択。

348 nobodyさん 2008/07/27(日) 01:11:32 ID:sEx2Pn85
    質問させてください。

    サクラエディタに鬼車5.9.1を搭載して正規表現の勉強をしているのですが、手元にある詳説正規表現には

    (<)?\w+(?(1)>)

    このような例があり、<があれば>のマッチを試みる?ということができるみたいです。

    ただ、鬼車はこの表現をサポートしていないみたいです。
    http://www.geocities.jp/kosako3/oniguruma/doc/RE.ja.txt

    同様のことを鬼車でも実現する方法ってあるのでしょうか？ 

鬼車は条件付き選択をサポートしていないのが玉に瑕だと、以前から思っている。なんとかできないかと上の例で考えてみたら、こうなった。

(<|)\w+(\1{100}|>)

せこい。姑息だ。100ってなんだよ。こんなの( <abc<<<...(94個の<を省略)...<<<> )にもマッチするじゃねーか。

最終更新: 2011-04-12T20:54+0900

♪ Googleキャッシュ「ハイライトされているキーワード: ○○ このページへのリンクにだけ含まれているキーワード: △△」

Googleの検索は英字の大文字小文字、ひらがなカタカナの区別だけでなく、カタカナ英語と本物の英単語の違いも無視して検索結果を表示してくれるんだけど、キャッシュのハイライトがそれに追随できていないのが残念。「このページへのリンクにだけ含まれているキーワード」っていうのは要するに「このページの中にこのキーワードは発見できませんでした」っていうことなんだと、うすうす気付いてきた。多いんだもん最近。

キャッシュを使うのは、オリジナルがなくなってる場合、オリジナルの反応が遅い場合、ページが長大でマッチ箇所を見つけられない場合。ハイライトは 3番目のときに役立つ。検索語にジャンプするツールバーボタンがあいまい検索の結果からマッチ箇所を見つけられないのは仕方ないかな、と思えるけど、キャッシュは検索の主体(google)が返してるものだからハイライトされてないとがっかりだよ。

最終更新: 2010-05-29T12:31+0900

♪ Scala。「あると嬉しいぱたーんまっち」

Scalaの match-caseが Rubyの case-whenと同等のものにしか見えなくて、Cの switch-case的な使い方しか思いつかない俺は手続き脳？

 @2010-05-20 第15章 ケースクラスとパターンマッチ

いいタイミングでパターンマッチの章に到着。途中まで読んだ。caseに書けるパターンの種類は「定数パターン(Cなどでおなじみ)」「ワイルドカードパターン(いわゆる default)」「変数パターン(名前付きワイルドカード。変数はコンストラクターパターンの構成要素を束縛(？)したり、型付きパターンの一部として使ったりもする。必ず？小文字で始める)」「コンストラクターパターン」「シーケンスパターン」「タプルパターン」「型付きパターン(型テスト+型キャスト)」があり、「パターンガード(パターンで表現できない追加の条件)」が付けられる。※(かっこ)内は個人的な解釈であって引用ではない。

コンストラクターパターンに使えるのはケースクラスだけだと思う(試してないけど)。ケースクラスのイメージは const struct。コンストラクタに与えられた全引数を constメンバとして持つ。だからコンストラクタの逆、match式に与えられたオブジェクトを構成要素に分解してマッチング(深いパターンマッチ、らしい)を行えるんじゃないかと。

 @2010-05-29 第15章 ケースクラスとパターンマッチ 読了

パターンを書けるのは caseだけではない。変数定義や for式にも書ける。caseが書けるのは match-caseだけではない。部分関数として caseの並びを書ける。コンストラクターパターンに使えるのはケースクラスだけではない。24章で説明される extractors(抽出子)を使えば一般のクラスも使用できる(らしい)。

 @2010-05-29 Rubyでやってるww「Ruby でパターンマッチ - まめめも」

最終更新: 2010-05-21T11:58+0900

♪ [本]講談社 BOOK倶楽部メール　Vol.284 から

【Q3】電子書籍についてどう思いますか？

• 積極的に読みたい…5%
• 少しは読みたい…13%
• 読みたい作品が電子書籍でしか出てなければ読む…35%
• できれば読みたくない…27%
• まったく読みたくない…16%
• わからない…4%

5%とは。若干の興味がある人を足しても 18%。講談社のメールマガジンを購読する層にはほとんど支持されていない。作品本位で読みたい本のためなら手を出してもいい人と、積極的に遠ざけようとしている人がそれぞれ 3分の1超。なんでだよー。電子書籍の利点は

• 運搬の手間、保存の場所が必要ない。(本屋に足を運んだり、なにか「物」を所有したい気持ちはわかるけど、重い本を家まで運んだり、かさばる本をいつまでも部屋に置いておきたくはないでしょう。一部の本に限って印刷版を持てばいいんですよ)
• 軽い。(文庫一冊には負けるけど、予備を含めた数冊や、持ち歩くのをあきらめる大判の技術書にくらべたら圧倒的)
• ページを固定する手がいらない。(立てかけて食べながら読める)

これらのメリットのためなら、バッテリーが必要、初期コスト(端末代)が必要、書籍フォーマットの端末間での互換性に対する不安、DPI(画面の大きさと細かさ)の不足、耐湿性に対する不安(風呂に持ち込むのを躊躇する)なんて問題は、現在のデバイス(※携帯電話と iPadは含まれません)の水準でも目をつぶれる。必要なのは印刷物に対する 100%に近い(超えてもいい)カバー率だけ。