時代は大画面ハイビジョンだそうですが、 うちなんてアンテナ繋がってないから、ノービジョンです。 小画面ノービジョン。 ロービジョンですらないというこの恐怖の事実。
引続き、 ツール ド スイスを録画してもらった分をみています。 これはなかなかこぢんまりとまとまった、良い試合ですね。 それに展開も早い。 なんせ国土の関係上、山しかない。
Debian で大規模なアップグレードがあったようで、 自宅のパソで デフォルトの xsession が上がらなくなり、ログインできなくなってしまった。 ログをみると、 theme が無いからウィンドマネージャが起動できないようだ。 アップグレードの際に theme が削除されてしまい、戻っていなかったので、 手で戻す。
しかし、まだ動かない。 ログをみると uim の gtk2.0 どうのこうの というものが無くて、 エラーになっているようだ。 これもアップグレードの際に削除されていた。 こいつは依存関係上、戻せない。 無理に戻したが、起動しなかった。 uim-gtk2.0 のソースとってきて自分で今の版に合わせた パケジを作ればいいのだが、 それはそれでたくさんの開発関連ものをとって来なければならず、 大変だ。
xsession はシェルスクリプトみたいだから 最悪、問題になっている箇所をコメントにすればいいのかもしれない。 そして、im には別のものを使えばいいだろう。たぶん。 しかし、しょうがないので今んところは twm で使っている。 twm ですよ。 時計の針は戻らないといいますが、 15年くらい戻った感じです。
今日は家庭の事情で堺にでかけた。
そして堺でイタリヤ料理食った。 まぁまぁだった。 ただし、水がまずかった。 水がまずいところは、水道の水をそのまま出さないでほしい。 それとも、そこで暮らしているとあれが普通で特に何も感じなく なってしまうのだろうか。
帰りは難波周辺を散歩してから帰宅。 大阪は東京同様に、暑くて空気も臭かった。 どうも生駒山が、あれを遮断してくれているようである。
今朝は、窓から見えるところに、 ウグイスの巣立ち雛が群れでやってきた。 ちょっと尻尾がボサボサで、短く、 ウグイスにしてはずいぶん警戒がゆるい。 ちょど小笠原のハシナガウグイスみたいな感じだ。
仕草行動は、基本的にウグイスそのもの。 ちょっと翼を下げてバタつかせながら、低い姿勢で 「ちゃちゃちゃちゃ」といいつつ素早く枝渡っている。 その群れには他に、メジロとコゲラも居た。
息切れしてきた。 ものすごい肩コリで、右目がよく見えない。 ちょっとやりすぎたか。 分散処理を考え、今日は午前中で、 描画データをソケットで取得してキューイングするサーバと、 そのサーバにデータを突っ込むクライアントとして使える、 メソッドをこしらえた。 描画クライアントが、これからデータを貰って、 画像を生成する。 描画クライアントは午後 OpenGL で作った。 計算の進捗によって画像がアップデートされたものを、 マウスでグリグリと回せるので、なかなか楽しい。
高級言語で書いた、 ある処理をCに引っ越した。 ちゃんと動くまで、まる一日かかった。
すると 72329.6 倍速くなった。 ちょっと桁が読みにくいので日本語表記すると 7万2千倍である。 どんなやねん。 7万2千分の一の処理速度って、 それ、止まってるのと同じでんがな。 これだけ速くなると、一日かけたかいがあったといえよう。 gcc のフラグは -g のみなので、 公開時はもっと差がつくだろう。
問題はどうしてそんなに差がついたのか、というところだが。
なにか、もののグループがあります。 何でも構いません。 そのメンバ二つに対して、ある操作を行うと、別のものができる、 そういう操作があったとします。 たとえば、文字列のグループがあって、 操作がその文字列の連結であったり、 数値のグループで、操作は足し算だったり、そんな感じ。
操作した結果が、またそのグループのメンバになるとき、 そのグループはその操作に対して「閉じている」といいます。 ちなみに、その操作の順番を変えても結果が同じ場合は、 その操作とグループの組を「半群」といい、これに単位元と逆元が追加されると 代数でおなじみの「群」です。 文字列と連結操作の場合は操作の順番で結果が違うので、半群になりませんが、 自然数と足し算は半群です。 操作の順番を変えても結果が変わらない事を、 数学っぽく言うと「結合法則」といいます。 教科書にはこんな風に書いてあったのではないでしょうか。
(a * b) * c = a * (b * c)
この式は、二つの操作のうちどっちを先にやっても同じって意味です。 だったらそう書けよ、もったいぶって数式使いやがって、 わかんねぇよ。って感じですが、 たまには、そういう深い知恵がたった一行で表現できる数式の偉大さにも、 敬意を払っていただきたい。
ちなみに、数式の難しさは、一行に情報が濃縮されている事以外に、 解釈の曖昧さにもあります。 えー？数式の意味が曖昧だって？！そんな馬鹿な！と思うでしょう。 つまりこの数式は命題なのか、それとも、右辺のものを左辺に代入しているのか、 命題だとすると、仮定なのか結論なのか、 ぱっと見ただけでは判らんのです。 これは、話しの展開から読みとるしかない。 つまり数式を計算機に載せるためには、乗り越えねばならない壁が いくつもあるという事なのです。 数学の研究はコンピュータに任せる事はできず、 人間が自分の知能を使ってやらねばならないゆえんでもあります。 高校のときに偏差値が70くらいあったような奴が、 大学のショボい数式処理の課題で何日も徹夜する事情はこのあたりにあります。
ちなみに多くのプログラミング言語では、 代入操作と、「等しい」という命題は、違う表記になっており、 曖昧さを排除した記述ができます。 LISP 系なら代入は set とか define で、等しいは equal とか eq です。
さて、ここから先は私が考えた料理の構造理論です。
混ぜるという操作は、食品に関して閉じています。 また、順番を変えてもおおむね結果は変わりませんから、 半群です。 つまり、基本的に料理に失敗はありえません。 何をどう混ぜても、たべものが出来上がる事には変わり無いからです。 これは非常に重要な事実なので、 ここでこの命題に固有名をつけ、「食品半群定理」とします。
食品は混ぜる操作について半群ですが、 おいしいものはちがいます。 おいしいものを二つ混ぜても、おいしいものになるとは限らないからです。 ここに、料理の奥深さが存在します。
食品の種類に対して、混ぜる組合せの数は、 爆発的な量となり、しかもこれを効果的に縮約する手続きは存在しません。 具体的な証明は読者に委ねますが、クラスNPに属する問題は、 うまい料理のレシピを作る手続きに還元可能です。 しかし、言うまでもありませんが、 できあがりがおいしいかどうか、検証するのに必要な手間は 一回の食事で十分です。
つまり美味の探求はNP完全というわけです。 とりあえず食えるものは誰でも作れますが、 うまいものを実用上十分な時間で作れる事が、 職業として成立する理由がこれです。
久々に恭仁大橋にヤマセミでも見に行くか、ってことで、 台風もいっちゃった事だし、88を持ってでかけてみた。
ものすごい濁流で、突風も吹き荒れており、 そもそもあんまり鳥が居なかった。