憂鬱な午後のひととき

『武士と世間』(山本博文)

なんとなく読んでみた. 「サムライはなぜ，これほど強い精神性が持てたのか」に対する答え. 著者によると, 武士は常に世間に対する評価を第一としていたのでいつでも死ぬ覚悟があったから, というものらしい. 「死が名誉であった武士社会では, 死ねば恥はそそがれるという合意がある. いさぎよい死は, 汚名挽回の最後のチャンスだったのである.」
だから今日では些細なと思われるようなことでも切腹してたそうな. ところでここは「汚名返上」がよいよね.

『武士道の逆襲』(菅野覚明)

ついでにもう一冊. こちらのほうが面白かった. 上記にもあるように, 本来の武士の考え方は, 新渡戸稲造の『武士道』のそれとは全然違うものらしい. というか, 『武士道』がもともと英語で書かれていたというのも知らなんだ. 明治時代に近代文明国家の仲間入りを目指したとき, 強い軍隊に必要な精神のあり方を確立するために, 国家(や天皇)に対する「忠」が必要になった(武士は私的な戦闘者だった). そして, 欧米に対してキリスト教のような普遍的道徳が日本にもあるよと示すために用意したのが「武士道」というキーワード. そこではキリスト教徒にもわかりやすい「義」を全面に押し出した道徳として説明されたものだそうな.

外交について

「負けしろ」を以て考量するのである。 どれほど外交内政上の失策を犯しても、どれほど政治的無策が続いても、それでも法治が継続し、内戦が起こらず、テロリスト集団が形成されず、略奪や犯罪が横行しない「民度的余裕」において、日本は世界最高レベルにある。

そういう考え方もあるのか. 確かに5年ほど毎年変わる首相でもやっていってるし. でもworking poorや新卒の内定率の低下などの問題は, その余裕が意外と少なくなってる徴候かもしれないと思うと怖いなあ.

Xorshift 乱数生成アルゴリズムを書いてみた。

ある程度は工夫しないと、最初のうちに似たような乱数列が生み出される結果となることは予想できるので

ちょっと試してみたが, x, y, z, wのうちどれか一つのbitだけ1でそれ以外が全て0の初期値で初めて乱数を生成すると40回前後で128bit全てのbitが立ち得ることが分かった. 任意の2bitだけが立ってる場合は35回ぐらい. だから気になるなら(そもそも気にする必要もあまりないと思うけど)30回ぐらい読みすればいいとかいた. そしたら

「複雑な関数増やしてバグる可能性」とか本気で言ってるとしたら笑える。

と反論された. まあ確かに「バグる可能性があるので…」は本筋には関係ないので余計だったかもしれない(ただし, 「複雑な関数増やしてバグる可能性」については本気です).

でも, rotateが

uint32_t rotate_left(uint32_t x, int n)
{
    assert(0 < n && n < 32);
    return (x << n) | (x >> (32 - n));
}

みたいにuint32_t決め打ちだったら別にそんなことは書かなかったと思う(今回のケースで必要なのはuint32_tのみ). 彼のコードは

template<std::size_t N, class Int>
inline Int rotate_left( Int x )
{
  typedef std::numeric_limits<Int> limits;
  static const std::size_t Int_bits = limits::digits + ( limits::is_signed ? 1 : 0 );
  static const Int mask = static_cast<Int>( boost::low_bits_mask_t<N>::sig_bits );
  return ( x << N ) | ( mask & ( x >> ( Int_bits - N ) ) );
}

だった. これは私は複雑な関数だと思った. 何をやってるのか分かりにくい. どうやらIntが符号つきな型であっても動くように一般化しているようだ. 理由は

C++で作るならビット数決め打ちとか処理系定義の機能に依存とか、したくないんだぜ。

だかららしい.

私は逆だな. ビット数とかシフト処理とか処理系依存な部分があるからこそ(処理系もある程度決めて)決め打ちにしないと危なくてしかたないと思う. 自分の場合は実際にチェックできる環境が(x86/x64用)gccやVCだけなことが多いので, それらをターゲットに決め打ちして, コードを簡略化することも多い. やみくもに一般化するよりはずっと安全だと思う.

実際のところ, 符号つきの型に負の数が入っているときの右シフトは処理系依存(算術右シフトになるとも限らない). 左シフトだって値がoverflowすればundefined. つまるところ上記の符号つき型にも対応してるかのようなコードは処理系依存. 彼の要求するレベルなら「バグってる」と言ってもよいのではないか.

