． 4時。11章まで終えた。あと3章やったら、 章の題名を見直す。目次は帯に印刷されたりするので、 目次だけ見て何をやる本かわかりやすいように 章の題名をいじることにしたのである。
． 朝までに片づけられれば、オタマをひつじこの実家へ連れていける。 夜には帰ってこないと、夜ひつじこが苦しくなる時間に 家にいられないので、行くなら昼前に出ないとダメだ。 今回は泊まりはまずい。 あーでも、とりあえずもう寝た方がいいか？ 月曜の朝までに終わってりゃいいわけで、 今日がんばりすぎると昼間持たんぞ。
． いや、ダメだ。顔を洗って続行しよう。 明日産まれてしまえば、作業が止まる。 そうすれば確実に入稿が遅れる。ありえない。9/5入稿だからな。 一刻の猶予もない。
． 目次がヤバい。X.X.Xまで目次に載ると思わなかったので、 見出しが最近のラノベのように長いのだ。 「押す暇がないし、押せてもわからない.」みたいな見出しが ズラズラ並んでいる。センスが疑われる上に、 文字数が多すぎて目次がえらいことになっている。 でも、これとても全部は直せないし、 文脈上はこれでいいのである。 そして、だんだんこれでいい気がしてきた。 目次にX.Xまでしか載せなければ簡単に解決するが、 むしろこのひどい見出しを並べることで、 目次を見ただけでこの本が異様なことがすぐわかる。 ノリがおかしいことが一瞬でわかるというのは、重要だ。 特にひどい見出しだけ変えて、あとはこのままにした方がたぶんいい。
． 終わったぞ...8時か...念のためデータをzipして送っておこう... もう数日会社に来られないかもしれない。
． ThinkpadX240sが保証4年付きで17.3万で買える。だが待つべきだ。 解像度が低いと絶対後悔する。 つうか、201sの不満は17万払うほど大きくないだろ。冷静になれ。
． レイトレが面白い。やばい。こんなに面白いのか。 しかし今そんなことをしてる場合じゃないだろ。
． 23時。たぶん最終になる直しをしている。4章まで。
． レイトレレイトレ。なんか成り行きで先にやってみることにした。 といっても、とりあえずはすぐできる範囲でしかやらないが。
． 徹夜一回でどこまでできるか、という縛りでやってみた。 完全鏡面、球と無限平面のみ、発光体のみ、交差判定高速化なし、 8スレッド並列CPUのみ、 レイの分岐なし、リアルタイムのみ。 これくらいなら一晩でできるわけだ。 ラスタライズの時に必要になる射影行列みたいなトリッキーなものがないので、 かえって楽な気すらする。まあ地獄はこの先だがな。 レイの分岐が入った時にどれくらい恐ろしいことになるかは是非とも見てみたい。
． パストレースってやつをレイトレの一種だと思ってた。 というか、それがレイトレだと思ってた。 携帯電話とPHSの関係みたいなもんなんだろうか。 PHSと携帯電話の一種と見るか別物と見るかは微妙、みたいな。 用語は良くわからんなあ。
． 数字が入ってる方がわかりやすい、というのはわかる。 しかし、「わかる」の定義が問題だ。 形として曖昧に「あーそんなもんだな」と思って欲しい時に、 数字をつっこんでも大丈夫なのだろうか。 「あーそんなもんだな」というタイプの理解は得られるのだろうか。 数という記号が入ることが、イメージ的な脳の働きを阻害しないだろうか。 でもまあ、とりあえず例示として数をつっこむくらいは必要か。最初と最後を記号にし、 間は図形で行ければ理想。金曜に返ってきたら少し直すか。
． CG技術は「負けたくない」という程度なら買った方がいい。 アンリアルでもUnityでもなんでもいいだろう。 使ったことがないので使い勝手まで含めてどうかは知らんが、 記事やら聞いた話やらから判断する限り、自作する利点はもうない。 しかしそれでもなお、「差別化したい」なら自力でやらねばならないと思う。 ただし、最低でも凄まじい苦行か、すごいアイディアのどちらかが必要になる。
． ただし、レンダリングエンジンを買うからといって、 絵で勝負しないというわけではない。 絵で差別化したい製品でもレンダリングエンジンを買うという選択肢はある。 ただ、レンダリングに関するプログラミング上の技術では勝負しない、 というだけのことだ。 モデリングやコンセプトで勝負すればいい。そもそもそっちの方が重要だ。
． UnityとかUEとか見てると、 自分でレンダリングするという選択肢はもう99%ないんだなということがよくわかる。 そして、そういう時代においては、 ハードの設計が多数派からズレていることは致命傷になる。 WiiUがマルチ八分を食らってるのはそのへんかもしれんなあ。 あれに特化して作れば相当いい絵が出るはずだが、 「レンダリングは買ってくる」という前提で考えると、 そういう特化設計をやるという選択肢は消え失せてしまう。 任天堂が自前でハイエンドグラフィクス路線のゲームを 作れば多少は話も変わるのかもしれないが、 そうなるとマルチでないのが痛い。 マルチで出るゲームであれば、同じもので各機種の比較ができる。 性能に序列をつけやすい。 「機械にも得意不得意があるので、同じゲームで比べるのはナンセンス」という事を 素人にわかってもらうのは無理だ。 性能にもいろいろある、なんてのは専門家だけが知っていればいいことで、 普通は数直線上にゲーム機の性能をプロットできると思うだろう。 「パーティクルはアホほど出るがテクスチャはちょっとしか置けないPS2」 とかの時代はまだわかりやすかったがなあ。
． これを読んで、 競技者が出るような習い事教室と同じシステムだったのかと合点が行った。 本気度の低い人の金を本気度の高い人につっこむシステム。 習い事程度なら所詮趣味なのでそれでいいんだが、 学校でそれをやられると社会としてはダメージがでかい。 金を払うだけだった側も、いつか卒業して何かしらの仕事をせねばならんのである。 そいつらの人生は過酷なものになるし、 そいつらを雇う側にとっても辛い。 集中投資された「できる子」が、それを補って余りあるくらいの 働きをしてくれれば社会全体ではプラスになるかもしれないので 否定はできないのだが。 実際、近くにゲーム専門学校出で大活躍してるのがいるしな。
． なんにせよ、すべきと思うことをしよう。 一回授業しに行ってみたいけどなあ。ゲーム専門学校。 有名になったらそういう話来るだろか。 有名になりたいなあ。有名になってみないと見えないものがあるし、 有名であることでやりやすくなることがたぶんある。
． こええ。専門家から見て技術的にヤバい、というのは本当にヤバい。 malloc本は技術の高い人にチェックしてもらわないと絶対ダメだ。
． オブジェクト指向関係は怖い人がたくさんいるので、 「オブジェクト指向ってのはこんなもんだ」とか言うのはやめた。 オブジェクト指向がしてくれることの一つの例を示すに留めた。 よしマイルドになったぞ、と思ったのだが、 気がついたら「オブジェクト指向を理解しようなんて思わなくていい」とか書いてた。 でも、これ、本心だ。説明が客観的に間違ってるのはマズいが、 主観的な姿勢が気に食わないのは別に問題ない。うん。これでいい。
． ついに産まれるのか。なんかドキドキしてくる。 でも今日ではなさそう。
． 今日はCG本の前書きと目次案を書いてみる。
． 一瞬で頓挫。コード書いて動くもの作らないと全く書けないことがわかった。 結論も流れも読めなさすぎる。始めるのは簡単だが、 いざ始めると凄まじく長い道のりになる。これは今始めちゃダメだ。 対抗してプレビュー版を作ってweb公開するぜ！ とか思ったが、前書きと目次と1章を書くためには、 最低でも半分くらいの章の内容は見えていないといけない。 本のコンセプトすら実装状況次第で修正され得る。 これはダメだ。始めて3ヶ月は文章にはかかれないと思った方がいい。 まずコードを書いてかなりのところまでやってしまい、 その後改めてコンセプトを考えてストーリー展開を考え、 その後で再度最初からストーリーに沿ってコードを書きながら 文章化していく。そういう流れにしないとうまく行かない。 malloc本のように簡単には行かないということだ。 そのmalloc本ですら、後から3章にソートが入ってきたりして 相当に流動的なわけで、ちょろっとプレビュー版出してジャブ打とうぜ、 なんてのは無茶である。
． 集中してmalloc本を片づけよう。CG本のことは一旦忘れる。 せいぜい歩いてる最中に妄想する程度にしておこう。
． そのうちプログラミング入門オブジェクト指向編を書こうとか思ってたが、違うな。 そう言えば確実に叩かれる。そうじゃない。 続編を出すとすれば、単に作るものを大きくすればいい。 自然にいつも使っている概念を足したくなるだろう。 もっとも、本当にそうなるとは限らない。 それを解決するのに別の策が思いつくかもしれない。 結論を決めないまま歩くことも必要だ。本では言わなかったが。
． オブジェクト指向ってのは、便利になるようにいろいろ機能足してたら、 書く側の認識もそれによって変わってきて、 気がついたらそんな概念ができてた、みたいなもんなのだろうか。 それとも、誰かが理論を提唱して後から実装が作られたのだろうか。 まあどっちでもいい。歴史的な事実は問題ではなく、 問題なのはうちらが使う上でどのようなストーリーで理解すれば都合がいいか、 ということだ。 それを考えるには、オブジェクト指向言語を作ってしまえばいい。 私は要領が悪いので、たぶんそれをやらない限り理解できる日は来ない。 実際に作らんでも作ろうとしてみればおおよそわかるだろう。 そして、作る時にはオブジェクト指向なんて言葉は忘れて、 とにかく「デカいものをロクに会話できない大人数で作るならどんな機能を足すか」 を考える。その結果同じものになれば、ああそういうことね、と思えるし、 違うものができれば、なぜだ？と考えれば深く掘れる。
． javascriptの型定義の仕様を今更知った。 型らしい型なんてないじゃんこれ。辞書だ。ハッシュテーブル。 あるブロックでの状態の集合もハッシュテーブルっぽいな。スコープ。 あと特徴は、関数の操作に関して制約がほとんどないことか。 なるほど、こうすれば妙な要素を増さずにいろいろとできる自由度が得られる。 これはエレガントだ。 だが、この自由度はガンだろ...拡張を封じる方法はないようだしな。 コンパイラの類はかなり単純化できそうだが、この自由度はヤバいよなあ。
． Javascriptにクラスはないと言っている人と、クラスという言葉を使う人の 間には単なる技術レベルの差以上の溝がある気がする。 クラスはないと言ってる人は、このエレガントな自由の楽園を受け入れている。 自由の代償を支払う用意があるか、 自由のマイナス面が見えるようなことをする気がない。 しかし、クラスという言葉を使ってどうにか 他の言語の枠組みを持ちこもうとしている人は、 たぶんそうではない。自由に価値を見出だしていないか、 自由のデメリットを重く見ている。 10人で50万行書こう、なんて思うと、 結局規律を設けてあたかもJavascriptではないかのように コードを書くことを強いられる気がするなあ。 10人50万行以上の規模でweb開発したいというところにニーズがあるのなら、 長期的には別の言語を用意すべきなんだろう。それがJavaだったんだろうが、 なんか流行ってない。でかいせいかもなあ。 Javascriptを吐きだす別言語、というアプローチもあるようだ。 なるほどそれが現実的だろう。つうか誰かC++を javascriptに直すコンパイラを書いてくれ。
． 関数特別扱いする必要なくね？というのは実際そうだ。 Sunabaもそうしようと思えばできた。 実際途中までは関数の中でも関数を好き勝手に作れたのだ。ただ、 素人がいじる言語でそうできることには何一つ利点がない。
． 「括弧の中では外は見えます」は一貫した規則だ。 しかしこれで言語を作ると、相当にややこしいことが起きる。 そのややこしいことをjavascriptは許容していて、 魔法使いな人達はそれがたまらないらしいし、うまく利用してもいる。 さて、それがややこしく見えるのは私が先に静的な型を持つ言語に慣れているから かもしれない。
． でも、普通に考えて、やりたいことをおおよそ無理なくできる限りにおいて、 自由度は低い方がいい。動的でなくていいものは静的がいい。 多いよりは少ない方がいい。 高級言語はつまり自由度を下げることで生まれている。 例えばある場所で見える名前は最小であるべきだ、と考えるならば、 「特別に指定がない限り外の名前は見えない」とするのは理にかなう。 ただ、それを徹底すると、if文の中で外の名前は見えてはいけない、 ということにもなりかねない。if文のブロックの中に外の変数を持ちこむために 何かしらの記法を用意せねばならないとしたら、それはさすがに不便だろう。 そういう言語もありうるとは思うが。 結果、例外がたくさんできてエレガントからは遠くなり、処理系は大きくなる。
． なんか書こうとしてる本と市場を食い合う本が出るっぽいぞ。 よし、正面から戦おう。競争がないと盛り上がらない。
． 相手は監修がついてるんだよな...超ひも理論の学者さんか。すげえ。 数学できるんだろうなあ。 戦うなら誰か専門家に推薦の言葉でももらって帯でアオらないとダメな気がする。 まあ私はそういうアオリで買う気になる人の事がまったくわからんのだが。
． というわけでジャブがわりにfacebookに概要を書いてみた。 前書きと目次案と第一章くらい書いてお試し版として置くか。対抗して。 産まれたらすぐやろう。もし気が向いたら明日やろう。 あるいは今日の夜かもしれんが。
． そのうちMTFrameworkみたいなものを一人で作る本書いたら売れんのか？ 問題は、そんなものを作るスキルが私にはないことと、 仮に作れたとしても規模がデカすぎて一冊の本にするのは不可能だろう、 ということだな。つまり無理。 そもそも需要ねえよそんなもん。 ゲームエンジンアーキテクチャって本がそういう本なんじゃないの？ 読んでないけど。
． まあ私が書く本は、全て書き始めた段階では私がわかってない内容なんだけどな。 テトリス本すら、書き始めてみたら予想以上に深かった。 何を天秤に乗せてどう考えるべきか、ということの掘り下げが甘かったのがよくわかる。 この本が売れなくても、私が成長した分だけでプラスになるはずだ。 でも売れてくれ。
． 夜はコードのチェック。それが済んだらmalloc本に戻るか、 気分が乗ればレイトレ一発目のコードを書くか、文章を書くかする。
． カツオ食わせたら激しくジンマシン。そういやそうだった。失敗。 炭水化物断ちをしていても、ダメなものはダメなようだ。
． アメリカにはいい本がいっぱいあるけど日本はさっぱりだ、 というのは事実なんだろう。私はそれを否定したいわけじゃない。 ただ、その「いい本」は技術的に高度な本だと思うんだよ。 私が欲しいのは、やる気も才能もイマイチな普通の人を 最短で戦士にする本だ。 アメリカ人は世界中からやる気のある奴を集められるので、 やる気がない奴の相手をしなくていい。 だから、高度な本に偏っていても全く問題がない。 読める奴はゴマンといるからだ。 しかしうちらは、この狭い日本の中で人間を調達せねばならん。 選ぶという贅沢は許されない。 そこにいる奴を確実に戦士にせねばならないのである。 上級者は英語の本でも読んでりゃいい。 できる奴は勝手に英語の掲示板や論文を漁って情報を拾ってくる。 問題はそうでない奴をそれができる状態まで持っていくことだ。 それも低コストで、確実に。 本なのか教育カリキュラムなのかはわからんが、何かが必要だ。
． 日本人は英語に関して圧倒的に不利な状況にある。 放っておけばガラパゴスになるし、ガラパゴスにならんように がんばれば、英語にコストをかける分だけ他がおろそかになる。 したがって、基本戦略は英語をがんばることじゃない。 弱点を強くするよりも、弱点が無意味になるようにした方がいい。 情報共有で劣るなら、情報共有で劣ることが不利になりにくい 戦い方をすればいい。標準化とか共有化で劣るなら、 個別化と自前主義を突き進めばいい。 もちろん、何事も匙加減で、100%そうすればコストと品質で 負けるだろう。また、分野によってはそれではどうにもならない ことも出てくる。とりわけ先端分野や大規模化が必要な分野では どうにもならん。しかし、そういう分野は元々勝つのが 無理な分野なのであって、そこで戦うこと自体が間違いだ。 そんな土俵に上がった段階で負けである。
． それに、労せずして英語を読めて 他からモノを持ってこられる人は一定数はいるのであって、 そこは最大に利用すればいい。それだけでも結構なことはできるし、 良く見れば大した労力をかけずに英語が使えるようになる 人間はそれなりにいる。そういう人間はもっと英語を学ぶべきだ。 海外にバンバン送りこんだらいい。 ただし、英語で劣り、海外から情報を持ってくることが 苦手な人間はどうしてもいる。 つうか、私はそうだ。 なにせここは日本なのである。
． であれば、もういいから何でも自作しちまえよ。 そこそこのものならなんでも自作できるだけの スキルを持った人間が掃いて捨てるほどいて、 全員が「オレが作ったものが最高！他人が作ったものなんて使えるか！」 とか言ってる状態にすればいい。そんな心強いことはないぞ。 会社の全チームがバラバラに何の協力もせずに それぞれ製品を作れるとしたら、それは相当にすごいことだ。 それを目指す方がまだ目があると私は思う。 まあ、どうでもいいものは買えばいい、とか、 他人の良い所を取り入れる、とかいう考え方は必要なのだが、 そのために自作する気概と能力を失うよりは、 他人に全く学ばない方がまだマシな気がする。 少なくとも変な製品は出てきやすい。 もちろん、最終的には匙加減の問題になるわけだが。
． 2chで「gems読め」とか言ってる奴がいるが、 そいつはすごくできる奴か、適当に言ってるだけかのどちらかだ。 gemsをまともに読んで応用できる奴が何人いる？ だいたいあの本、テクニック集じゃん。教科書じゃない。
． 本って価格感受性低いんだろうか。低くないと定価で売る特権がかえって 利益を削りかねない。 後で値下げして売りさばきたいと思っても価格を下げられないことが不利になりうる。 あーでも、廉価版出せばいいだけか。文庫とか。 ただ在庫の問題があるからそれが完璧な解決策にはならない。
． 誰かに多大な恩を受けたとして、 その人にお礼をしたいという気持ちは持ち続けるべきだが、 むしろ社会的には、誰かに何かをしてもらったら、 全然関係ない誰かに同じくらいのことをしてあげる方がいいらしい。 その方が社会が良く回る。理屈としては贈与の経済とか言われる奴だ。 でもそれはそれとして、ありがたすぎる。 本当助けられて生きてんなあ。 私も誰かを助けて生きられるといいんだが。
． 今更13章の一部の説明をごっそり直した。しかし、 元々「ここは適当でいいだろ」的に書いていた部分で、 どうせ厳密な証明を書くわけにも行かず、「あーそんなもんか」 と思ってくれればいい場所なのである。 しかし、なんぼなんでもこれはいいかげんすぎだろという話になり、 やけに詳しく説明してしまった。こう直すことがいいのかどうかが よくわからない。
． 前の本は、 「読めない奴はゲーム屋のプログラマとして飯を食うのは無理と断言していい本」 として書いた。読めない奴はゲーム屋になろうとか思わない方がいい。 今回の本はそれを一歩進めて、 「読めない奴はプログラマとして飯を食うのは無理と断言していい本」 として書いている。読めない奴はプログラマになろうとか思わない方がいい。
． ということを、ここに書くのは平気だが、 twitterに書くのはまだはばかられるな。ヘタレ。
． ゲームを動かす技術と発想、っていうのがいいらしい。賞もらってた。 読もう。ところで、本とか書くようになると、参考資料と称して 出版社の人が本を送ってくれたりする。 このまえもガベコレの本もらったし、 その前は初心者向けっぽいのを10冊くらい送ってもらった。 なんか特権階級になった気分になる。いかんな。 ちゃんと自分で読もうと思った本は買わないと。
． 「ゲームプログラミングのためのリアルタイム衝突判定」 は、だいぶ難しいと思うんだけどなあ。 「コリジョンどうやって書いていいかわからん」とかいうレベルで読む本じゃないだろ。 アマゾンにそういう感じの書評あって、大丈夫か？と思った。 一通り自力でやってみて壁に当たった後で読まんと 後ろ半分は全く無理じゃね？BSPとか作ってみりゃわかるが、 私程度だとかなり手こずるぞ。doubleで書いていいなら楽だけど。 それに、検出だけできてもそれは必要条件であって十分条件ではない。 問題はその後だろ。
． 最近は「私が難しいと思う内容は、一般的にも難しい」 という傲慢な仮定を置いている。何か本を読んで、 「読みたくねえなここ」とか「こんなにごっついもんいるの？」とか 「え、何の話？」とか思う本は、たぶん難しい。 いや優秀な人はなんぼでもいると思うんだが、それは優秀な人だけを見るようにすれば、 とか、優秀な人しかいない場所に行けば、という話だ。 cedecで会う人、なんて限定を置くととんでもなく認識を間違う。 この前ゲーム屋にアンケートしてたが、 あれはcedecに行く人限定だから、全くと言っていいほど役に立たないと思う。 cedecに人を行かせるような会社の、cedecに行かせてくれるような人材限定と 考えれば、その役に立たなさがわかる。
． 九州大学の奴だが、二人だけ個人メアドをもらってたのを思い出したので、 その二人には講評を直接返しておいた。
． 私は初心者向けにしか書く気がない。 というのも、自分が中級以上だと断言するだけの自信がなく、 そもそも技術そのものにさしたる興味がないからだ。 しかし、校正で読んでて思うんだが、 これ初心者向けじゃなくね？技術面では初心者向けだし、 私は本気で初心者向けで書いているわけだが、 物の進め方とか思考のパターンとかトレードオフとか、 そういうものについてこれだけ語ってる初心者本なんてないだろ。 むしろそっちを理解するのに嫌気がさしたりせんだろか。 初心者はやっぱり言われた通りコードを書き移して慣れるような やり方を望んでるんじゃね？ でもまあ、もういいや。引きかえせないし、とりあえずこれで売ろう。 反応見て、次回で軌道修正すればいい。
． まあ売れなかったら次回もクソもないんだが。 出版社的に、どれくらい売れたら私に継続して書いてほしいと 思ってくれるんだろうなあ。 ページ数多くて私のこだわりが強い分だけ編集作業のコストもかかっただろうし、 ページが多ければ原価も高いからもうけも薄いし、倉庫代もかさむ。 前回の七光的な何かで1万くらいは売れてくれんかと思うが、 C++じゃないのがヤバい。 アマゾンで「独自言語とかねえよwwwww」とか書かれる可能性は極めて高い。 まあそれは覚悟済みだが。
． でもまあ、出版社が赤字になるようなことはよほどのことがない限りないだろうし、 そのラインを心配していては始まらん。 コストの大半はこっちの会社が払っており、気にすべきは出版社よりもうちの会社だ。 私にこんな穀潰しをさせておくことが割に合うくらいの効果がなければならない。 もうけを気にしないとしても、部数は必要だ。 前回のが万単位であることを考えれば、今回もそれくらいないと困るし、 あわよくばどっかで賞もらうくらいの名誉がないときつい。 前回の本と違って、採用に来る人が「これ読みました！」とか言ってくれる 可能性は低いからな。その分だけ別のところで評判にならんとまずい。
． ガンホーの社長かっけえなあ。 岩田さんとか宮本さんとかに関しても思うが、 ああいう人がいる所で働くってどんななんだろう。 たぶんすげえ大変なんだろうなとは思うが。 腑抜けた働きは許されまい。
． 転職は一回やると、転職し続ける覚悟をせねばならんだろうからなあ。 cedecの飲み会とか行くと元同じ会社にいた人に出会うので、 いろいろと話が聞けて面白い。
． なお、転職の話をしてる人はまだ転職しないと思う。 おとついの飲み会でも上司がいる前で「一回岩田さんの下で働いてみたいなあ」 「神谷さんとかもすごそう」みたいな話をしてたが、 むしろそういう人は辞めない。やめる人は数ヶ月沈黙の時期があって、急にやめる印象がある。 なんかあんまり働いてないなあとか、平日たまに早く帰るなあ、 とか思ってしばらく経つといなくなる、みたいな。
． ThinkPadX240sが消費電力的にかなり改善されているらしく、欲しくなってきた。 同じバッテリー容量でうちに比べて3割増しくらいの駆動時間っぽい。 ただ、キーボードとトラックポイント用のボタンが変わってるのが気になるし、 解像度が低いのは辛い。もっとも、解像度が高いのが出ても 消費電力が上がるはずなので、そのデメリットを受け入れるくらいなら 1366x768でいいという考えはありうる。 どれくらい消費電力が上がるのか次第だろう。 そして、それを確認してから買うとなると、つまりまだ買えないということになる。 にしても、保証つきで20万以上かかるわけで、 X201sで我慢してもう1年待つ方がいい気もしてくる。 2人を大学院まで行かせられるくらい金を残さないといけないからな。 3人かもしれんし。
． 最近X201sがスリープから起きる度に再起動がかかる。 やはりこのSSDが不良品だったか。 もう一回インストールするのは面倒なので、win8.1が出るまで 待ちたいのだが、再起動待ちがダルいし、 前回の故障の原因がSSDがダメなことだとしたらまた壊れることになるので、 それは困る。テトリス本が出て、赤ちゃんが出てきて、 ひつじこが動けるようになったらSSD買ってwindows入れ直そう。丁度サーバ組むし。 その時にkabiniマザーが品切れになってないといいけどなあ。
． というか、元のHDDに戻してしばらく過ごすという技もあるな... でも今の再起動の速度に慣れてしまうとHDDでwindows7というのはたぶん辛い。
． まだ産まれないようだ。ところで、医者の超音波診断が下手すぎて、 先週より体重が減ってたらしい。ママ友によれば、 2300gと言われながら産んだら3000gあったりしたらしいし、 一般的な医者の超音波スキルは低いのだろう。 へその緒が首に巻きついてたりしませんか？とか聞いてもわからないらしいし。 大鳥居病院の先生のスキルが高いのか、それとも他が低いのか。 超音波で赤ちゃんの顔見てダウン症かどうか診断するからなあの人。 そういうスキルが多くの医者に継承されていないというのはなんとも困ったことだと思うが、 個人のスキルに依存した医療を脱却するのは必ずしも悪いとは言えないので難しい。 当たりを引かなかった人のことを考えれば、 誰がやっても同じになるような技術とか手順とかを重視するのは 間違いではないからだ。もっとも、プログラマと一緒で、 たぶんテクノロジーとマニュアル化によって 平均的な医者のスキルは落ちる方向に向かうと思うけどな。
． シェルソートのコードは短い。コードは短いが、案外速い。 あと、増分をpiの累乗にすると、3h+1より乱数列で顕著に速い。 ちゃんと試してないのでいろいろ怪しいが、 後の章でまともな乱数が導入された後に再度テストしてみることにしよう。 というわけで、3章は準備にかこつけてソートの基礎を学ぶ章となった。 やっぱりアルゴリズムと言えばソートだろう。
． やっぱり一回もstd::randを使わないで行きたいな... 何かすごく簡単に思いつくすごく適当な乱数ないかなあ。
． Kabiniマザー出た。でも、今組む余裕あるか？ 無理だ。メモリ2GB、マザー、箱、HDD2個、適当なモニタ、 といった感じで合計5万ちょいといったところか。
． 私、みんなのスキルを低く見積りすぎなのかなあ。 「そんなに親切に書かんでいいだろ。サイト見るなり論文読むなり、 なんぼでも手はあるじゃん。 だって、大学出てんだよ？」と言われて考えてしまう。 まあ、そう言う人が超絶できる人で、 明らかに超絶できる人しか相手にしてない気がするので、 多少差し引いて聞くべきではあるのだが、 確かに、あまり「おまえらできねえだろ？」的な扱いをしすぎるのは 良くないというのはわかる。 でも、私自身がそもそも私の要求水準に遠く満たないわけで、 その要求水準を基準に考えれば、私を含めた大半の人は 「スキルが足りてない人」なのだ。 放っておけば自発的に勉強して勝手にできるようになる、 なんてとても信じられない。私自身、そんなことは絶対ありえない。
． 以前「STLとかBoostとかまともに使えてねえし 中身もわかってねえだろ？やめとけば良くね？」 みたいなことを言ったら、「技術を学ぼうとする姿勢を否定する気か！許さん！」 みたいな感じですげえ反発されたことがあった。 その反発してきた人がどれくらいできるのかを私は知らんので、 なんとも言いようがないのだが、 そういう考えの人が多いことは骨身に染みて知っている。
． 正直言って、私はBoostやらSTLの使い方を覚えることを勉強とは思ってないし、 それらを覚えることを指して「技術を学ぶ」と呼ぶこと自体に違和感がある。 それらを通して「こういう問題をこのような形で 解決する考え方があるのだな。なるほど」と思うことは勉強と言えるが、 それらの使い方を覚えて使えるようにする自体を勉強とは思わん。 私は「学ぶ」とは言わず「覚える」と言いたい。
． 私には「あらゆることは必要性なしに導入してはならない」 という信念がある。また、「必要性が生じた後、その必要性を満たすために どうすればいいかを自分で考えることなしに他人による解決策を導入してはならない」 という信念がある。「自分で考える」の部分にどの程度のコストを割くかは 場合によるので、5分考えてライブラリ買って終わりにするという結論に なることもあろうし、最後まで自作してしまうこともあるだろう。 それは場合によるが、しかし考える前に自作の可能性を捨てることはしない。
． ただもちろん、自作するという選択肢が選ばれる確率は下がる一方だ。 最近Unityに微妙に触れる機会があって、 ちょちょいとメニューを選んで適当にパラメータをつっこむだけで、 十分今風の絵が出せることを知った。 生半可な覚悟しかない状態でCGを自前でやるとかアホすぎる。 そんなもん趣味だ。仕事でやることじゃない。
． CGはちょっと真面目にやろうとすれば、即座に数学と物理と計算機科学の知識を 総動員することが要求される。 例えば、「球面上にランダムに点を散らしたい」 という程度の要求でも、それなりな品質で応えようと思えば 普通にゲームを作っているプログラマには手に負えない事態に陥る。 チームに入ってきた若いのに、「じゃあ君CGね。勉強しといてよ。発売は来年ね」 みたいなことを言って許される時代じゃない。 ちょっと前まではそれが当たり前だったし、私も2004年にそうやってCGの世界に 足を踏み入れたわけだが、今それをやるのは気が狂っているとしか思えない。 そりゃできる奴もいるが、それはあくまで個人としてできるだけだ。 チームとしての技術力にまで高めるには、個人の才能だけでは足りんのである。 そんな状況では、どっかのサンプルを いろいろと持ってきてフランケンシュタインのような 奇形のレンダリングパイプを組み上げ、なんとなく追いついた気分になる程度が 関の山だ。積み上げてきた奴等との差は歴然としている。 テクノロジーで勝負するということは、積み上げるということなのだ。 積み上げることの地味さを嫌うのであれば、 勝負所はアートに求めるべきで、テクノロジーの土俵には上がらない方がいい。 そのためにUnityやら何やらを使うのは至極合理的な選択だろう。
． 福島を観光地化しようとしている人達がいるそうだ。 広島や長崎、チェルノブイリが観光地的な何かになっていることを 考えればアリだろう。 来る人だって内心はともかく、一応建前としては学びのために来るだろうし。
． 悲惨なところを見に行く人がどれくらい真面目に受け止めるかはわからないし、 正直そこはどうでもいいんだろうと思っている。 道路の真ん中に家の2階だけが鎮座しているのを見て内心「オモシレー」 とか思っても、それを外に出さず深刻な顔をしてブログやらに 旅行記を書いてくれれば、それでいいわけだから。 もちろん、そう大っぴらに言うわけにも行かない。傷つく人がいる。 しかし、傷つく人は大抵経済的にも困っているわけで、 心のケアだけで済ませるわけにも行かない。
． 一時はげしく値上がりした株その他がかなり落ちついてきた。 こうなると売っておけば良かったと思ってしまうわけだが、 それを考え出すとキリがない。
． グローバル人材、みたいなのを目指すべきなんだろうなあと思いつつ、 なんか無理そうな気もしている。 日本人とすら社交できないのに、どうやって外国人と社交するんだよ。 社交しないグローバル人材なら目指してもいいかと思わなくもないが、 それはできるだけ英語を読んで英語で発信することが前提になる。 しかし、英語な人との会話がほとんどないまま日常の英語比率を増やすなんて無理だ。 意識を変えるには努力がいるが、努力は持続可能ではなく信用できない。 やるとしたら環境を変える方だろう。海外赴任するとか、 しょっちゅう英語な人と話さないと仕事にならない場所に行くとか。 もちろん、そうしたいかと言われれば、全くしたくない。 ただ、そうすべきかと言われれば、たぶんすべきなのだろう。
． 借金の金利は自分で運用する金利よりも高い、というのは絶対とは言えないわけか。 借金の金利以上に運用で稼げるなら、借りた方がいいわけだ。 もちろん少額な借金でそんなに金利が安いことはなく、 ありうるのは住宅ローンくらいである。それでも2%を超えてくれば 運用でそれを超えるのは難しい。 資源制約がかかって世界全体が減速する可能性も高いわけで、 年率3%での経済成長がいつまで続くかもわからん。
． cedec飲み会だけ参加。おもすれー。
． 開発の効率は良い方がいいか？100人中99人は「はい」と答えるだろうし、 残りの1人は頭のおかしい人だろう。 では、開発の効率は改善した方がいいか？ これも100人中95人は「はい」と答えるだろうが、 残りの5人には95人に見えていない何かが見えている可能性がある。 効率の悪さゆえに収益が悪化しているのであれば議論の余地はなかろうが、 それなりに安定して利益が出ていて、組織が維持できているケースでは 慎重にならざるを得ない。 開発効率が上がる、というのは、開発における何らかの行動のコストが 安くなることを意味する。経済学的に言って、 何かのコストが変化すれば、行動は必ず変化する。 その行動の変化が、利益を落とす方向に向かわないという保証はどこにもない。 下手にいじった結果どのような副作用が出るかはわからないのだ。 プログラムの話で言えば、ビルド時間を短くすることで品質が悪化するような 状況は容易に想像できる。試行錯誤の回数が多いほど品質が良い、 というのはおおよそは言えるとしても、常に言えるとは限らない。 とりわけ、非効率なやり方で長くやっていれば、 その非効率なやり方の中で効率を上げるように行動が最適化されているはずで、 その最適化が進んでいれば進んでいるほど、変化に対して脆弱になる。 効率を改善した方が良いと確実に言えるのは、 日頃から効率を改善することが当然になっている時くらいだろう。 その場合作業工程の修正が頻繁に行われているので、 変化に対する抵抗も少ないし、変化がもたらす副作用への対処にも慣れている。
． でもまあ、何事も程度の問題だ。あまりに非効率が甚しく、 その非効率に対して取りたてて愛着があるというわけでもないのであれば、 除いてもかまうまい。もちろん、それが望ましくない副作用をもたらす可能性はあるが、 それを恐れて手をつけないのも競合に対して不利になる危険を冒すことになる。
． 効率なんて大した問題じゃない、というのもその通りなんだけどな。 売れるものはコストの10倍とか20倍とかいうもうけをもたらすわけで、 10%20%のコストは問題ではない。 そういうレベルで不確実性の高い商売をする場合、 最も創造性が発揮される開発環境でありさえすれば、 効率はさしたる問題ではないわけだ。 効率が競争する上で重要になるのは、成熟して安定した産業においてだ。 娯楽産業において、しかも製造原価がゼロ同然であるソフトウェアにおいては そういう状況は起こりにくい。 だからコストをとやかく言わないのも合理的ではあるのである。
． 外人は日本人ならではの頭のおかしい作品を求めているらしい。 頭のおかしい作品が乱立するためには、 規模の優位性がなくなるまで市場を拡散させる必要がある。 規模が大きい限り、頭のおかしい作品は作りにくい。 絶対に無理とは言わないが、確率は下がる。 でも、もっと重要なのは、頭のおかしい労働環境だろうな。 昔のゲーム業界の話とか聞くと、本当に頭おかしい。 アニメの人の昔話もやっぱり同じように頭おかしい。 高度成長期の日本企業の昔話とかも、相当頭おかしい。 戦略とかマネジメントとか管理とか、 そういう事を言ってる段階でダメなんじゃないかと最近強く思う。 そしてもしそれが本当なら、私みたいな人間は向いてない。
． シェルソート。2倍づつだとすごく遅い。それでも2乗系のアルゴリズムとは 天地の開きがあるが。3倍だともっと遅い。 3倍して+1すると確かに速い。2倍して+1でも速いが、3倍には及ばない。 このへんは理屈を求めるのは難しい。 例によって素数でやるのが良かったりするんだろうが、 理屈がないので試行錯誤の過程を示さないと納得させられない。
． 書き忘れた。イノベーションのDNAの中に、 イノベーションを重視する企業は、そういう人材を取ることに熱心だとあった。 変な奴を採用する工夫をしている、という。 それ効果あんのかなあと思う一方、 たぶん効果が云々とかいう話でなく、 「うちの会社は変なんだ」という意思を内外に示すために それが必要なんだろうという気はする。
． 私は採用で変な奴を集めるのは無理だと思うけどな。 勢いがあって伸びてる所なら人がたくさん来て選ぶ余地もあるだろうが、 落ちついたり衰退したりしてる会社にはそんなに人は来ないし、 選ぶ余地もない。 勢いがあるから、結果変な奴もたくさん来て、変な奴を選べる、 というだけで、変な奴を取る工夫をした結果勢いがある、 ということではないだろう。 だいたい変な奴を取る採用をしようとすれば、 採用されたい奴は変な奴を装うようになる。 インド行ってると通りやすいとか、そういう話になったらダメだろ。 まして、選ぶ側が考える「変な奴」の概念がちゃんと変か、 という問題もある。極端な話、 選ぶ側が変な奴なら普通の奴を変と思うかもしれないのだ。 採用で選抜を凝るより、その会社が求める人間に作り上げていく 文化やら制度やらを強固にする方が大切だ、というドラッカーの意見の 方が私にはまっとうに思えるな。
． つうか、ちゃんと商売して客に愛される企業になればもうかるし、 もうかれば人が来るし、人が来れば変なのを選ぶ余地もでてくるのだ。
． あともう一つ。アマゾンの書評を見ると、 書評を書いてる人のフツーっぷりが物悲しい。 普通になるなと書かれた本を読んで、 すごく普通に分析して普通の感想を書いてる。 全然この本に書かれてることを実行していない。 まあそれを言うのも酷な話だろうが。
． イノベーションに関してもドラッカーで足りる雰囲気。 イノベーションのジレンマとかはそりゃ名著だと思うが、 役に立つ度合いで言えばドラッカーの方が上な気がする。 結局占いみたいなもんで、あれを読んで何を思い浮かべるかは 個人次第だ。そういう方が実践には使いやすい。 学者が書くデータの裏付けがある論説は、 そういう想像力を刺激する成分が少ない。 「いろんな人と話すといいよ」みたいな「そりゃそうだ」 と思うことを言われても、具体的すぎてかえってどうにもならんのである。 でもまあ、受け取る側があまり深く考えられないなら 結論がズバリ書いてある方が楽かもしれんな。 そんな人が成果を上げられるとも思えんわけだが。
． リストラこええ。 いつこうなるかわからんのだから、普段から覚悟と準備をしておかねば。 そして、覚悟と準備ができていれば、たぶんこういう目には遭わない。 しかしそれはそれとして、 でも周りでこれが行われてるような会社にいたくはないよなあ。
． アーティストもデザイナーも日本語としてなじまないのであれば、 「美術」とか言えばいいと思う。 それにしてもプログラムやソフトウェアの訳語が存在しないのは どうにかならんのか。 算譜とか、そんな感じに無理にでも作っておいてくれれば良かったのに。 1970年くらいはまだ訳語を作る文化が残ってたと思うんだがなあ。
． 今週の校正終了。malloc本を書こう。だいたい収束してくれるといいなあ。
． malloc本がなんとなく行き詰まり感。 無理矢理書き進めようと思えばやれるのだが、 基礎が揺らいでいて不安な感じ。 これは一旦最初から書き直していくべきかな。 テストフレームワークとかも問題が山ほどある。 扱うべき話題で飛ばしたことも結構あるしな。
． facebookがよくわからない。 なんかすごそうな人から友達リクエスト来たぞ... メッセージもなくただリクエストだけが飛んでくるので 温度みたいなものがわからない。
． 宝くじが当たった人間だけで集まって話をすれば、 「何をやっても当たる」という話になる。 当たらなかった人まで含めて統計を取った時に初めて、 どうすると当たる率が高いのかについて議論ができる。
． 商売は、自分にできることと、他人が欲しがるものの間をどうつなぐかだ。 欲しがる物が見えても、作る能力がなければそれまでだし、 作れて作りたいものを作っても、求められなければそれまでだ。 そのへんを考えていろいろとやるのがマーケティングであり、 その具体的な策の一つがプロモーション、つまり広告だ。 マーケティングを考えない製品作りはどう考えてもありえんし、 広告はその中で当然考えるべき要素だろう。 結果的に広告らしい広告を一切やらないこともあるが、 それはそれで広告戦略である。ソフトをタダでバラまく場合、 販売と広告は連続的で、境界がどこにあるかは明らかではない。 今の人はtwitterやらブログやらで勝手に広めてくれたりもするので、 広告を売り手が自分でやらないという選択肢は存在する。 むしろ、そこを積極的に利用した方が小規模な製品の場合には効果が上がる。
． 本を書く仕事は、そのへんの実践に丁度いいな。 しかも金銭的リスクを負わずに勉強できる。 給料もらって本書くって最高！ 前の本の印税をもらってたら車くらい買えたんじゃないの？ とか言われることがあって、確かに額だけ見ればそうなのだが、 そんな選択はありえない。 会社を辞めずに印税をもらう方法はなかったし、 出るまではどの程度売れるかは全くわからなかったのだ。 テトリス本に関しても、もうけは全くの未知数である。
． まあ、アマゾンで適当に「プログラミング」とか検索して出てくる本を見るにつけ、 「こんなのでできるようになるわけねえよ。 オレがこんな本ばかりの状況を粉砕してやる」 とか思うわけだし、そう思わない人間が本など書くはずもないのだが、 当然のこと私に見えていないことはたくさんある。 私がクソだと思うような本が売れるのには理由があるのであって、 その理由には買う側の現実が反映されている。 私が買う側の現実をきちんと見て、そのニーズに応えているかは 結局やってみるまでわからない。
． 憂鬱な〜で始まるオブジェクト指向プログラミングの本を読もうとして、 10ページと読まずに本を閉じた。 これは今の私にとって必要な本じゃない。だって、全然ピンと来ないもん。 「なんでオブジェクト指向なの？何の問題を解決するの？ それって日常概念の何と対応するの？」 という私にとって一番根本的な疑問に最初の10ページで答えてくれてない。 答えるそぶりもない。 「オブジェクト指向とは何か」という問いは、 オブジェクト指向が読者にとって重要である理由を納得した後で ないと意味を持たないんじゃないの？ みんなそこは納得してるわけ？
． 私にはオブジェクト指向は理解できん。 たぶん関数型プログラミングの方がまだ理解しやすかろう。 ただ、私が「これがオブジェクト指向だ」と理解していることをオブジェクト指向と 呼んでいいのであれば、私にとっては自明なものだ。説明を聞く気にもなれない。 「擬人化」であり、「プログラミングへの主語の導入」だ。 知る限り全ての技法は、その概念から自然に出てくる。 必要性も適用範囲も明らかで、例えばポリモルフィズムが日常概念の何を プログラミングに持ちこんだもので、どのような必要性があって、 いつ使うべきものかははっきりしている。 私はその意味ではオブジェクト指向とは何かを他人から学ぼうとは思えない。 私は自分が知っていると思っているからだ。 しかし、私が自分の中で持っている説明と同じものを見たことがないし、 誰かと話すと全然話がかみあわない。 だから私は自分がオブジェクト指向を知らないことにしている。 以前社内でオブジェクト指向について有志で語ろう、みたいな会に出て これ以上ないくらい後悔したのだ。「こいつら、一体何の話をしているんだ？」 という具合である。
． でもまあ、こんだけアマゾンで絶賛されてんだから読んでおいた方がいいんだろうな。 今回のが売れてオブジェクト指向導入編でも書くことになったら読もう。 逆に、そうならなければ読まなくていいや。 だって日常足りてる。私の感覚から言って、 オブジェクト指向がわからない奴なんているわけがない。 そんなことはひつじこだって当然のように知っている。 それがわからない人とは会話がまともに成立しないはずだ。 まともに会話できる人で、かつプログラミングの基礎ができている人間であれば、 オブジェクト指向プログラミングが理解できないということは およそありえないように思われる。 みんなが日常生活の中で自然にわかってることをプログラミングに 持ちこむ方法を教えてあげればいいだけで、 わけのわからん用語や言語機能をどっかり持ちこむのは後でいいはずだ。 先にそれをやるからわけがわからなくなってるだけじゃないのか？ これ完全に説明の仕方が間違ってるだけだろ？違うの？
． まあ違うんだろうなあ。私がわかってないんだろう。 そういうことにしておかないと人と話す時に面倒なので、内心はともかく やっぱりわかってないことにしておく。
． 全然わからねえ。うん。やっぱり私はわかってないんだよ。 書いてある内容がわからないとは言わないが、 この文書の意図がわからない。話題の選択の意図がわからない。 話の展開の意図がわからない。それだけわからないんだから、 やっぱりわからないとしか言いようがない。
． で「イノベーションのDNA」が面白くて仕方ないわけだ。 プログラミングの勉強なんてしてる場合じゃない。 そして、読めば読むほど、自分がイノベーション向きの人材であるような 気がしてきていい気分になってくる。危ねえ。 ただ、「空気読まない」つまり 「歴史的経緯を無視して今から始めるならどうするかを考える」 点に関しては自信がある。 そして、そういう性質のない人間がイノベーションに向かないことははっきりしていて、 そういう人が周りにはいくらでもいる。 つまり、私にイノベーションを産み出す力があるかどうかはわからないにしても、 私が相対的にイノベーション向きの人材であると言うことはできる気はする。 私はイノベーションによって仕事をする方が組織や社会に貢献できるはずだ。 というか、すでにあるものの保守や改良には決定的に向いていないわけで、 それで給料をもらうのは絶望的に難しい。 となればそれ以外に給料をもらう道を探さないと生きていけない。
． この本に書いてあるイノベーション力を上げるために必要なことで 私が特にダメなのは、人と話すことや、新しい環境に身を置くことだ。 cedecでもgdcでも、バリバリ人と話せればもっといいのはわかっている。 海外旅行でもなんでもして、普段と違う環境に身を置く方が アイディアが出るというのも、そうだろう。 たぶんここは克服すべき課題なのだろうし、 そんなことはずっと前からわかっていたのだが、 この10年改善はほとんど見られなかった。 英会話まで行ったが、そもそも日本人しかいない宴会で日本人に話しかけられてない 段階で、英語ができても意味がないのである。 客観的に言えば、私がこれらを克服する見込みは薄い。 別のところに注力した方がいいんだろう。
． 例えば、私は人と話したり旅行をしたりする代わりに、 拳法をやったり音楽をやったり本を読んだり結婚したり子育てをしたりしている。 拳法はまあいろいろあってやめたが、体の動かし方は今でも研究している。 音楽もまあいろいろあってやめたが、言葉を使わないで脳を動かす習慣は すでに身についていると言えるだろう。 脳から言葉を追放した状態で何時間か過ごしてみると、いろいろな発見があるものだ。 本もプログラミングの本はどうにも読めんが、 経済、政治、軍事、医療、料理、などの本は面白くて仕方がない。 それらがプログラミングに役立った経験はいくらでもある。 所詮人間がやることなのであって、 人間が対処する問題のバリエーションは知れているし、 人間がどう脳を動かすか、どう人と協力するか、などのパターンも知れている。 プログラミングとそれ以外に大差はない。応用できないはずがない。 ここ数年では結婚と子育てがすごい。 自分の都合に関係なく勝手に生きている生き物が二人も家にいるのである。 人間について学ぶのにこれほど良い環境があるだろうか。 というわけで、それで良しとしてもいい気はしてくる。 人が100人いる宴会で自分から人に話しかけて回るとか、 facebookでやりとりするとか、正直面倒くさい。 だからこの日記にもコメント機能をつけていないのだ。
． 人と話すのは好きなんだけどな。静かな所でゆっくりと少数の人と話せるなら、だが。 しかしそれは、相手にそれだけの時間を割いてもらうということであり、 私との会話が相手にとってそれだけの価値を持たねばならない。 自信ねえ。
． で今日は二郎食べた。品川。そして血糖値測定。
． 血糖値が130もあるのに空腹感がある。調べたところ、 動脈と静脈の血糖値の差が小さくなると空腹感を催すらしい。 普段の80程度の時には、巡ってくる間に赤血球がそこそこ消費するので 差がそれなりにあって空腹感を感じないが、 130とかになってきて、しかも安静にしていると、 赤血球ごときでは消費しきれないため、巡ってきた静脈血も血糖値が高い状態になる、 ということだろうか。
． 普段あまりインスリンが出ていないので出が遅れているのかもしれない。 また、脂肪まみれでグルテンの強い二郎なので消化が遅く、 いつまでも糖の放出が続いているということもあるだろう。 食後190分で110まで落ちたが、そのあたりの時間は買い物に行ったりして 動いていたため、筋肉による糖の消費がそこそこあった。 しかしその後は全く動いていない。そのために、 じわじわと血糖値が上がってきて、350分後では134まで上がっている。 まだ胃には二郎が居座っているはずで、今もブドウ糖を出し続けているわけだ。 これ、もし二郎食べた後一切歩かずにいたとしたら血糖値が どこまで上がっていたかわかったものではないな。 ブドウ糖の試験をやったら余裕で200を超えていただろう。 一発で糖尿病判定が出る。
． 糖質制限をしていると澱粉に弱くなる、というのはおおよそ間違いなさそうだ。 ただし、二郎のように消化が遅く脂でギトギトの場合は 一気に血糖値が上がる効果はさほどでもなく、 また遠方にあり嫌でも歩いて帰ることになるので多少は害が薄まる。 むしろ近場でソバでも食べて、直後から座って仕事、 みたいな方がヤバいんじゃないだろうか。 ただ、二郎は絶対量が多いので、血糖値×時間の積算ダメージでは 量が少ないソバを凌ぐだろう。 血管を痛めつける度合いと血糖値の関係ってどうなんだろうな。
． 江部サイトによれば、200以上はヤバいらしい。 今日は180くらいで止まっていたので一応セーフか。 インスリンの大量分泌で膵臓を疲れさせる効果の方が大きそうである。
． イノベーションが得意な会社は、社長その他が自分でイノベーションに参加している ケースが多いらしい。ジョブズみたいなのがいる、ってことだな。 そういう社長は、そういう部下を好むから、会社の上の方が イノベーション大好きな雰囲気になる。そういう人が出世するとなれば、 下っ端もイノベーションを重視する気になる。 しかし、上の方が確実に物事を実行するタイプの人で占められてしまえば、 下の方にしても思いつきで勝負しようという気は失せる。 ちゃんとトップ付近に変な人が混ざっているか？ というのは企業がまともかどうかを見るのにわかりやすい基準になるんだろうな。
． 研究開発部門の技術開発チームにいるわけだが、 それは会社の中で最もリスクを恐れてはいけない場所だ。 であれば、会社の中でも一番成功率が低い仕事をやらねばならない。 できるかどうかわからないことを率先してやろう。 まあ、と言っても本を書くわけだが。技術そのものでリスクを冒す気はないが、 技術の伝え方ではリスクを冒そう。 製品に入れられる品質のコードそのものも売るが、 説明という付加価値をつけて売る。その付加価値が全てだ。 mallocにしろCGにしろ、新しい技術を開発する気はさらさらない。 問題はそこじゃない。
． というわけで、明日からがんばる。 今日は午前中で校正のレスを渡したが、 頭を切り換えてmalloc本を書けるわけでもなく、 なんかダラダラしてしまった。二郎とか行ってるし。
． いいかげんNISAが何なのか調べておかんといかん。 といっても表面上のことはわかっている。 年間100万づつ、売っても非課税な口座ができるんだろ？ しかしこれ長期投資に使えるのか？ 売らずに放置しておけない気がするのだが。 5年後に売らないといけないとしたら、その段階でかなり使えない。
． 2014年から2018年まで100万づつ買うとする。500万溜まる。 2019年の枠には2014年に買った100万を入れないと売る破目になるので、 つまり2019年以降はこの口座では買えない。そして、2023年末には 2014年に買った100万は売らねばならなくなる。 ただし、非課税なので売って目減りするのは売る時の手数料分だけだ。 また、毎年配当があれば、それも非課税になる。 もうかっている場合、税金分はおおよそ得する。損している場合、 売って同じものを買い直すと手数料分損する。 たぶん高確率でプラスだろう。 手間もさほどではないし、まあ試してみよう。 試してみないと人に伝えようがないしな。
． 損した場合が実はヤバいな。半分になった状態で5年経って、 そこで売らず普通の口座に移し、後で元に戻った所で売った場合、 半分になった時点からで利益を計算されるので税金がかかる。 NISA口座が終わる段階で一旦売るべきだろう。 半分になっても、売って買い直せばそのデメリットはない。 ただし手数料分はかさむ。 あとは損失が出た時に他の口座のプラスと相殺して税金を削れない。 売らない前提でいた方がいい。
． 5年経って目減りしていた場合はその分買えるのか。逆に増えると 増えた分は売らねばならないと。 この制度をやることでいろんなコストがかかってると思うんだが、 それに見合うだけの効果があるのか？ 銀行につっこんで死蔵されているお金を他に回してほしい ということらしいが、それは一体誰のメリットになるんだろう。 海外の株に投資してほしい、ということかな。 そうすれば海外から金が日本に入ってくることになる。
． ひつじこ実家。お盆だしな。 私の実家は遠すぎるのでパス。冬な。 オタマはいとことちゃんと遊べていたようで、 知らんうちに成長していたことを実感した。 毎日見てると、かえってどれくらい育ったのかよくわからない。
． 池上彰の本を2冊ほど読んだ。おもしろくて読みやすいのだが、 それ以上にこの人の人柄が気になって仕方ない。 いろんなことが面白くて仕方ないんじゃないかなあこの人。 もしかして、あいつとか、あいつとかと似たような タイプなんじゃなかろうか。 問題自体が本人にとってどうでもいいからこそ、 これだけ本質を捉えた説明ができるんじゃないかという気がしてならない。 反原発の連中はまず間違いなく原発を冷静に見られないし、 産業上の都合で原発賛成な人も同じように冷静には見られないだろう。 原発を冷静に見られるのは、原発がどうなろうがどうでもいいと思っている人だけ ではないのか。問題の構造や利害関係者が作り出すカオスが面白いのであって、 原発がどうなるかなんてどうでもいいのではないだろうか。
． もし私がプログラミングの技術をわかりやすく教えられるとしたら、 プログラミングに愛着がないことは強みだろうな。 結果として物ができりゃそれでいいし、 それを手段として深い知恵を身につけられればなおいい。 プログラミングにしか役立たないプログラミングの勉強なんてクソだと思っている。 それだけに、プログラミングに愛着がある人からは叩かれるわけだが。 きっと、malloc本やCG本を出したらまた叩かれるんだろう。 私はmallocのアルゴリズムに正直興味はない。CGも同様だ。 作りたいものを作るのに十分であればそれでいい。 もちろんやり始めてみれば面白くなるのだが、それはパズルゲームを解くのが 面白いのと同じであり、誰か他人が考えた技術を知ること自体はうれしくない。 私が興味があるのは、役に立つ技術はどのような構造を持っていて、 どのような枠組みで勉強したり運用すればいいのか、 という一段メタな問題であって、 mallocであれCGであれ、そのものは比較的どうでもいい。 だから、この先本を何冊か出せるのだとすれば、 そのジャンルはバラバラだろう。私は何かの専門家であろうとは微塵も思っていないし、 その能力はそもそもない。CG本の次にありそうなのはコリジョンかな。 あとはテトリス本が売れるならObjectiveSunabaでのオブジェクト指向プログラミング。
． テトリス本はどれくらい叩かれるんだろうな。ワクワクする。 もちろん叩かれればへこむんだが、それはそれだ。 順調に行けば9/4に印刷所に提出らしい。
． グラフィクスやってねえなあ...まあ今書いてる本が片づいたら CGの本を書くつもりでいるわけだが、 もちろんのこと現時点での私は本を書いていいレベルではない。 例によって、書いてるうちに本を書いてもいいと思えるレベルまで 上がるだろ、という杜撰な計画である。 つうか、私より下の人間が私の所まで来られりゃそれで十分価値がある。 だから間違っていることも、私のレベルが低いことも気にする必要はない。 CG技術を牛丼のように早くて安いものにできればそれでいい。
． 「11回」が「1一回」に直されてる... 「61行」が、「6一行」に直されてたりもするしなあ... どちらも「1回」を「一回」に、「1行」を「一行」に直す時に誤爆したせいだろう。 同様に、「直後」が「直あと」になってる場所を2箇所見た。 「後は、」を「あとは、」に直す時の誤爆だ。 ファイル名の中にある「2つ」が「二つ」に変わってる所もあった。 うーん。デジタル時代の校正作業ってのはそういうもんなんだろうが、 もし私が見つけなかったらこのまま出てしまうと考えると、 作業フローを改善する必要がある気がするなあ。 いや、作業フローの問題というよりは、コミュニケーションの問題か。
． でもまあ、malloc本ではこっちで出荷基準みたいなものを作って、 一定のテストを通してから提出するようにしよう。 統計レポートを出すプログラムを作って、それを通して疑わしいところを 直してから提出する。
． もう夜中の1時だが、第二校正チェック開始。
． 3時半。3章までしか終わってない。結構莫大だ。 逐一渡していくしかないなあ。 続きは明日の夜から。 順調に行けば9/4入稿らしいが、 出産で校正がどうなるかわからんし、 社内チェックにどれくらいかかるかもわからんわけで、 9月中の発売はなかなかに危うい。
． オタマが夜中起きてしまった。今は帰れん。もう一章やる。 1時間くらいで終わるかなあ。 2時間経つと6時で睡眠時間がヤバい。
． 4時半。4章まで終わった。
． 場所によって「1つ」だったり「一つ」だったりするのってそんなにダメかなあ。 使い分けているのだが、ひとりよがりなんだろうか。 いやでも「描画位置を右に1つ動かす」と、「一つには」は別物だと思うんだけどなあ。 前者は3つだったり6つだったりするわけで、1に特別性はないが、 「一つには」は「三つには」とかにはならないからな。単なる接続詞だ。 そういう場合にはひらがなにすべき、という意見もあるとは思うのだが、 場所を食うし、ひらがなが続いて読みにくくなるケースも結構ある。 私は自分が読む分には「蓋し(けだし)」みたいに接続詞に漢字使われてもかまわないと 思うので、書く時にも若干そっち寄りになってしまうんだろう。
． そもそも文体を開発せんといかんなあ、これは。 20文字以上点が打たれずに文章を書くと、ほぼ確実に点が追加される。 要するに、私の文章は従属節が長いのだ。 階層が深いと言ってもいい。 一つの文を一つの木とし根ノードを用意すると、 原則としては、2段目の要素の間に点が打たれる。 2段目の要素はさらに分解されて3段目があるが、 3段目の要素間には点は打てない。 打てば2段目の要素の境界と区別しにくくなる。 文脈から明らかになるケースでは点を打ってもいいとは言えるが、 理想的には内容を一切見なくても正しく木を構成できるように 点を打つことが望ましい。 そういうわけで、3段目の要素がすでに長い場合、 ここに点を打てないのである。
． 「何々が何々したのと何々が何々したのでは、前者の方がいい」。 点によって要素が分離されている。 しかし一つ目の要素が長すぎるので、 「何々が何々したのと、何々が何々したのでは、前者の方がいい」。 と点を増やしたくなる。 しかし、点を増やすと構造が変わる。 元は点の前までが丸々副詞句だ。しかし途中で切ると、 中身を見ないと構造が見えなくなる。 点が二つあるが、この二つの点は分割のレベルが異なるのだ。 私はできれば一つの文の中にレベルが異なる点が含まれる文は書きたくない。 もちろん、それを完全にやるのは無理なので、ほどほどというか適当になるわけだが、 ここが適当すぎると文意がわかりにくくなる。 って、この前の文の点3つも前2つと最後のはレベルが違うわけだがな。
． 私がもし2008年に本を書いていなければ、 前二つの点は打たれなかっただろう。前回容赦なく点を打たれまくったおかげで、 個人的には打ちたくない点を打つクセがついたのである。 人に読ませるならその方がいいんだろうが、 その結果文の構造が狂って丸ごと再構成する破目になったところが大量にある。 接続詞なしで短文を連続させることが増えたが、 それは完全にこの問題への対処だ。 長い文を書けないとなれば、割るしかない。 前の例で言えば、「何々が何々した。何々が何々した。前者の方がいい」 となる。実際には接続詞が入ったり、クッションになる節が挟まったりはするが。
． もっと徹底的に文を短くする実験をしてみるかなあ。 いわゆるビジネス日本語を書けばいいんだろうが、 それをやることが良い結果につながるのかよくわからん。
． 「以前想像した通りに、四角を描く所を部分プログラムにするならば、そ れを使ったプログラムは、こんな感じになるだろう。」 元々は重文境界に点が一つだけあったが、点が二つ追加されている。 「想像した通りに、こんな感じになるだろう」とつなげられるので 構造が曖昧になる。そんなふうに読む奴はいないからこれでもいい、 というのはわかるが、私の好みではない。だからこう直した。 「以前想像したように、四角を描く所を部分プログラムにしてみる。 こんな感じになるだろう。」 まあ元の文章がブログレベルに適当なので、多少削り落とした方がいいのは間違いない。 点が打たれるような文は大抵冗長なので、削り落とし、それでも長ければ分割する 方針でやっている。
． malloc本は真面目に文章を直してから提出した方がいいな。 校正が始まる前に自分でやれるだけのことはやっておかないと迷惑をかける。
． 「60000に、マス目単位で見た時の縦の番号に、500を掛けたものを足し、 マス目単位で見た時の横の番号に、5を掛けたものを足して作ったものだ」 ヤバいな。複文に点を足した結果構造がおかしくなっている。 「に、」で終わる節が2連続しているのはマズい。 「マス目単位で見た時の縦の番号に500を掛けたものを足し」を 短縮して点がなくてもいいようにするしかない。 「60000に、マス目単位の縦番号×500を足し、 マス目単位の横番号×5を足して作ったものだ。」かな。 「×」に3文字入れるのがちょっと姑息だな。正直好かんが、やむを得ん。 コードとの対応があるので節の順序は入れ換えられないし。
． 5章に3時間以上かかってる。考えすぎた。再開最初の章は大抵遅い。 今日中に10章までは行かないと明日がマズい。 松戸行くという選択肢を残さねば。
． 「その方がいいと私は思う」って、主語ないよな。「私は」は修飾語の意味合いが強い。 もっとも、主語なんて修飾語だと言ってしまうこともできるとは思うので、 その立場を取るならば「主語っぽさの差」でしかない。
． 脚注が多すぎた気がするな...脚注なんて少ないほどいいのはわかり切っているのだ。 ただ、玄人にツッコミを受けて叩かれることに予防線を張った結果であったり、 引っかかる率が低そうな項目を本文から飛ばした結果であったりする。 日本語の文章としての質は落ちるが、なかったらなかったで技術書として ヤバい。まあ単なるギャグもあるけどな。
． 2538。7章まで終えた。できれば10章まで片づけたいが、なんか疲れてきた。 コーヒー1リットルを買って臨んでいるが、逆効果だったかもしれん。 確かに眠くはないが、疲れないわけではない。それどころか、なんか頭痛いぞ。 飲みすぎたのか。
． Cの絵本という本がある。こういう本を駆逐するような本を書けないかなあ。 こういう本にすがる人のニーズをちゃんと満たしつつ、 そういう人が本当に求めているものをちゃんと提供できる本は書けないか。 この本、やわらかいフリしてるけど、フリだけじゃん。 改行コードとかどうでもいいだろ。もっとページを使う事は別にあると 思うのだが。
． でも、文章が少ないことは見習うべきだ。 私の本は基本的に、文章が少ないためにわからない人に対して、 文章を増やすことで対処している。今回の本も700kBもある。 ラノベ3冊分だ。 しかし、このアプローチは、文章が多いことを怖がる人を排除してしまうため、 取りこぼしが大きい。今回の本はそういう人には売れないのだ。覚悟済みではあるが、 いつかその取りこぼしを回収する手を考えないといけない。
． もちろん、文章が多いのが嫌われるのは、 文章の質が悪かったからというのもあるし、図にすべきことを図にしてこなかった せいでもある。しかし、実際問題わからんで困っている人にとってみれば、 文章の質が悪いとか、図が足りないとかいうことはわからない。 ただ「なんか文章ズラズラしてたけど全然わからんかった」 という印象だけが残る。そういうトラウマを持つ人に対しては、 仮に質の高い文章を提示しても拒否される可能性が高い。 だから文章を少なくするアプローチは効果的だろう。 トラウマをほぐすための本が必要だ。 問題はそれで何をわからせるかであり、 そして、どう次につなげるかである。
． C++ってやっぱりプロ言語なんだよ。 他の言語で一定の経験を積んでからでないと非効率すぎる。 そう思ってSunabaとか作ってるわけだが、これは普及はしない。 努力はするが、無理だ。 真面目に取り組んでくれる人が数千人か出れば御の字だし、 加えて面白がってくれる玄人が何人か出たり、 研修や試験に使ってくれる企業が現れたりすれば十分すぎる。 世界を変えるには、理想的ではなくとも、 すでにあって普及している言語でプログラミングを教えねばならん。 そこも考えないといけないよなあ。まあjavascriptになるわけだが。 C#でもいいのかもしれんが、言語仕様がデカいのがネックになる。 ライブラリ込みだからなアレは。
． 8.3あたりの日本語が危険。今日の頭には荷が重いので、 単純チェックだけして明日以降に回す。
． 2646。8章終わり。9章まででいいかなあ。今日かなりキツい。 まあでも5章でこだわりすぎたせいだから、明日さっさと始められれば大丈夫か。 それに今日は暑いなかだいぶ歩いたりもしたしな。 あーでも9章までのページ数が305ページ。全ページ数が523ページ。 6割か...ヤバいなあ。三日で片づけるにはやはり10章まで片づけねばならん。
． 2756。9章終わり。行けなくもないが、10章は長いので、確実に夜が明ける。 明日も長いはずだ。ここは撤退しよう。 一旦zipに固めて全部上げておく。明日ひつじこが産まないとも限らないからな。 そうなれば作業は家でやらねばならないわけで、 データの同期は毎日取っておかねばならん。
． 2-3木のアルゴリズムが素敵なのだが、2つキーを持ち3つポインタを持つ構造体が 必要なのがネックになる。キーすなわちデータであり、 データはintのように軽量とは限らない。キー型とノード型が別だと、 メモリ確保が面倒くさくなる。
． 2-3木を2分木で表現することを考える。隣合った二つの節をまとめて 2-3木の一つの節であるとして扱えるとしよう。 う。だめだ。左右非対称になって扱いが面倒くさい。 だから2-3-4木なのか。やっぱり自分でやってみないと納得できんな。
． いや、2-3木でも行けるだろ。調べたらLeftLeaningRedBlackTreeというのがある。 これだ。問題はこれが赤黒木に対する改良として出てきていることだ。 そりゃそうなのだが、もしこれを説明するなら、 普通の赤黒木を経由せずに説明する必要がある。 せっかく簡単なコードで書けるのだから、より難しいものを経由するのは効率が悪い。
． 二分ヒープって、親ポインタがなくてもやれるはずなんだよな。 逆方向に辿っていく処理が一切なければ親ポインタはいらない。 経路の保存が必要であれば再帰で書けば良い。 でも、削除で一旦検索を走らせる必要が出るので、 削除を頻繁にやる用途では遅くなる。
． オタマはほとんど毎日「ダイスふる」で遊ぶ。 同じ高校だった時村が作ったアプリだ。 もちろんサイコロなんて理解していないので、 4面体を2つ並べてちょうちょにしたり、一列に並べたりして 何やら楽しんでいる。 ちょっとした操作ミスで2回課金したが、170円。 もうちょっと払う手段があってもいいよなこれ。
． あとは再開時にサイコロがたくさん出てると初期化処理に えらいかかって遅いのをどうにかしてくれ。 Unityのせいらしいのでどうにもならんのかもしれんが。
． ThinkpadX240sを買えるようになった。 しかし、拡張保証までつけると18万とかになるし、そもそも1366x768はないだろう。
． iPadで文章を書くのが苦痛らしいので、ひつじこにノートPCを 用意したいと思ったが、iPadにキーボードをつければ済むことに気がついた。 そういう製品が売られている。iPadをセットする台つき。それだ。
． 戦争負けた日。今のところ、 日本がああいう戦争をやらかしたのは、 みながそれを望んだからだと私は思っている。 新聞は煽っていたし、皆はそれを喜んでいた。 朝鮮や満洲で商売をしていた人は、日本の影響力が そこに及び続けることを望んだだろう。 政治や軍はその空気を読んでいただけのことなのではなかろうか。 当時戦争は犯罪ではなく、悪いことですらなかったし、 だいたい序盤は勝ちまくっていたわけで、 お祭騒ぎ状態だったのではないのか。 軍やら政治家が本当のことを隠して暴走したせいだ、 というのは単純すぎる見方なのではなかろうか。 うちの祖父母を含むそのへんの普通の人達が わずかづつ戦争に加担していたのではなかろうか。
． 今も変わらない。うちらが普段何をして、何を買い、何を言うかが じわじわと社会の空気を作っている。 政治家はその空気を読むだろう。そうでなければ落選する。 この先何が起こるにしても、その責任がうちらにないということはありえない。 誰か悪い人が少数いるという世界観は大人が持つべきものじゃない。 もちろん、悪い人がいないわけではないし、 「みんなが悪い」と言って誰も責任を取らないよりは、 誰かを見せしめにした方が全体としてうまく回ることもあるが、 それはテクニックの問題であって本質ではない。 責任というのはツールでありテクニックにすぎない。 プロジェクトが炎上した時に責任を取るべきなのは プロデューサやらディレクターやらだが、 道義的な意味での罪は全員が背負う。 シェーダ書いてただけだから関係ない、みたいなことは確かにあるだろうが、 それでも罪はゼロにはならない。大小はあるとしても、ゼロじゃない。 罪のある人が責任を取るわけじゃない。 責任を取るのは、責任を取ることが仕事である人だ。 責任を取るかどうかと罪があるかどうかは、必ずしも一致しない。
． 13章。OSからの継ぎ足し。 64ビット化が終われば仮想アドレスが物理アドレスより圧倒的に大きいことを 前提にできるようになるが、今はそうじゃない。 そうなると、それほど仮想アドレスを活用することに重きを置かなくていい。 下手にVirtualAllocに頼りまくると仮想アドレスの枯渇が先に来そうで怖い。 割り当てのアルゴリズムは知らんのだが。
． 採点。悩んだ末に提出した奴には全員60点以上を出した。 ただし、一人友達に作ってもらった奴がいるので、 その扱いは先生に委ねた。
． おととしの講義でも全員にお手紙を書いたのだが、 先生が届けてなかったらしい。今更発覚した。 去年は直接学生のメアドにメールしたが、 数人エラーが帰ってきていて、届いていたのかが怪しい。 今年もメールするつもりだったが、二人に送って二人ともサーバがエラーを返した。 もらったメアドが間違っている。 一応先生に届けてもらうようにお願いしてzipを送ったが、 やっぱりメアドを確認してもらうべきか。
． ミクの髪の毛はモーターとAIが入ってるようなもんだからな... プリキュアのアレはそこまではしていまい。知らんが。 というか、プリキュアキャラのプロポーションにリアル人間の 動きを当てれば、そりゃああもなるよなあ。
． 3分ヒープ。削除に手間がかかるので追加が速くなっても全体としてはトントン。 削除をもうちょっといじればプラスになるだろうが、 割に合うかは疑問。ヒープソートを3分とか4分にすると速くなるらしい、 というのは試しておくべきだな。そっちはコードが大して複雑化しない。
． 仮想アドレスと物理アドレスのことをよくわかってないことに気づいたので考える。
． 物理アドレスはメモリの実体についた番号。 仮想アドレスはそれと関係ない番号。 仮想アドレスで連続していれば、プログラマにとっては連続に見える。 物理アドレスが連続である必要はない。
． 物理アドレスと仮想アドレスの変換は何かがやってくれるが、タダではない。 タダではないが、ゲーム機でもない限りそこに介入する手段はないので 考えなくてもいい。ゲーム機だとそもそも仮想アドレスがないとか、 物理アドレス直指定ができたりすることもあるのだが。 でもまあ、そろそろそういうゲーム機もなくなるだろ。
． でここまでは当然知っている。わかっていないのはここからだ。 仮想アドレスが存在することは断片化問題に役立つか。 役立つ条件は何か。役立つ度合いはどの程度か。 これだ。プロセス違っても同じアドレスが使えて便利とか、 スワップできて便利とか、そういう効用については今は考えない。
． 今仮想アドレスが無限で、物理アドレスが有限であるとし、 ページサイズが1バイトであるとする。凄まじい仮定だが、考えるには丁度いい。 この場合、同時に使うメモリ量が物理メモリ量を超えない限り、 確実に取れる。つまり断片化問題は存在しない。本当か？
． 物理メモリが10バイトとする。5バイト取って、1バイト取って、4バイト取る。 順に先頭アドレスが0、5、6番地だとしよう。 5バイトのと4バイトのを解放して、 6バイト取ろうとする。仮想アドレスがなければ不可能だ。 0からは5バイトしか空いてないし、6からは4バイトしか空いてない。 しかし、仮想アドレスがあって、1バイトごとに対応関係を好き勝手決められるなら、 取れる。物理アドレスの0から4番を仮想アドレスの10から14に対応させ、 物理アドレスの6番を仮想アドレスの15番に対応させ、 仮想アドレスの10番を返す。6バイト連続に見える。めでたい。 かくして仮想アドレスを使うことで断片化に対処できる。 そして、ページサイズ、つまり物理アドレスと仮想アドレスの対応表を作る単位が 1バイトで、仮想アドレスが無限であれば、断片化という問題は存在しえない。
． では、ページサイズが大きくなってくると何が起こるか。 対応づけの制限が強くなる。例えば先の例でページサイズが2バイトになれば、 0から3を10から13に、6から7を14から15に対応させるように変更せねばならない。 結果、さっきならばなお3バイト取れたのに、今度は2バイトしか取れない。 物理アドレスの4番と8、9番を連続した領域に見せかけることはできなくなる。 しかし、メモリ全体の量がギガとかある状況であれば、ページサイズが 64KB程度であることはさしたる問題にはならない。 だから、ページサイズの問題はあまり気にするにあたらない。
． やっぱり問題は仮想アドレスが有限なことだ。 さっきの例なら、仮想アドレスが10番しかなければ、 なんぼ仮想アドレスが存在していてもどうにもならない。 5番に居座っている限り無理だ。先の例で言えば、仮想アドレスは最低でも 12必要だ。そうすれば6から11までを取れる。 要するに、メモリ搭載量が2GBで、プロセスのアドレス空間も2GB、 みたいな状況では仮想アドレスが使えることの断片化に対する効果はない。 もしかしたらあるかもしれんが、少なくとも薄い。 つまり、それに期待しすぎるのもマズいということだ。
． 仮想アドレスの問題を一旦置くとしよう。 ヒープが一個しかなく、あらゆる領域をそこから取るようにし、 必要に応じて拡張していくやり方の欠点を考える。 まず、一旦拡張してしまうと縮小が容易でない。 後ろの方のアドレスを少しでも使っていれば、もはや縮小は不可能だ。 結果、他のアプリに迷惑をかける率が上がる。 メガ量の確保もヒープ内から行われるので、拡張は素早く起こる。
． ヒープが一個しかなく、一定以上大きな領域は独立にOSから仮想アドレスを発行 してもらう場合の欠点を考える。 まず遅い。システムコールの回数が増える。 ただし、そのデカい領域を解放すれば、他のアプリから使えるメモリ量が回復するため、 他のアプリに迷惑をかける度合いは小さくなる。 一定以上デカい領域はやはり直接OSからもらった方が良い。
． ヒープがたくさん作れる代わりに拡張できないケースを考える。 まず、マルチスレッドでの性能が上がる。それぞれのヒープは並列アクセスできるからだ。 ただし、ヒープが複数あってバラバラに使われれば、容量効率は悪化する。 ヒープは一旦作ればほぼ確実に削除はできない。 これはマルチスレッド性能と容量効率のトレードオフになる。 それに、複数スレッドからボンボンnewされるような状況は まずない。ない、というか、そんなプログラムを書かないといけない状況が 思いつかない。
． CreateThreadに相当するlinuxの関数はcloneなのか。使う日は来ないだろうが。
． 14章はスレッドの問題を扱うが、スレッドとミューテクスのクラスを こっちで用意する。実装はwin32API版とpthread版を用意しておくことにする。
． ココナッツミルク、大して糖質多くないな。100gあたり3gくらいだ。 ひつじこが気持ち悪くなる理由がわからん。 ココナッツミルクじゃなくてナンプラーかもなあ。 ナンプラーもタイカレーペーストも使わないココナッツベースの即席煮物を 開発するか。野菜(にんじん、なす、ズッキーニ、にんにくが基本)を炒めて、 ココナッツミルクと塩入れて、 70度程度に保って肉を加熱、しばらく保温、 という料理を作ってまずは味見してみよう。 ダシは肉と野菜とココナッツからそこそこ出るので、 たぶん塩だけでもそれなり以上に食えるものにはなるはずだ。 大量にある鮭を一緒に入れてもいい。鮭の腹身と豚肉を 一緒に入れてもお互い邪魔しないのは味噌汁で確認している。 あとはせいぜい胡椒、クミン、ターメリック、カイエンヌペッパー あたりで風味付けすればそこそこ食えそうな気もする。 タイカレーペーストやナンプラーは主張が強すぎるからな。 同じ味になってしまう。
． ココナッツミルクとトマトは合うか。味噌、醤油は合うか。 いずれ実験せねばなるまい。
． カツオの刺身は、スーパー等で半額になってから買うなどして 鮮度が微妙な時には、オリーブオイルと塩、胡椒、 トマトと和えて食べると醤油で食うよりも気にならない。 パセリも撒くといいかもな。試してないし、もっと合うハーブもありそうだが、 ハーブ経験は足りてないのでよくわからない。 バジルとパセリくらいしかわからん。 スパイスも胡椒とナツメグとクミンとターメリックくらいしか把握してないしなあ。
． 醤油は10%炭水化物。味噌は20%炭水化物。糖質制限的に味噌はダメ調味料である。 気にせず食うけどな。味噌50gとか食べないだろ普通。
． 江部氏の提唱するスーパー糖質制限は一食あたり20g。 アーモンド100gで10gだから、ナッツやチーズ、肉魚卵を食べている分には これを超えることはまずない。調味料の類はまず問題にならんし。
． で菓子。比較的糖質が少ない菓子であるシュークリームやチーズケーキ でも15-20gの糖質がある。 スニッカーズ等の普通のチョコレート菓子や、コーン付きのアイスクリームは あっさり30gを超えてくる。カカオ多めのチョコレートか、 プレミアムグラン等のコーンがないアイスがよろしい。グランは実にうまい。 大福などの餅系の和菓子はヤバくて、あっさり50gを超えてくる。 油脂が少ないのでカロリーを4で割れば即糖質量である。 また、私が好きなヤマザキの月餅もヤバくて、50gを超える。
． 一番健康的な甘味は冷凍で大量に買ってるイチゴ、ラズベリー、クランベリーだな。 こいつらはどれも糖質はかなり少ない。 日本産のイチゴはすごいことになっているが、 フランスやアメリカからの輸入物はそれほど甘くないのだ。 ましてラズベリーやクランベリーはなおさら甘くない。
． てんぷらなどの揚げ物がヤバい。コンビニの揚げ肉も結構な糖質量。 ところで、揚げ鳥はファミマが圧倒的。もちろん高い方。
． うちは食事はスーパー糖質制限なんだが、菓子欲は残ってるからな。 一日の糖質摂取量は100gには満たなくても、50gを超えてくる日が多い。 もっとも、50gであればカロリーにして200kcalだ。
． 野菜ジュースが結構ヤバい。930gのペットボトルを丸々飲むと糖質が30gを超える。 安物で180mlあたり6g。濃いやつで10gくらいの糖質がある。
． kabini積んだThinkpadEdgeがそのうち出るっぽい。予備に買うか。
． 2248。11章まで終わったな。あと3章。辛い。
． 2645。落ちそうになりながらなんとか最後まで片づいた。 まだ漏れてるとは思うが、だいぶ完成度が上がっただろう。 編集さんにも「勝手に直さないで！」って言えたし。 どうも、他の著者の人達が勝手に直しといて派だったらしく、 その調子でやりすぎてしまったらしい。そういうもんか。 「これはオレの本じゃー」的なこだわりって、あんまりないもんなのかね。 技術系だと。
． そのうち数学ガールみたいに物語入りの奴書きたいが、 そんなのの前にmallocとCGと前の改訂の3つは片づけないと。 そしてそれが片づいたら、コードなしでのプログラミング入門を考えたい。
． 萌え萌えした技術本とか書いてみたいんだけどな。 要は単純にラノベを書いてみたいだけなのだが、 自信がないので技術と抱き合わせ販売して弱味を補強しよう、という話だ。
． 寝て起きたら、試しにInkscapeで一個図を書いてみるかなあ。 いや、先に採点か...
． 技術系の出版では、内容以外のものは重視されないんだろうな。 前に技術系の記事を頼まれた時には、 私が書いた文章が原型を留めないレベルに改変されていた。 あれは自分の中では私が書いてないことになっている。原案くらいの位置付け。 技術系の文章ってのは、たぶん英語にしてから日本語に戻しても 価値が変わらないような、それくらいに内容以外はどうでもいいジャンルなんだろう。
． というか、技術系の出版社でもtexを知らないとしたら、 texってのは一体どこで使われているんだろう。 数学ガールがtexだったので、ソフトバンクはtexが通る出版社なんだろうけどなあ。
． 今はtexのファイルに改行を取り除くスクリプトをかけて渡している。 プレーンテキストが普通らしいが、普通の著者は一体どうやって 仮レイアウトをしているのだろうか。 仮レイアウトしないと友達に読んでもらって直すとか評価してもらうとか そういうこともやりにくいだろう。 プレーンテキストでは図も入れられない。 つうか、一体どういうシステムで組版しているのだろうか。 それがわかればこっちで支援スクリプトを書いたりもできるのだが。 InDesignかQuarkXPressのどっちかなんだろうけど、そういう 高いソフトは見たこともないのでわからんなあ。
． ひつじこ、まだ産まれないらしい。 もっとも医者が適当っぽいらしくあまり当てにはならない。 とりあえず、本の作業がなくなるまでは産まれないでいてくれる方が ありがたいといえばありがたい。 家にいながら校正対応をするのは大変だろうからだ。
． でも、さっさと産まれてしまうのもそれはそれで楽だけどな。
． 教育言語と言えば今はscratchらしいので見てみた。 おーいきなり音鳴るし、10歩歩けとか言えるし、そりゃ楽しいわな。 だが、これに対抗しようと思えば大量の機能を実装せねばならんし、 なにせwebベース必須である。まあ対抗しようと思うのがおかしいわけで、 私は私のやり方で考えよう。 結果としてやりたいことがscratchと一致するならば、scratchを使えばいいのだ。
． いきなりできることが多すぎるあたりが好みじゃないなあ。 私はやっぱり少ないブロックと、それを組み上げる考え方だけから どうにかする方が好きなんだな。レゴでも基本ブロックばかり大量に欲しいタイプだし。 確かにタイヤとかはどうしようもないわけで、バランスが難しいところではあるのだが。
． ソースコードが生テキストである必要がない、 という言葉を見て、そうか！と思った。 字句解析までした状態の中間コードだけ保存して、 何らかのスタイルファイルを指定してコードを開くと そのスタイルで表示される、みたいなことができれば、 確かに空白の入れ方やらインデントやらはそれぞれが自分の好みの状態で 作業できるわけだ。で、SVNにコミットする時には中間コードだけをコミットすると。
． 問題は、「好きなエディタで編集したい！」みたいな要求があることだが、 そんなことを言うのはプロだけだ。 私は正直プロの作業環境に興味はない。 私は誰が何と言おうとどうせviで、他人もそういうこだわりがあるだろうから放置だ。 だが、初心者用ならばそこを設計する価値があるし、せねばならない。 Sunabaのコードが生テキストである理由のかなり大きな部分は、 エディタを自作する手間をかけてられない、ということだからな。 もしかして、ここをどうにかして、マウスで視覚的にコードを作れるなら その方が初心者にはいいのかもしれんけどなあ。 そういうご時世なわけだし。
． 真面目にやるなら、まずすべきことはVisualSunaba、みたいなIDEをちゃんと作る ことなんだろう。すばらしく面倒くさいな... webでUI作る時ってどうすんだ？ボタンとかスライダーとかメニューとか、 そういうののツールキットって標準的な奴があるのか？ つうか、もしwindowsアプリとして普通に作るなら、 OpenGLで丸ごと描画させて、ツールキットごと自作するな。 そうすればWindowsのメッセージループの制約を受けずにすむ。 圧倒的なサクサク感にできる自信がある。 簡単な奴は以前作ったので、あれの見栄えを良くして必要な機能を順次足していくだけだ。
． GUIのツールキットを自作するかどうかはともかくとして、 生テキストを書きこむ以外の方法でコードを書けるようにする環境整備は やらないといけない気がしてきた。あと2冊書いてまだ書いていいようなら考える。 オタマがプログラミングを学び始められる年になる前にやらんといかんと考えると、 あと3年くらいしか猶予がないな。 オタマの前にひつじこにやらせねばならんことを考えるとなおさら余裕がない。
． 今回のテトリス本は、数年後に作るVisualSunabaのプロトタイプなのかもしれない。 もちろんIDEを完備するのとしないのでは学習効果も対象も違うから、 メモ帳だけでプログラミングする今回のコンセプトはこれはこれでいい。 ただ、コードを書かねばならない段階で相手にできない人がたくさんいる以上、 コードを書かずに同じことをやれる道を用意することは必須だ。 なんとしてもwebアプリでGUI的にプログラミングする方法を作らんといかん。 そしてそれは、テキストでコードを書くことにつながっていくことが望ましい。 結局テキストは消えんだろうし、コンピュータがない場所で コードを表示できる方法はそれしかないのだ。 scratchの本とかあるにはあるんだろうが、たぶん紙であることの不利を 存分に味わえる代物になっていることだろう。
． よし。とりあえずレイアウト案へのツッコミは入れ終えた。 malloc本の続きを書こう。
． 前の本、本当に誰か殺してくれないかな。もっといいのを書いてくれよ。 改訂しないといけないのに改訂してるヒマがない。 しかも改訂は商業的な意義が薄い。 前のを買った人が全員買い直してくれるというならいいが、 そんなことは絶対にないのだ。 改訂しなければ売上が0だが、改訂することで今後10年売れる、 とかいうならいいが、そんなことはないだろう。 改訂に何か相当な売りがないとダメだろうな。 文章は完全に書き直すだろうし、一部の説明も完全に直すし、 つけるライブラリも完全に書き直すだろうが、 それが売りになるかと言うとなんとも言えない。 やっぱあれか。「iOSでもオーケー！Androidですぐ動く！」とかか？ でもそれをやるのはきついなあ。 いっそJavascript+HTML5前提であの本の内容を再構成した本を 作る方が意義があるように思われる。
． あの後分厚いゲームプログラミング系の本がなんぼか出たと思うが、 結局私読んでないもんなあ...翻訳だったり著者が複数いたりすると、 それだけできつい。技術書の翻訳は大抵日本語がいまいちだ。 感情とか臭いとかテンポとか、そういうのがひどいことになる。 著者が複数いると、一貫した物語が感じられなくなる。 技術書にも小説やエッセイと同じ種類の面白さを入れないと 私のように技術だけで楽しくなれない人間は読めないのだ。 なぜそこに気を使わないのか全然わからない。 今回の本を書くのに参考になると思っていろいろ見たが、 大抵の本は面白くない。私の本が面白いかどうかは読んだ人によるだろうから なんとも言えないが、少なくとも私はそこはかなり気にしている。 技術的な正確性なんかよりそっちの方が重要だ。 多少おかしくてもいいんだよ。おかしいとわかる奴を対象に私が書くことはないし、 私の本を読んだ程度で、それでプロとしてやっていけるわけでもない。 小学校の算数を教えるのに大学レベルの数論ができる必要はないだろ？ もちろんわかってた方がいいが、何もかもを揃えることはできないのだ。 大切なのはそこじゃない。
． 「憂鬱なプログラマのためのオブジェクト指向開発講座」という本が評価高いな。 ちょっと本屋で覗いてこようか。 他人のオブジェクト指向の説明で私は一度も腑に落ちたことがないのだ。
． 医者に「ケトン出てると何がどう悪いんですか」と聞いてみたい気分でいっぱいだ。 江部氏のサイトを見ると、糖質制限初期にはケトンの利用効率が悪くて 尿に漏れてしまうが、だんだん体がケトンを燃やすのに慣れてきて尿に出なくなるとある。 これは素人目にも納得の行く論だし、江部氏は糖質制限状態の人体を 多数見ているので、そのデータに関しては信頼できる。 つまりひつじこはまだ体がケトンを燃やすのに慣れていないということになるが、 もう結構長いよなあ。体質的にケトンを燃やす能力が高くないのかもしれないし、 あるいは妊娠で変わった状態にあることと関係があるのかもしれない。 というか、酸素の取り込み能力が足りないせいな気はするんだけどな。 脂肪をケトンまでバラすのには酸素はいらないよな？確か。 しかしケトンを燃やすには酸素がいる。 ひつじこは慢性的に呼吸が浅く、しかも最近運動していない。 一緒に運動をすればあっさり改善する気はするんだが、 まあそれは産まれてからの話だ。今動けというのは無茶すぎる。 とりあえず、ケトンが出るのは脂質代謝が普通よりも活発で、 その割に燃やせていないからである。 澱粉を食べていないのだから脂質の代謝が活発なのは当然で、 これは飢餓によるものではない。 こんだけ食ってて飢餓とかねえよ。 だいたい飢餓なら体温が下がる。
． あーでも糖新生能力は低そうだな。腹が減るのが速すぎる。 私なんか頭が食べたがるだけで、ちゃんとした空腹感は 丸一日くらい経たないと出てこないからな。 もちろん澱粉を食べれば別だが。ひどいことになる。 たぶんこれも運動して酸素取り込みを鍛えれば変わってくる気がするがなあ。
． 医者って大した知識持ってないぞ。本当そう思う。 経験的な知識はあるが、構造としての知識がある人は稀なんじゃないか。 とか書くと、 「素人のくせに医者を信用しないとか、変な宗教にはまってるみたい。頭がかわいそう」 と、輸血を拒否するモルモン教徒と同一視する人もいるんだろうが、別にかまわん。 そういう人がいてくれるからこそ、 自分がやっていることの論拠を常に強化しようという気になる。
． 糖質制限も、納豆ダイエットに踊らされるアホと同じに見られてるんだろうがなあ。 まあいいさ。なお、サバ缶ダイエットは悪くないと思うぞ。 蛋白質とオメガ3脂質を豊富に取れ、カルシウムまでついてくる。 野菜を何かしら補充すれば、それでほぼ問題なく生きられるのではなかろうか。
． 医者がそれほど特殊な人種とも思えんよなあ。 ゲームプログラマに比べて平均知性レベルが著しく高い、 ということはあるまい？大鳥居の先生は尊敬しているが、 あのレベルに尊敬できる医者なんてそうそう見たことがない。 構造を理解した上での知識を持ち、経験が豊富で、 人間的にデカい医者、というのが良い医者なわけだが、 そんなのがゴロゴロしているわけがないのである。 医者にそれを期待するのは医者にとっても辛いだろう。 プログラマの大半は、プログラマでない人が思っているほど有能じゃない。 有能だと思ってもらっては困る。医者も同じだ。
． 12章を一応書いた。一応すぎるので、明後日あたりもう少し見直す。 それにしても単なるサイズ別リスト速いなあ。 断片化耐性は二分検索木ベースにかなり劣るが、 速度が2倍とか3倍とかなのでさすがに迷うだろう。 しかもこれでもまだ最適化甘いんだろうし。TLSFって奴がすごいんだろ？ まあまだ論文すら読んでなくてwikipediaしか読んでないんだが。 でも、2段で分類してるという意味ではこれとあんまり変わらないんじゃね？ と思ったりはする。そもそも空きリストの分布が偏ってたら なんぼうまく選んでもダメだしな...
． TLSFは、true love storyにしか見えないぞ。Fってなんだよ。ファンタジーか。 あれついに3はやらなかったなあ。
． 考えたらテトリス本の表記揺れの問題をまだ見てなかった。 1つ2つと、一つ二つは使い分けてた気がするんだよな。 どうだったっけ？とりあえず全部算用数字に直されてしまったが、 それでいいんだっけか？なんか違う気がするな... 「一つには」みたいなのは数がどうでもいいので漢字で、 「1つ目は、2つ目は、6つ目は」みたいなのは数にしていた気がするのだが... もう眠い。続きは明後日だ。たぶん明日は疲れて動けんだろう。
． 後ろからキーの音が...うわ、徹夜してる人がもう一人いるよ... あの人近くにいる割に一回も話したことないんだよな。 でも徹夜までして働いてる人に話しかけて邪魔とかできん。
． 「1つ」に直された「一つ」を、一つづつ検証してどちらが良いか指定して回る作業。 大半は漢字でいいはずなんだよ。 逆に数字に直している場所もあるが、それほど多くない。 というか、日本語の中に算用数字が出てくると、私はそこで引っかかりを感じる。 5や7,243に置き換えても日本語としておかしくならない時には、それは純粋に数なので 算用数字でもいいが、「一つにする」「もう一つ」「一つづつ」「一つには」 といった場合には漢数字だろう。だって、それ数じゃないもん。 日本語の言葉であって、数としての意味合いは薄い。
． 莫大な数ある。これをいちいち「1つ」に直して回ってくれたのか... 「表記ゆれ」って言うけど、それって統一すべきもんなのか？
． いかん、もう6時になる。土曜の過酷さに耐えられなくなる。 寝よう。どんなに遅くても日曜の夜には全部やらんといかん。
． 空きリストを2羃で分類したら速いかわりに、 すこぶる容量効率が悪い奴ができた。 その準備段階として10羃で分類した奴を書いたが、 こっちはさらに速い変わりに、さらに容量効率が悪かった。 というわけでこれを準備段階として、 空きリストを2の平方根を乗数して構成して容量効率を改善し、 さらに2の4乗根を乗数にしてさらに容量効率を改善する。 そこまでやったらリストの検索を高速化して、 結果的にTLSFに近い何かになる。 2の平方根を法にするといっても都合のいい近似で、 4,6,8,12,16,24,32,48,64といった数列になる。 これは単純に上から2ビット見るだけだからビット演算に直すのは簡単だ。 2の4乗根も近似で、4,5,6,7,8,10,12,14,16,20,24,28,32といった数列になる。 上から3ビット見るだけだ。 2の羃で粗く分類した後に中途半端な部分の分類をするので二段階になる。
． 2羃サイズに限定して再帰分割するk-d tree的な奴もやろうかと思ったが、 どう考えても容量効率が悪いのでやめた。 それに他の技法との関連も薄い。おおむねそんなもんだよな。
． 会社納会。ピザ、寿司、からあげ、薄い小麦粉生地に野菜とか肉とか 巻いて輪切りにしたやつ。というわけで炭水化物。 食べないつもりだったが、つい食べてしまった。ひどい不快感。 仕事とか不可能。後半は輸入物で全然甘くないいちごばかり食べていた。 甘くないっていいなあ。すまん日本の農家。
． malloc本11章。テストの問題。12章はやはりサイズ別リストを扱う。 実質TLSFだな。 13章はOSからの追加。14章はマルチスレッド対応。
． 10章は乱数でMWCの一歩手前までを扱うが、10ページ足せばMWCに至る。 足すべきか、足さないべきかで迷う。 MWCと乱数の性質自体は同じだ。数が出てくる順序が逆順になるだけである。 ただ、速度は半分くらいになる。つまりMWCにすれば倍速になる。 しかし、10億回あたり6秒を3秒にすることに意味があるか？ と言われると、意味があるほど速度が重要な応用はそう多くない。 それに本筋から外れた改良に10ページ払う意味はない気がする。 だいたいここまでわかっていれば、MWCをwikipediaで調べれば済むのだ。
． マルチスレッドの問題は是非とも扱いたいが、 スレッドは環境依存だ。 boost入れてくれ、とか言いたくない。 14章はwindows用しかサンプルを用意しません、というのもどうかと思うな。 とりあえずpthreadの導入が簡単にできるならそれがいいのか。 どうせ使うのはmutexだけだし。 でもそうすると、今度はVisualStudio派の人にとって面倒になる。 一番マシなのはboostだなこれは。
． うわ、boostのインストール面倒くさい。これ強いるのは嫌だ。 ビルドってなんだよ。
． とりあえずCreateThread呼ぶか。8割の人にとってはノーコストだ。 一応pthreadで使った場合のコードも入れておけば問題あるまい。
． 数学ガールのゲーデルの奴を読んだが、さっぱりわからん。 正確に言えば、わかろうと思えない。 ネタがネタだけにそうなるだろうとは思っていたが、 やっぱりそうなった。
． 11章がだいたいできた。mallocの評価を行うためのテストプログラムの設計と、 それを使ってそれまでに作ったものを評価してみる実習。 12章は2羃サイズ別空きリストと、2段階化を扱う。 眠くなければ明日の朝までに12章がおおよそできるはずだが。 12章で作るものの結果次第で赤黒木もつっこむかどうかを決めよう。 13章のOSからの継ぎ足しは大問題だからもうちょっと考えないとな...
． 数学ガール、乱択アルゴリズム。選ばれた人間はこういうふうに プログラミングを捉えているのか。 そして、古代においては選ばれた人間以外はプログラミングの世界にいなかったので、 このやり方が標準かつ唯一だったわけだな。 正直に言って、私はこの考え方でプログラミングをしていない。 だからクヌースACPが読めないのだ。 同様に、これも非常に読みにくい。真面目に追えば読めるだろう。 しかしそうする気が起こらない。 そして私はこうでないプログラミングの方法を人に教えようとしている。
． 仮に私が今後10冊も20冊も本を書くようになるとしても、 この人と同じ土俵には立つまい。 まあ立とうとしても立てないだろうが。 この人には、単なる技術書書きとは全く違う臭いがある。 著者のキャラが伝わってくる本だ。 厳密な思考を好むこと、歴史と先人に敬意を示すこと、そしてキリスト教。 著者のキャラが濃い本は、ファンがつく。それは見習いたいが、 それは自然に起こるべきことで、それを狙ってやっても寒くなるだけだろう。
． スイカのペンギンのタオルをもらった。オタマ大喜び。 サイズを合わせるためにひつじこが改造してた。 ありがとう。
． お金メンテナンス。これでまた数ヶ月放置できる。さすがに落ちついてきたな。 値上りしてから買った分は割高なので、一時ほど利益率は良くない。 かなり薄まっている。
． 早いところ年間収入の1/5くらいは投資由来にならんかなあと思うが、 年間100万出るためには、2%を仮定しても5000万必要だ。 さすがに遠い。これから新興国も減速してくるだろうし、 投資から収入を得ることは期待できんな。 投資は単純にリスク軽減の手段と考えるべきで、 もうける手段とは考えない方がいい。
． 本当人には勧めにくい。しかし、定期預金にドーンとつっこんでる話を聞くと さすがに心配してしまう。 世間の常識的に定期預金の方が投資信託等々に分散するより安全と思われている ので、分散した方がいいよと軽々しくは言えないのだ。
． 定期預金の利率って0.1%とかなのか。完全に金庫だなそれ。 国債の方がまだマシじゃないの？ 銀行よりは国の方が安全だろ普通に考えて。 定期預金がインフレ率に負けたことはない、と言っているが、 高度成長期とそれに続く成熟停滞期のことが、 これからも適用できると信じる気にはなれない。
． こんな態度が求められている！！とか言っても、無駄だよなあ。 白けるだけだ。 都合がいい行動を取ることが得になるように 環境をいじることが必要なのであって、 説教垂れて人のやる気を奪うのは下策もいいところである。 「報告は迅速に」とか、そんなの時と場合による上に、 そうする動機がこっちになければそれまでだ。 面倒くさいことはしないのが人間なのであって、 報告してほしければ報告したくなるように仕向ければ良い。 偉い人が「プロたるものこうすべし」とか言うようではおしまいだ。 もしかしたら語り方によっては共感と賛同と尊敬を得られるかもしれんが、 それは演出の問題であって内容の問題ではない。 演出によって変えられるのは感情であって理性ではない。 そして感情の変化はごはんを食べて寝れば消える程度のものだ。 そういうことをやる先輩とか上司とかにならないように注意しよう。 まだ中二病の方がマシだ。
． 別に何があったわけでもないよ？
． 炎上って何なんだろうなと思うわけだが、 つまるところ、本気でどうにかしようと思ってないから炎上するんだろう。 しかし、私の言う「本気でどうにかしようと思う」はすでにしてスキルだ。 私は「本気でどうにかしようと言うならば、何をせねばならず、 それは誰がやり、いつまでで、まず何から手をつけるのか、を決めずに会議を 終えることなんてありえない」と思っているが、 そう思って実行することがすでにしてスキルである。 人によっては「それは能力の問題であり、意思の問題ではない、 と言うかもしれない」。 どうしなしなきゃと思いながら思考が堂々巡りして何一つ進まない、 というのを「本気でどうにかしようと思ってない」 と呼んでいいかどうかは意見が分かれる。 しかし、私は意思と能力を分けて考えることに意味を感じない。 意思は個人の脳内にしかないもので、他人が観測できるものではない。 そんなものは、客観的にはないのだ。 意思は行動結果によって決定されると考える方がいい。 「こうしようと思ってそうする」のではなく、「こうしたのだからそう思っていたのだろう」 が妥当である。信頼も実績も行動の積み重ねによって得られるものだ。 それだけが考慮に値する。
． あるプロジェクトが炎上するかどうかは、誰を投入するかが決まった段階で、 ほとんど決まっている。期間、技術、人数といった制約要因は、 マネジメントの問題に比べれば大した問題ではない。 そのことがよくわかった。
． 技術を高めて制約を緩めてやっても、 せっかくの余裕を別の無駄につっこんで元の黙阿弥となる例は珍しくない。 いくら収入があってもつまらんものに無駄使いすれば同じ、 ということだ。収入が足りないのが問題ではないのである。 「速いCPUはより遅い生産性の高いコードを書くためにあるんだよ」 と自慢気に言う奴がいるが、コンピュータの無駄使いがちゃんと コストダウンにつながっていることを証明できているのかね。 私の印象では、とても効率が上がっているようには見えないのだが。
． 循環するものは円のイメージで理解できるという。 数学ガールにあった言葉で、言われてみればその臭いがする。 x+=a mod mが全ての自然数を取るかどうかは、aと法mが互いに素かどうかでわかる。 m時間ある時計を描けばわかる。 そしてこれは、加算で乱数を作った時に周期が最大になるかどうかと同じ問題だ。 加算の場合の周期最大条件は簡単である。 1とm-1は必ず最大周期だ。他にあるかどうかは場合による。 例えばm=6ならない。
． 乗算で循環するものも円のイメージで理解できる。 これは複素数がまさにそれだ。 さて、こっちで周期最大になる条件が難しい。
． 1.5TのHDDが出た。でもまあ容量密度が上がったわけではなく、 ギガあた8.6円と高い。無理矢理3枚詰めただけか。 HDDの容量増加は完全に止まった印象があるな。
． 数学ガールはいい本だ。でも、私が相手にする人はこの本をたぶん読めない。 この本も相当にストーリーを練り上げていて、 私程度でも一応は読めるようにしてくれている。 しかし、この本を私が面白がって読めているのは、 乱数がらみで整数論を必要としているからだ。 問題意識を持ち、それについて考える時間を過ごしているからだ。 その前提条件がない人に、この本はおそらく響かない。 そういう人をこの世界に連れ込もうとするならば、 違った何かがいる。
． 2巻の後半はよくわからんのでいいや的な。記号思考は向いてない。 しかしよく整理したもんだ。数学できるってのはすげえな。
． ax mod mで、x=1から始めて永遠に1に帰ってこないことはありうるか？ 1、a、a^2...と進んでいくわけだが、 まず1に帰ってこないとすれば、aには帰ってこない。aになるならその一回前は1 以外ないからだ。そして、aに帰ってこないとすれば、a^2にも帰ってこない。 a^2になればその一回前はa以外にないからだ。 そういうふうにつなげていけば、a^nの全てのnに二度は来ない、ということになる。 しかし、要素数はm個しかなく有限だから、そんなことはありえない。 そういうわけで、1から始めればいつか1に戻ってくる。 つまり、初期値1で線形合同法を始めた時には 1に戻ってくるまでの回数を周期としていい。 変なところで無限ループこくことはない。
． 32要素の01で成るベクタvに、1024要素の01で成る行列Aを掛ける。 ここで掛け算は個々の要素は01にしかならないような演算であるとする。 さて、ある初期値v0から始めて永遠に帰ってこないことはありうるか？ これがありうることは経験上わかっている。XorShiftの周期を調べようとすると、 初期値を含まないループにはまることがあるからだ。 極端な話、x<<1を表す行列をAとすれば、32回以内に0になってそのままになる。 全部1になって帰ってこないAもある。 このへんの数学的扱いが厄介なのが行列系のアルゴリズムの嫌なところなのである。
． 5,1のxorShiftは周期が40億ちょいであり、これは全周期2^32から 1億2億欠けた数だ。普通掛け算で作ると、周期は法-1の約数になるが、 この場合そんな規則性はない。 そしてここに1が入っていないことはありうる。 ビット0だけ1のものを1と呼んでいるが、この演算において各ビットは平等だから、 整数値としての1を特別扱いすることはできない。 値は行列の影にすぎず、数の実体は行列だ。 つまるところ行列が2^32通りあるかどうかという問題になる。 Aを2^32回掛けてAになることは周期が2^32-1になるための必要条件だ。 周期が2^32になって0もオーケーな演算ないかなあ。
． ひつじこのは嫉妬ではないということで訂正。 私の原動力たる劣等感の方がまだ近いかもしれないが、 ひつじこは暗黒面から力を出すタイプではないので、それもズレる。
． 土曜の夕方、外出から帰ってくると、 オタマが迎えに来てくれて、そのままひつじこの実家に行くことになった。 まあ体力の問題はいいし、一泊なら食料の問題も無視できるのだが、 問題は夜寝るのかだ。母親がいない状況で寝たことはまだないのだ。
． 結論から言えば、そこそこ大変だったが、どうにかなった。 朝10時ごろになって帰るというので帰ってきた。
． 数学ガールの数学の説明は質が高い。娯楽になっている。 しかし、根本的に娯楽として数学をやろうという意思がない人間には辛い。 つまり私のことだが。sinの因数分解とかすごく面白いんだが、 何分余裕がないので「で、これどう使う？」ということばかりが頭にちらつく。 余裕がない人間にとって数学は手段であって、 他のもっと楽な手段がない時にやむを得ず取る ものでしかない。やってるうちに面白くなってくる、ということはあるにしても、 面白そうだからといって始めるものではない。
． 例えば私はコンピュータで計算させることのために数学を必要としている。 32ビットであれば、数は40億個しかなく、 それ全てで成り立つことは、事実上全ての整数で成り立つこととして 扱ってかまわない。もちろん、「32ビットの範囲では」 という条件がつくことを忘れていいとは言わないが、 あらゆる整数で成り立つことを証明してから使うべきだ、ということにはならない。 数学が必要になるのは、例えば計算時間的に40億個の総当たりが不可能で、 何かの理屈で候補を削りたい時であり、 その場合も間違っていることを確認する手段があれば仮説でかまわない。 例えば「3の倍数でない限り使えない」という仮説は、 「仮に使った時にダメであることがすぐにわかる手段」があれば、 仮説のままでも使うことができる。
． もちろん、それでは問題を完全に理解しているとは言えない。 しかし、十分に理解しているとは言える。 自分が使っているやり方が依存している仮定や適応範囲をわきまえていれば、 そこに理論がなくても実用上は十分なのだ。 それ以上の理解は、理解にかかるコストが安くない限り正当化されない。 しかも、単に私が理解できればいいという話ではないのだ。 私が書いたコードは他人が理解できなくてはならない。 したがって、私がコードを書くのに使った理屈は説明可能でなくてはならず、 しかもその説明を理解できる人間が十分に多いレベルに抑えなくてはならない。 だから先端技術の大半は使い物にならんのだ。 現実には完全性はほとんど必要とされない。十分であれば良く、 大抵は妥当でありさえすればいい。
． この考え方はアンチ数学のようではあるが、 ある意味では数学的でもある。私は「何がわかっていないのかを 把握すること」「何があれば十分か」に関してはかなり厳密さを要求する。 普通はそこも適当なので、たまたま動いているだけのものが製品に入って、 特殊なケースでバグを噴いたり、書いた人間が忘れたりいなくなった後に 危険なブラックボックスになったりとロクでもないことを引き起こす。 私はそれは嫌だ。しかし、大抵はその危険はあまり重視されない。 とりあえず「動けば良くね？」で進む。 それで大抵炎上するわけだが、炎上しても人はそれを変えない。 炎上してもいいやと思っているのかもしれない。 これは人類の脳がそういうふうにできているということだろう。 たぶん絶対に直らない。
． 本当思うが、数学は人間の脳には向かない。 だからこそ数学ができる人間は偉大なのだが、 偉大と言う言い方は一種ごまかしで、 正直に言えば異常というべきだろう。 数学ができるのは異常なことなのだと考えれば、 それを全員ができると考えるのは馬鹿だということになる。 もちろん、それでも数学は学ぶべきである。 その異常な思考法は恐ろしく役に立つし、 今の社会はそれを多少なりとも理解していることを前提としている。 しかし、大多数の人間に関しては、それが日常の思考法になるまでに 鍛えるのは無理である。どうしても大切な局面で 気合を入れて使う、というのがせいぜいだ。
． 数学は数学だけで教えるのは無理だと私は思う。何かに混ぜて教えるべきだ。 もちろん、純粋な形で厳密な数学に取り組んで初めて得られる ものというのはある。そうでなければ抜け落ちてしまうこともあるし、 不純な形にすることで優秀な人間が伸びることを阻害する恐れもある。 しかし、その副作用を受け入れてでも、 もっと多数の人間がちゃんとわかるような内容を教えるべきだし、 教え方も多数の人間がわかるものに変えるべきだ。 そうでなければ教育が機能しているとは言えない。 私は京都大学を大学院まで出ている。 しかし、正直数学は全然わかっていなかった。 中学では幾何系の証明ができなかったし、 高校では微積分がまるでわかっていなかった。 ただ、わかっていなくても点数は取れるのである。 結局、多くの生徒は「わかっていなくても点数が取れる方法」 を学ぶことに走らざるを得ない。それが上手だった人間が、 高い学歴を得るのである。
． 理科を拡大して、理科の一部として数学をもっと積極的に混ぜていく方が まだマシなんじゃないかと思う。 数学で微積をやってから物理で使う、という順序は絶対に無理だ。 それでできる奴は1/10もいない。 大学が大学だけに、周りにはそれで違和感なくできる奴がゴロゴロいたが、 あれは異常な環境なのである。 そしてその異常な環境ですらも、線形代数演習で黒板で問題を解ける奴は 1/10もいなかったのだ。 だとすれば、高校生全員のうち、大学数学へ進んでいいだけの力を持った人間は 1/100もいないということになる。 これはつまり教育が機能していないということではないのか。 学校教育は塾じゃない。優秀な奴を選抜する場ではなく、平均学力を高める場だ。 できる奴だけができるような内容を、できる奴しかできるようにならない教え方で 教えるのは罪だ。
． 数学ガールや、13歳の娘に語る〜は、 こういう状況をどうにかする上で重要な本だと思う。 しかし、まだ足りない。趣味人向けじゃないのが欲しいな。
． 塾とかやったらいろいろ実験できるんだろうが、 その前にオタマに実験台になってもらおう。 その前にひつじこだが。
． 数年以内にテトリス本よりもさらにレベルを下げた本を書きたい。 売れたら。 コードを書くことを強いる段階でアウトな人がたくさんいる。 したがって、「コードを書かない」という縛りでどこまで プログラミングを説明できるかを考えてみたい。 それを読んだ後ならコードを書くことにさほど抵抗がなくなって テトリス本を読める、というようになることが望ましい。
． Sunabaをキーボードなしで書ければいいのかもしれんけどなあ。 なんかかわいいアイコンのフローチャートみたいなので ロジックを示せればいいんだろうか。 しかし、10時間も経ったらかえって面倒くさくならんか？ 結局、1クリックでできることを大きくしないと割に合わず、 それはつまり用意済みの機能を叩くような作り方にするということだ。 仮にそれを拒否して、Sunabaと同じ機能しか持たないプログラミング言語を、 Sunabaよりも楽に書く方法を模索する、というふうに問題を縮小したらどうなるだろう。 あるいはSunabaをどこまで楽に書けるか、と考えるか。 VisualSunabaは一旦試してみるべきアプローチなんだろう。ダメならダメとわかる ことが重要だ。
． 12章見直し。眠かったので怪しい。でもそのまま13章見直し中。
． 文体とかリズムとかまで気にするとキリがないが、 そこをあんまり切り捨てたくはない。 わかりやすく、それでいて邪魔にならない程度に香りというか臭いというかが ある文章にしたい。 最低でも何かしらのキャラを感じさせたい。 まあ、この本に出ているキャラが私自身とは限らんがな。
． 数学ガールを読んでいて思った。 協力してくださっている方はテトラに似ていらっしゃる。 驚くほど本質的なところで引っかかって質問してくださるところが。 自分が到底自明でないことを自明とみなして甘い説明で済ませていたところが 山ほどあった。未熟。
． ひつじこもやってくれたらそんな感じだったかもしれんけどなあ。 ちなみに、ひつじこはその方に若干、というか結構嫉妬してた。 「自分も役に立ちたい！」らしい。 役に立つ役に立たないで結婚してるんじゃないから別にいいんだが、 まあそういう思いはよくわかる。
． ラベル先生の授業で、「お互い健康でいたい」みたいなことを言ったら、 「健康でなくても素晴らしい愛を持っている夫婦はいますよ」と言われた。 それはその通りだと思うが、私はひつじこの役に立ちたいので、 そのためには健康である方が都合がいい。健康でなくなった時は それはそれで仕方ないが、やはり申しわけないと思う。 もちろん、健康でなくなる日はいつか来るのだから、 そのことを忘れていいわけではないのだが。 ペットは別れの日のことまで考えて飼えと言うが、結婚も変わるまい。 どちらが先かはわからんが、お互いが自分が後まで残ろうと思ってしっかり生きるのが いいと思う。
． 13章見直し。とか言ってる間にまた鋭いツッコミが！ なんでこんなの気づかなかったんだよ自分！編集さんもな！
． 初版はバグまみれなんだよな。今回は前回よりもはるかに厳しいチェック体制を 敷いているが、結局は取り切れないんだろう。 商売でやるなら、下手に開発でバグをゼロにしようとがんばるよりも、 オープンベータで見つける方が効率はいい。 しかしそれは見方によっては客をバカにしている。 そして、ベータの次があるかどうかはわからないのである。 要するに、一度も増刷しないまま終わる可能性はそう低くないということだ。 大半の本は初版で終わると聞くからな...自分がその大半に入らないと 自惚れるにはかなりのエネルギーがいる。
． これそのうち読もう。 しかしすげえな。それぞれのCPUでどうか調べるとか並大抵の労力じゃないぞ。 なお、私はこれを読んでも、特定のCPUでだけ効くような最適化はしないと思う。
． 加算がxorと同じ速度というのがどうにも解せなかったが、 素敵な工夫で桁数の対数時間まで減らせることを知って、 今のトランジスタ数ならそのくらいのコストは全然問題じゃないのか、と理解した。 でもZ80の時点ですでに加算とxorの時間は同じだったらしく、 加算のトランジスタ数が問題になる時代なんて 本当に昔のことなんだろう。
． というわけで、桁がかぶらない2数を足す場合にorにしても、 わかりにくいだけで何もいいことはないということか。 もっとも、orやxorがandより遅いCPUがあるとも思えないし、 コンパイラに対して「こいつら桁混ざりませんよ」と教えることで 何か最適化をかけてくれる可能性はある。 実際にあるかどうかは知らんが。
． 桁がかぶらなかったらorでもxorでも足し算になるんだよな。当然だが。 なんというか、xorの影の薄さは良くない。 これはもっと積極的に使うべきだ。andとorばっかり使ってると、 xorで簡単に書けるケースを見落とすことになる。 最初はandとorでいいと思うが、ある程度慣れてきたらxorも 道具箱に入れておいた方がいい。しかし、 「じゃあ日常何に使うわけ？」と言われると浮かばないのも事実。 if文の中でxorが出てくるケースがないとダメだ。 整数演算に使うのは玄人に決まっているわけで。
． A xor B = (A or B) and (not (A and B))。「AかBの少なくとも片方は正しい時で、 ただしAもBが両方正しい時以外」。やっぱりあんまりないな。 それにxorは3項以上に増やせない。3つ以上あって「どれか一つだけ」、というのは 2を法とする演算におけるxorとはすでに違う。 「奇数個1なら1」がxorだからな。andもorもN項に自然に拡張できるが、 xorはできない。これは重大すぎる違いで、つまりダメだ。 やっぱりマイナー機能だなこれは。玄人しか使わない。
． 14章まで一応見直し終わり。12章やってた時眠かったので、 明日もう一回。でも一応終わりは終わり。 また指摘があれば対応しよう。 もし数日の間に終了とならなければ、また最初から読み直そう。 社内チェックが予想外にかかるとかいう展開もありうるからな。 なんにせよ、明日はmalloc本11章。評価の問題。 ここに一番興味があるわけで、気合を入れねば。 ここが片づけば、あとは個別の知識にすぎない。 結局何を作るにしても、評価を作るところが肝なのだ。 人間の組織もな。児童館に足りないのはそこだし、 たぶん公立の学校にも言えることだろう。 オタマをそういう所に行かせるのは忍びないが、 私立の小学校に電車に乗せて通わせることがいいとも思えん。 歩いて行ける場所にあるならアリだが。
． これはどういうネタだ？。 しかし、こういう考えの人間が政治家になったからといって、 それで何ができるかと考えれば、まあ無理だ。 これに過剰に反応する必要はないんだろう。 そもそも誰の発言かもわからんし。 でも政府のサイトにこれが置いてあるのは嫌だな。2chとか飲み屋の雑談くらいに しておいてほしい。
． 昔の文化は、昔の世界でしか存続できない。 なんだかんだ言ったところで、 能も歌舞伎も落語も消える方向にしか行かないように見える。 保存しようと努力している段階で、もうそれは死んでいる。 死体をドライアイスで冷やすのと大差ない。 人の欲望がそれを求めないのであれば、消えるしかない。 社会は欲望で動くのだから。
． 欲望に対抗できるのは別の欲望だけだ。 できることがあるとすれば、 より周りの人にとっても都合のいい欲望を持つように仕向けることくらいだろう。 社会に貢献するとうれしい、とか、物を作るのがうれしい、とか、 そういう欲望を持つように仕向ける努力はいくらしてもいい。 しかしそれはあくまで欲望であって、何かを禁止したり、制限したり、 強制したりして達成するものではない。 オタマ見てりゃわかるが、やるなと言っても無駄なんだよ。 やってほしくないことがある時の基本方針は、 こっちにとって都合のいい別のやりたくなることを提示することだ。 緊急にやむをえないケースなどでは強制や禁止もあるが、 避けられる限りは避けないといけない。 でないと本当に必要な強制や禁止の効力が落ちる。
． 萩中集会所のキッズルームにあるぬいぐるみの腕がもげていたので、 針と糸を持っていってくっつけてきた。 しかし難しい。ひつじこが動けるようになったら後で改めて直してもらおう。 今は仮だ。明日は破けた本を直すか。あれもかなりひどい。
． ナッツ1万円、冷凍フルーツ1万円、チーズ1万円、肉1万円を通販。総重量22kg。 ミートガイは送料無料ラインが2.5万なのだが、 今はまだ気にしない。 そのうち肉を10kgとか買うようになるかもしれん。
． ひつじこが牛肉を受けつけない。なので豚スネ肉でシチューを作ることにした。 豚スネ肉なんてスーパーじゃ買えないから通販するしかない。
． 数学ガールを読み始めた。5冊借りてきたが、予想外にぶ厚くて、 とても2週間で読めそうにない。
． とりあえずこの人は頭がいい人だ。 説明は良質だが、頭がいい人の説明の仕方なので、たぶんどこかで私は嫌になる。 私は何らかの必要性があって数学を使うのであって、 数学をおもちゃにするという感性はない。
． 生まれる前後、会社をハデに休むことになる。 テトリス本の作業は終わっていてほしいが、まだわからない。 そうなると、家でも作業できないと話にならないということになるし、 テトリス本が終わっていてもやはり家で作業できないとマズい。
． 家で作業するために必要なのは、最低限PCだ。 しかし、床にねそべってやる場合はそれほどの時間はやれない。 また、X201sは画面が狭いので作業効率は悪い。 msysのウィンドウ3個と、gvim4個と、PDF見開きと、ブラウザ、 みたいな状況なわけで、とても1440x900では足りない。
． 学生の時の作業環境をギリギリとするならば、 座椅子、低いテーブル、モニタ、キーボード、ということになる。 低いテーブルとモニタがない。テーブルが全くないわけではないが、 今あるのは食卓用だからこれは動かしたくない。 あとはモニタだ。家で本気で作業するなら2560x1440にすべきだが、 そんなもんどこに置くんだよという話になる。
． モニタの類はいくら技術が進んでも安定性と耐久性の問題があって 一定以上は重くなる。是非とも20インチくらいで2560x1440まで解像度を上げてくれ。 なんで需要ないのかなあ。