・睡眠時間８時間くらい。寝る時間はだいたい０時前あたりで安定してきた。できればあと３０分早く寝て欲しいんだけど、まぁいいや。
・最適化中。
Sinとかはテーブル作って持たせるバージョンを作りたいなぁ。「だいたいの値でよければ、こっちが高速」みたいな。パーティクル関係ならそっちの方が良いんじゃなかろうか。
なんだかんだで師匠の本の影響はちゃんと受けてるんだな。ビット演算は使わなそうだけど、もう一度引っ張り出して読む価値はあるかもしれない。つか、絶版なのかあの本。
・楽水会の手紙も定期的に来てたので、「住所変更」なり「手紙送るな」なり伝える必要があるんだけど、公式ページを見てもさっぱり。いいやもうめんどくせぇ。ググってトップに来ない時点でもうめんどくせぇ。
・今日も余裕は足りない。余裕がない時の雨はうざったいだけだなぁ。楽しむ余裕がない。余裕があれば、「雨」を「大規模な物理的干渉行為」とみなしたりとか、色々と考えられるはずなんだけど。ほんとは雨ってすごいはずなんだよなー。あれだけの面積に、あの量の物体を、あの高さから落としてるわけだから。空気抵抗とかの関係で最終的な速度はそんなでもないけど。
・そもそもが全てのことは「手段」に過ぎないのかな。「人生の目的」なんてないし、全てのことは元を辿れば「人生の目的」に行き着くのだろうし。「何故最適化をするのか」「何故高速でなければならないのか」「何故ユーザにストレスを与えないようにするのか」「何故良いゲームを作るのか」「何故お金が必要なのか」「何故生きていく必要があるのか」みたいな感じで上のレイヤーに上がっていく。下のレイヤーでの「目的」は、上のレイヤーにとっての「手段」。「一番上のレイヤーでの目的」だけがいわゆる「真の目的（手段ではないもの）」足りえるが、「一番上のレイヤーでの目的」が実はないのであれば、その下の目的・手段も無意味だな。
で、戻ってくると、「どのレイヤーを不動の目的として設定するか」の問題あたりが現実的か。この「どのレイヤーの目的を固定するか」が違うために嫌悪みたいなあのコンフリクトの感情が発生する現象はよく遭遇する。主に観察したのは自分との違いだけど、他者同士の違いの推測の一助にはなるか。
この前観測した例としては「ゲーム会社が今のまま存続する」という前提の違いか。「目的」に置き換えると、「（今の構造の）ゲーム会社が黒字を出すこと」かな。構造としては「（今の構造の）マスメディア（TV、新聞）が生き残るには」という問題に似てる。完全には消失しないかもしれないけど、基本的には「自分は今の構造の中に入ったままではいられない」という前提の方が一般的かつ有用なんじゃないかあたりの云々。マスメディアよりは変化が遅いはずなので、その分の余裕はあって云々。
・なんかしばらく雨っぽいな。日曜は晴れそうなのが救いか。ちょっと色々と見て回って、必要なのをどこで買えば良いのか把握しておかねばならんのだ。土曜の朝はおとなしくゴミの分別でもしとくかね。
・そういえば、京急の駅って無線LANが使えるっぽいんだよな。ちょっと試してみたいところだけど。iTunesのアラートのメールとかが以前のアドレスのままだし。てか、もうアラートいいや。肝心なもののアラートが利いてないし。オフにするだけでいいや。
・嗚呼、余分な空白が耐えられない。TabじゃなくてSPACEでインデントしてるのが耐えられない。
そこまでは普通なんだけど、「0.f」という表記が耐えられないのもある。「0.0f」じゃなきゃなんかイヤなんだよなぁ。「コンマだけて」みたいになる。
・昨日、定期の範囲で途中下車してスーパーに寄ってみたんだけど、小型のIH対応鍋とかあるんだなぁ。あれならあの狭い流し台でも洗えそうだし、悪くないかなぁ。でも作り置きの量が稼げないんだよなぁ。ラーメン専用と割り切ればなかなか良い感じな気もする。安かったし。
コップすらろくに並べられないので、もう「食った後はすぐに食器を洗う」or「食う前に食器を洗う」ものと割り切れば良いのかな。
で、ラーメンだけじゃなく、他のものも小さい鍋で作れるようなものにすればOKとか。しかし、「鍋で一食分だけ作る料理」なんてあとは「コーンのバター炒め」くらいしか思いつかないぞ。
・しかしまぁ鶏皮を扱ってる店が近場に見つからない。鶏肉の鶏皮煮込みが作れない。
あと、ホームセンター的な店も見つからない。ネジとか物干し台とか買わねばならぬのに。
・「128bitをまとめて一つの値っぽく計算できる」ってのを見ると、上の方でもこれを利用した最適化方法が考えられるけど、そんなことやるくらいなら可読性の方を優先すべきな気がする。
・コード見るとコメントになんかすごいこと（ひどいことの方向ではなくて）がしれっと書いてある。すごいんだけど、勉強になるというより、「え？なんで？」という疑問の方が強い。しかし、そこまでいくとプラットフォーム側のライブラリに踏み込まないといけないのであれだ。
あぁそうか。ここらへんはアセンブラがわかるともうちょっと理解できる。しかし、アセンブラは半端にしか知らん。
・んん。しかし「勉強」になるなこれ。だんだん楽しくなってきたぞ。これならもっと将来有望な人間にやらした方が良いのではなかろうか。自分にはもったいないぞこれ。木の葉丸だこれ。
・上の「楽しい要素」をもうちょっと言語化したい。「この関数は使うのか？」「そもそも何に使うんだ？」「調査」「使ってねーから消す（プラットフォーム側にあるやつのただのラッパだった）」「こういう風に使うのか。確かに早くなるなこれ」みたいな流れの後半の流れの方。「地続きになった感」が大きいのかな。低レベルから高レベルまでの道が一つ見えるだけでも楽しい、みたいな。
「現象理解の楽しさ」がベースかな。「作る楽しさ」とは別種かな。
・４次元ベクトルのwの一般的な扱われ方がよくわからんな。「元の大きさ」を記憶しつつ「wでスケーリング（実際には逆数だったか）」が一般的だと思ってたんだけどどうなんだろう。
・とりあえず、仕事でゲームを作る際の「目的」は「バグのない（少ない）ゲームを作ること」あたり？プログラマ視点では。いや、もう少し広義に「問題のない（少ない）ゲームを作ること」か。「バグじゃなくて仕様です」というやつでも「問題」だったりはするし。ロードの長さとかな。
で、その「目的：問題のないゲームを作成」のための「手段」として「高速化：ロードまわりの問題解消」と「可読性の向上：エンバグ率の低下＆デバッグの効率上昇」などがあり、それらがコンフリクトを起こす、と。
・視野が狭いと物事が単純に見えるのは利点だ。
「構造がシンプル」なわけではない。スパゲッティコードの「goto HOGE;」という文だけを見て「単純」と思えているに過ぎない。
「正しく見れる」わけでもない。クラスや変数名のバッティングに気付いてないだけだ。
まして「正しい答に辿りつける」わけでもない。「何でもインライン展開すれば良い」という思考が正しいわけもない。
そこらへんの思考というか実感が足りないんだよなぁ、現実の物事の方だと。
・ここまで最適化バリバリのコードなんて見る機会はそうそうないだろうし、それが「すーぱーぷろぐらまー」達によって作成され、「これ以上の最適化は望めない」というレベルなわけで、そのコードの一挙手一投足すべてに意味がある。解釈の対象として濃密で、こちらが疑問に思った部分全てに相応の理由がある。これ自体が一つの「作品」に見えるくらい、「解釈の楽しさ」がある。すげーなー。
つっても、ここまで来るのがしんどかったけど！「良作。ただし英語」みたいな！「まず英語がわかりませんけど」みたいな！見たことない関数が並んでるんだもの！構文はわかっても単語がわかんないよ！
・興味が持てないものを無理矢理モチベ化するのではなく、別の興味を割り当てれば良いのかもしれない。ライブラリの高速化なら「こんだけ速くなった！」とかじゃなくて「こんなの思いついて、それが正しかった！」みたいな。いや、あんま良い例じゃないけど。とにかく、他人と同じモチベの持ち方にしようとするからダメなのかもしれん。「あらゆる最適化手法を詰め込んでやる！」みたいなのが一番自分のモチベにしやすそうなんだけど、これは本末転倒に陥る可能性もあってなぁ。いや、「速度を上げるという制限の中で、いくつ手法を詰め込めるか」みたいに、「制限」として取り込めば良いのかな。結果として最善に至るように制限をもうければ。
・とりあえずキリが良いのでここらで止める。次回は別のプラットフォームのやつから再開。
そういえば、自分の「キリが良い」の定義が他人と違うっぽいのはメモったっけ。レイヤーが違うだけっぽくはあるんだけど。
「HOGE(Val);//文としてキリが良いのでここで止める」
「void Bar(i_Val){〜}//関数としてキリが良いのでここで止める」
「Compile：コンパイルが通ったのでここで止める」
「Run：ちゃんと実行確認できたのでここで止める」
「Complete：タスクが一個終わったのでここで止める」
みたいな。最後のやつだけを「キリが良い」と呼ぶ人を時々見かけるんだけど、自分の場合は基本的には「Run」がベースで、場合によっては（長いコードにならざるを得ない時などは）「Compile」までで、さらに場合によっては「関数」までを含む。さすがに関数が閉じない状況まで「キリが良い」とは呼ばないけど。