長いけどもう一点, Xorshift アルゴリズムの偏りを除去するのに必要な「読み飛ばし」回数を見積もる

xor128 の場合は、ざっと 8 回ほど乱数を読み飛ばせば、初期状態に起因する偏りはそれなりに取り除ける、 という見積りを得ることができたのです。

見積もりをしたので実際の値を比較検討してみよう(今からする予定だったらすいません). 試してみると分かるが, x, y, z, wのうちxの最下位bitだけが0と1で異なりあとは同じ二つの初期値で乱数生成した場合, 11回読みとばした直後の値の上位16bitは完全一致する.

↓第１回「暗号検定」のやつ, 難易度Aのときに自分が答えたのは難易度Cと同じだったのでやっぱり解答不備だったということか. ちなみに難易度Aは百人一首を知らなくても解けなくはない. なぜなら, それらのHTMLのソースを見ると画像のファイル名が100017.jpg, 100019.jpg, ...だったりするので.

第１回「暗号検定」
私は難易度が特Aの出題のときから百人一首の本を取り出していろいろ考えてたけどわからんかった. Aの段階ではすぐ解けたと思って提出したけど不正解だったみたい. で, Bも出題されたので同僚にも相談してみた. やっぱりAとBの答えが同じものを指してるという結論になった(ちなみに私はAよりBが難しい, というか面白いと感じた)ので回答の仕方に不備があったのかなあ.

明治大学の普通じゃないプログラミング発表会2010
全くの部外者だし, どういうものかさっぱり分からんかったけど面白そうだったので行って発表してきた(カッコつけないプログラム, fac.c).
#内容は完全なネタなので本気にしないように. boost勉強会で話そうかとも思ってた.
会場は数十人ぐらいを想像してたら, なんと200人規模で, その上初っぱなからプレゼンのレベルが高くてびびった. まあでも面白くて刺激になってとてもよかった. 参加させていただいてありがとうございました. こんな研究室だったらとても充実しててやりがいがあるだろうなと. それから, 昔のTOWNS-MLでお名前は存じてたけど, 今回ようやく福地健太郎さんご本人にお会いできたのもよかった.
あと, どうでもいいけど明治大学の学生は歩く速度が遅かった.

msdnjp

米国マイクロソフトが最近行った某調査で「学んでみたいプログラミング言語は？」の回答でもっとも多かったのは F# でした。

そういやshuyoさんに教えてもらったけどbingでF#は検索できない. C#だとできてるので#を扱えないというわけではないみたい.

同僚にいただいたノートパソコン(gateway 1632j)にWindows Xpをいれようとしたけど, ビデオカードとサウンドがどうにも認識しない. 結局諦めてubuntuを入れた. Xつきなんて何年ぶりだろう. 8年ぐらいsshでしか使ってなかったので, あまりのきれいさと簡単さに衝撃をうけた.

duck typingのコメント欄

>たとえば、「each メソッドを持つ」必要があるというのを知るのはどうやればいいのでしょう？ソースを見る必要があるんでしょうか？
>ドキュメントやサンプルコードを見ます。

面白い. C++のtemplateによるduck typingは, conceptがそのドキュメントをコードにしてしまう枠組みを目指してたのかな. ポシャッたのが残念なところ.

スーパーのレジが混んでるときに, レジの人が客の細かい買い物を小さいビニールに入れるの, 物凄くうっとうしい. そんなんで一人あたり10秒とか時間かけてサービスと思ってるのだろうか. 6人, 7人並んでたらそれだけでトータル1分以上のロス. しかも一人当たりの時間がかかってる分, 行列が余計に長くなってる. その上「ポイントカードはお持ちだったでしょうか」みたいなけったいな質問されるともう.

論文提出直前の最終推敲の段階で, マシンが落ちた. 再起動してもキーボードを受け付けない. しばらく電源を落としてたら復活したが, まあそういうもんだ.

・日本応用数理学会のJANTセクションで発表してきた(資料). 発表は久しぶりで緊張した. 同内容はPairing 2010でも発表予定. 終わったら外は物凄い雨で道路が川になっていた.
・kinabaさん

別の話の中で魅力的に紹介されていた／モチーフとされていたから、という理由で読んだ小説ってどのくらいあるかな。いくらでもある気がするんだけどとっさに思い出せない。「冬のオペラ」のおかげで「椿姫」を読んだ。(略)

