/ 最近 .rdf 追記 設定 本棚

脳log[2010-06-02~]



2010年06月02日 (水) 『プログラミングの魔導書』株式会社ロングゲート。明らかに長門(有希)。C++界隈にそういう人がいるって噂も聞いたことがある。まあ買うけど。Amazonで売ってね。


2010年05月31日 (月)

最終更新: 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.

本日のツッコミ(全4件) ツッコミを入れる

ds14050>ところで、hitEnd()が trueかつ requireEnd()が trueの場合って存在するだろうか。 a..

ds14050なぜだか上のコメントがスパム扱い。@data_path/log/debug.logを見た。 >I, [2012-0..

ds14050>[\/url] ではなく \[\/url] が正しい。 正真正銘正しいのは \[\/url\] だった。 しかし..

ds14050>requireEnd()はなくても困りはしない。マッチの範囲が入力の末尾まで続いていれば無条件に入力を増やしてリト..


2010年05月30日 (日) [リーンベル] 二周目終了。チャージするとグレネードの投擲モーションがスパイクになったりボウリングになったりすることに大聖堂(ラストダンジョン)で気がついた。プレイ時間は一周目が 140時間くらいで、二周目が 40時間くらい。グレネードひと筋のリーンベルのレベルは 30台。グレネードは常に供給に不安があるのと一度に一カ所しか攻撃できないのとチャージ速度とチャージ加速度が固定なのがつらい(だからモーションが変化することを最後になるまで気付かなかった)。ハンドガンで有名なゲージクラックを利用したハメはグレネードの専売特許にしてもよかった。


2010年05月29日 (土) NHK夕方のスターウォーズにヒナギクさんがいた。

最終更新: 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月26日 (水) Togetter - まとめ「『RPGにシナリオは不要』に対するシナリオライターの考察」」 「シナリオライター」とは生田美和。アセルス編と宝石泥棒編は両方のゲームで一番印象的だったシナリオ。だからこそゲーム関係者の名前で「ほりい」「さかぐち」「あまの」「かわつ」「きょん」「まつの」「こじま」に加えてこの人の名前を知っている。


2010年05月23日 (日)

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

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

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

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

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

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

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

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

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

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

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

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


2010年05月22日 (土) 本の帯はどうしてますか?Twitter,はてな,GREEを使って徹底検証! | ブクログお知らせブログ」<カバーの内側に装着しておりまする。残したいけど付けたままは見苦しいしすぐ引っかかって破れるし読むときずれて邪魔なので。折り目をつけ直さないとたるんで(カバーの外周と内周の差)しわが寄るのが難点。自炊してもカバーだけは残しておこうと思ってるけど帯も残しそうな気配。


2010年05月19日 (水) [SakuraEditor] コードブロックの折りたたみっていうのは、アウトライン解析の結果(ツリー)を別窓でなくエディタ自体に表示するようなものなのですね。byte_stream>char_stream(codepoint>glyph)>line_stream>layoutline_streamの上にさらに folding_streamを乗っけるイメージ?

最終更新: 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 でパターンマッチ - まめめも

 必ずかどうかは不明。書かれていたのは、1.大文字で始まる定数名はそのままその名前が定数パターン。2.小文字の名前は変数パターン。3.小文字で始まる定数名が存在していてもその名前は変数パターン。3.`バッククォート`で囲った小文字の名前は例外的に定数パターン。=>大文字で始まる名前があって、その名前の定数が存在しないときは?


2010年05月18日 (火) [790FX-GD70] BIOS v1.B, v1.C


2010年05月15日 (土)

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

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

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

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

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

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


2010年05月12日 (水) ロールケーキを通販で買ったのだけど、そこがあまりにも現代の日本に過剰適応していて辟易した。まずはさ入れ言葉。TV(ビストロスマップでの中居くん)でおなじみですね。次は敬語。無礼なんじゃないよ。田舎の銀行の支店のお偉いさんの慇懃無礼に話を聞かない態度とは違う。敬語は相手をもち上げると同時にへりくだるものでもあるので、「お客様は神様です」の誤った解釈を信じて疑わないような過剰な敬語は、ここの従業員は奴隷のような扱いを受けているのではないかと心配させる。まあ、この対応に文句をつけるようじゃあそれこそ何様だろうけど。


2010年05月11日 (火) 難しい問題があると聞いて、そのために数独リソルバを Rubyで書いた。この前より難しかった。今回は能力が及ばず総当たりで解いている。9×9の問題で数分かかる。終わらないんじゃないかと心配になるので生存確認としてデバッグ出力を含めていたら、答えを見つけるのに正規表現検索が必要な始末。分岐ごとにスタックに継続情報を追加するんじゃなくてスレッドやファイバーで処理を並列化したらマシになるか……とか考える前に枝刈りをすべきなんだろうけど。どういうアイディアがあるだろう。


2010年05月10日 (月) アホらしいのではてブのリンクを辿ったりもしない。これ(ノートPCの加熱は化学式クーラーで自然発散「NCLB5BK」)と同じレベルの日本語じゃないですか。> 「第16回 近い将来、日本中がリストラになる:日経ビジネスオンライン(business.nikkeibp.co.jp)」それは大変だ。俺もおまえも、京都も大阪も、リストラだ。ところで、リストラってつおいのですか?