私もそれで『椿姫』(アレクサンドル・デュマ・フェス)を読んだ. 北村薫だけでもなんぼでもありそう. 『六の宮の姫君』(だったと思う)の「私」がちら見した「うっうっう」の『交換教授』(デイヴィッド・ロッジ). 同著者の『素敵な仕事』はおもろかった(amazonみると絶版ってなってるなあ). 『ターン』のあとがきで触れられていた『リプレイ』(ケン・グリムウッド). 『夜の蝉』の三題噺で触れられている和田誠の発案のショートショートは本文ではタイトルも著者名も言及されてなくてやきもきした. でも偶然図書館でそれが『三角砂糖』(今見るとメンツが凄い)だと分かったときはうれしかった.

明日のための資料をちまちまと推敲. PowerPointの数式エディタの癖にも大分慣れた. 左にアウトライン表示してると絶望的に遅いことを除けば(それって致命的?)そこそこ使える. 論文をTeXでやってる場合, 数式を一から打ち直さないといかんのが難点. うまくコンバートできればいいなあ.

・FAISに行ってみたが, 形式的な安全性の証明というのはどうもぴんとこないなあ. また機会があればきちんと教えてもらおう.
・階乗を求める

答えが整数って分かってるから級数を途中で打ち切って求めちゃえという例では, たとえば楕円曲線のj不変量(Fourier級数)の最小多項式を求めたいとき, その係数が整数であることから級数を近似計算で求めるというのがある(cf. e^{π*sqrt{163}}≒26253741640768744).

身近なものでは(有限和やけど)整数の多倍長乗算にFFTを使うとき, doubleでやって計算結果に誤差が出るけど四捨五入してOKとしちゃうやり方. 誤差が0.5を超えないようにという要請からFFTでできる桁数の上限が発生する(cf. 大浦さんの円周率の公式と計算法).

・がっちりマンデーで象印マホービンの魔法瓶の作り方. 真空にするため二重になってるガラスは外側を作ったあと, 一度半分に切って中にビンをいれて外側をつなぎ直していた. なんとなく切らずに作ってると思ってたので衝撃だった.
・i7 2.8GHz + Windows 7でも取ってみた. VCはVC2010, iccは11.1.

exp for i7 [clk]

	std::exp	remez5_0_log2_sse	remez11_0_log2_sse	exp_ps(参考)
icc(32)	43780	60021	71518	5324
icc(64)	17049	15921	11941	5750
VC(32)	31284	21314	32029	6495
VC(64)	63965	22259	31681	7813

こちらでは32bitだとVC, iccでstd::expの方が速かった. というわけで3日の発言は全面的に嘘, というわけではなかった. しかしここでも64bit VC遅い. 同じVCの32bitより遅いというのはおかしい. 何かオプション間違えてるのかな.

(書く前にざくっとは計測はしたのだけど)ちゃんとベンチマーク取らずに書いてしまった. 反省して取ってみる. オリジナル関数が入出力が1変数になっていたのを入力と出力に分けて要素数 = 1020でループを回してrdtscで平均値を計った. CPUはCore 2 Duo 1.8GHz. WindowsはVisual Studio 2010, LinuxはNaoki Okazakiさんのと同じgcc 4.1.2で.

exp [clk]

	std::exp	remez5_0_log2_sse	remez11_0_log2_sse	exp_ps(参考)
Linux(32)	182219	30668	53304	8368
Linux(64)	177225	17477	33738	7899
Win 7(32)	36384	16784	27488	6927
Win 7(64)	48912	20435	28621	12601

というわけでVCでもremez11_0_log2_sseは1.3～1.7倍ぐらい速かった. 嘘書いてまことに申し訳ない. でもgccのexpが遅いのは確か.

fmath::exp_psはfloatの4並列版. 精度はremez5_0_log2_sseぐらいあるかどうかなのであくまで参考値(にしてもなんでWin64で遅いんだ).

expの高速計算
残念ながらgccのexpがタコなだけ(cf fmathのベンチマーク)で, VCやiccのexpはその高速バージョンと同じぐらいの速度が出る. よっぽど根性入れないとそれらに勝つのは難しい. 自分でもfmath作っててなんだけど, icc + core i7だとあんまし変わらないときもあって悲しい. あと, ベンチマークで10000000個テーブルに入れてやってると80MBのread/write になってメモリ性能の影響も大きい. もっと小さいテーブルセットがいいと思う.