2011年11月

タイトル「魔女の宅急便のキキについて」

本文「魔女の宅急便のキキは自分の事しか考えてない」

……

だから何なんだか．

なんとなくトラックボールを導入した．Logicool の M570．Unifying レシーバ対応なのでキーボードと一緒にレシーバ１つで済むのが有難いかも．

とりあえず，左クリックをしようと思ったときにボールを押し込む動作をしてしまう癖があるらしい事が判明した．なぜだらう？　親指が痛い……

Type class で可換半郡を次のように書いていた．

class CommutativeMonoid a where
    oplus :: a -> a -> a,  -- commutative, associative
    identity::a           -- the identity of oplus
data Bag a = Bag [a] deriving (Show,Ord,Read)
instance CommutativeMonoid (Bag a) where
  oplus (Bag a) (Bag b) = Bag (a ++ b)
  identity = Bag []

んで，type class だと不都合が生じたのでレコードで演算をまとめて持ち運ぶようにしたのだけど，定義部分に限っては RecordWildCards を使うとほとんど同じように書ける．演算の集合を定義するという点では type class でもレコードでも手間は大して変わらないっぽいねと． 楽だし簡潔でいい．

data CommutativeMonoid a = CommutativeMonoid {
    oplus :: a -> a -> a,  -- commutative, associative
    identity::a           -- the identity of oplus
    }
data Bag a = Bag [a] deriving (Show,Ord,Read)
bagMonoid = CommutativeMonoid { .. } where   
  oplus (Bag a) (Bag b) = Bag (a ++ b)
  identity = Bag []

インスタンス宣言に同じクラスの別のインスタンスを使う，例えば

instance (CommutativeMonoid a, Ord c) => CommutativeMonoid (Map c a) where
  oplus x y = unionWith oplus x y
  identity = empty

とかも

mapMonoid m = CommutativeMonoid { .. }  where
  oplus x y = let CommutativeMonoid {..} = m in unionWith oplus x y
  identity = empty

と書けばほとんど同じ雰囲気かね．let を内側で使ってあげるのが大事．下のようにやると定義の本体の oplus が新しく定義される oplus になっちゃうのでエラーを食らう．

mapMonoid (CommutativeMonoid {..}) = CommutativeMonoid { .. }  where
  oplus x y = unionWith oplus x y
  identity = empty

まだまだ黄色一色にはなっていないけれど生協に行くついでに Pentax Q で撮ってきた．たまには使わんともったいない．

ジャケットのポケットに入れておくにはちょっと重いなぁ……　やっぱカラビナで腰にくくりつけておくとかが良いのかもしれない．

作業に集中していたらいつの間にか終電を逃していた．どうしませう？

お家まで歩いて帰っても１時間半だし考え事をしながら帰るか……　ゴミ出したいし．

追記：ぴったり１時間半で家についた．曇っているせいか大分暑かった印象．

問題：「補足事項」および「Re:補足事項」というタイトルで次の５通のメールが迷惑メールフォルダに入っていた．どのように対処すべきか答えよ．

まぁややこしいかもしれないですが、連絡先を集めると言い放った時点で、○○さんの連絡先が集まってる事を示唆しています。あえて取り除く事もないですが、回数というのはそういう事も含みます。もしかするとわかりにくいかもしれませんが

転送するにとどめる、といっていたので、転送をするんだったら、直接的に得られるのか、というのが質問で、悪意があるように思われるのは心外です。

つまり、巻き込まれては迷惑だろうから、ルートとして、外そうと思っただけです。中間的な立場というのもかえって不安定かと思ったので

つまり実際的には転送先のメールアドレスに送る事が主の目的の時に、送り先がないために、大学のメールアドレスに対して送る事があった際に、文面としては、転送先のメールアドレス上でどのように見えるのか、という事を主に思うので、かえって、大学のメールアドレスに対して送る文面としては奇妙になるかもしれず、そういった事態を未然に防ぐというのが主な目的です。

転送される状態にある状態で、メールアドレスを直接的に求める意義としては以上になります。

模範解答：スルー．

今ひとつ黄色くなってないなぁ，大学のイチョウは．たぶん外苑もまだよね……　昭和記念公園はいつの間にか終わりだったしタイミング逃したなぁ．

長瀞のライトアップは今日までか……

問題：次のメールを読み，送信主の主張をわかりやすくまとめよ．

タイトル「電子メールに関するポリシーについてのコメント・苦言など」

一度、話しかけられた事のある相手に対して、面識に基づくコミュニケーションを要求する事は、面識があるかどうかについて深く求める事は関係を求められる事になり、関係を求められる事は責任を求められる事になるから、翻って、面識を求める事は責任を求める事につながる以上は、強すぎる要求である事は確かですが、電子メールの扱いに関してうまく関心を共有できなかったのは、一方で、Ｋさんが、電子メールアドレスについて、emokenさんが、比較的寛容な、ポリシーを示していて、その内容と、一貫しなかったから、それに対する、首尾一貫性を説明する補足的電子メールの、追加を、待っていたからです。〇〇さんについて、アドレスを尋ねたのは、実際知ろうとしていたのもそうですが、一方で、そうでない場合には、そういったポリシーを、説明してもらえるのかと、思っていました。コメント回数で言えば、わたしが〇〇さんに対してコメントした回数は、emokenさんが訊ねた回数を超えていないと思います。気にかかるのでなければ、公共の場での発言はお控えになった方がよいと思います。もしそういった言動が見られなければ、わたしも、そういった電子メールを送らずに済んだ訳ですから、話をややこしくする必要はないと思います。

よく分からないのでエキサイト翻訳で英語にしてみた．ますます訳分からんのだけどとりあえず全部を訳してしまう翻訳機すげぇ．［ ］とか / とかは何処から湧いてきたんだ？

Requiring the communication based on acquaintance to the partner who had addressed once, As for it being too strong a demand, it is clear that asking deeply about whether it is acquainted can ask for a relation, and it can ask for a relation, if it leads to asking for acquaintance searching for responsibility on the other hand at all, since responsibility can be searched for, but. One side was not able to share concern well about the treatment of an E-mail, and Mr. K, It is because it was waiting for the addition of the additional E-mail [ as opposed to / since the policy in which Mr. emoken is comparatively tolerant about an e-mail address is shown and the contents did not cohere / it ] explaining coherence. I thought whether, about Mr. 00, one side asked the address, and although actually trying to get to know is also so, when that is not right, it would have such policies explained. I think that the number of times that I commented to Mr. 00 will not be over the number of times that Mr. emoken asked if it says by the number of times of a comment. If not worrisome, I will consider the utterance in a public place as it is better to cut down. If such speech and conduct are not seen, I also think that I do not have to talk puzzling since it is a reason for not having sent such E-mails.

出かけたけど寒すぎてモチベーションが下がったので途中で引き返してきた．満月じゃないし．

閑話休題．

去年普通二輪の免許を取った教習所から大型教習の割引のご案内が来た．夏に比べれば空いているのかね．うーん，９万弱か……　わざとコケてみるとかやってみたい気もするので悩ましい．

succinct data structure というものを初めて知った．使用する空間量が情報理論的下限（つまりはエントロピー？）に近く且つ幾つかのクエリ処理が高速に行えるデータ構造であると．分類としては，適当なデータを表現するビット量の情報理論的下限をZとしてやると，Z + O(1) ビットで表現できる構造は implicit data structure で，Z + o(Z) ビットで表現できる（つまり係数も一致して漸近的に下限に至る）なら succinct で，O(Z) ビットで表現できる（つまり下限の定数倍程度）なら compact というと．

例としては，{0, 1, ..., n-1} の部分集合の表現（つまりは長さ n のビットベクタ）に対して rank と select というクエリをO(1)で行うギミックを付けた構造があると．rank(x) は x ビット目までの 1（ないし 0）の数を返すクエリで，select (y) は rank(x) = y なる最小の x を返すクエリ．rank を O(1) で計算するために o(n) なサイズのテーブル３つをうまく用意してやると．大きな１つのテーブルですべての答えを用意しようとすると n lg n になってしまう（引数の数がn通りでそれぞれの答えが lg n だから）ので，とりあえず (lg n)^2 毎に区切ったブロックの先頭だけの rank テーブルを作って（これで n / ((lg n)^2) * lg n = n / lg n ビットのテーブル），次に残りのブロック内の先頭からの rank の差分をどうにかしましょうとか考えるのね．残りの部分をどうするかだけど，とりあえず愚直に全部のインデックスに対してブロック先頭からの差分を保持すると O(n) 以上かかるのでダメで，一方，存在しうるブロックの全パタンを網羅しておこうとしてもブロックサイズが大きすぎてこちらも O(n) 以上かかる．しょうが無いのでもう一段ブロック化を導入してあげて，この小ブロックのサイズを lg n / 2 にしてあげると，この小ブロックに関して全パタン網羅しても o(n) で済むし小ブロックの先頭の rank （の大ブロックの先頭からの rank の差分）を全部保持しても o(n) で済みますよと．これにて一件落着．クエリ時には３つのテーブルを引いて足しあわせりゃいい．select はめんどいらしい．

まあ，再帰の段数を固定して適度なサイズ以下の問題は定数で答えが返るという状態を作っておけということなのか？　計算の一部を適当なサイズのデータに変えて取っておこうよというかよく使う部分計算はテーブルに取っておこうよというか．

それはさておき，rank/select で具体的に何が出来るのかがよく分からん．あとは一般にどんなクエリなら効率をデータ構造に押し付けられるんだ？　どの程度自動化できるんだ？　よく分からん（論文読め）．

変な姿勢でディスプレイ眺めてたせいなのか……　とりあえず行動不能．

働けるとこに感謝して一日中働く日だと教えられた気がする．

例え元のプログラムが正しかろうとコンパイラが間違っていれば出てくるものもやっぱ間違っているわけで……　例えば，車とかに入りまくっているチップの設計に使われるようなHDLのコンパイラはどの程度正しいと証明されているのだろうか？　コンパイラのバグ踏んだー！とか言って事故るのはゴメンなのだけど．

拡張が多すぎて探すのも面倒．

全部有効にして欲しい気もするけれどそれはそれで問題を発生させるんだよね……　こんな言語設計でいいのか？

レジで合計439円と出た　→　財布には992円（100円玉9枚，10円玉9枚，1円玉2枚）が入っていた　→　440円を出そうとしたが硬貨を1枚を取り違えて 530円を置いた　→　10円を置いた　→　この時点でレジのババァ様に硬貨が回収されてレジに入れられる　→　返って来たのは1円玉1枚と「439円をぴったり支払いお釣りがなかった」というレシートのみ

……

とりあえず100円盗られた形なわけだが，自分の記憶以外に証拠がない状況になってしまってから文句を言っても始まらないし後ろも列ができていたのでそのまま退散．まあ，ババァ様も合計金額が539円だと勘違いしたのかも知れないし受取額をレジ入力するのが面倒だったから正しくないレシートを発行したのかも知れない．硬貨を数えた上でレジの金額表示をちらっと確認はしてたけど．

教訓：まぎらわしい金額で支払いをしないこと．

最近，SSDの入っているノートPCでしか生活していなかったせいで，ファイル入出力中に加速度を加えるとかの行動を平気でするようになってしまった．HDD 入りのノートPCだと気をつけていないと壊してしまいそうで怖い．

あとはHDDだと起動時間遅すぎてイライラするので寿命が縮みそうで怖いとか．

全然知らなんだった．緑色とか赤色とか欲しいなぁ．でも当然のごとく在庫なし……

10年以上前に買ったヤツが（酷使により外装がボロボロだけど）平気で使えてしまう程の耐久度だし，そもそも使える限りは別のシャープペンに変える気も起こらない使い心地だし，文房具屋とか行ってもシャープペンシルを売っているコーナーには全然行かなかったので気づかんかった．とても残念．とはいえ，買っても飾っておくだけになりそうだから手に入れるだけ無駄なのだけど．

閑話休題．

ボールペンはシグノの普通のしか使ってないから限定版とかなさそうだなぁ．黒色ボールペンの限定カラーとか面白い気もするけれど．

multi parameter な type class をコンテキストに持つ関数を書いたのだけど，その type class の引数の一部はその関数の型に陽には現れずしかし functional dependencies で決定もできない，とかいうアホな状況で……　型が曖昧だとか推論できないだとか色々と文句を言われ続ける始末．とりあえず適当に unification しちゃってよと言いたいのだけどどう伝えたらいいのか分からない．

それはいいとして，もの凄くシステマティックでオートマティックにできるはずなのだけど今ひとつ綺麗に自動化できないのは悲しい．

忘年会の下見に行って酔っ払いモード．まさかお一人様8k円になるとは思わんかった．そしてドイツワインはマイナーなのか？ 全然店に無かった気がする．

とりあえず，酒は料理と共にというより単体で飲むものだという思考なので料理に合わせた酒選びとかは無理．酒のためにつまみを選ぶなら理解できる．ぶっちゃけ料理に合わせた酒とか最初から料理に入れときゃいいと思う．

それにしても店混んでたなぁ．

超寝不足＆風邪気味で飲むとかバカすぎる．

更には「インターネットをしている時間」という言葉の意味が全然分からない．

「インターネットで通信をしている時間」と解釈すると，ネット配信の動画をブラウザ上で見ている時間とローカルに保存しておいたその動画を見ている時間とが別物になる．これはなんとなくおかしい気がする．ついでに，ブラウザでリアルタイムにクロールするのとクローラに集めさせておいたのをオフラインで見るのとが違うってのもおかしいし．

うーん……　インターネットを介して得られた情報を頭で処理している時間のことなのか？　でも，例えばインターネットから手に入れた「インターネットする」という言葉の意味を考えている今のこの時間はインターネットしてるとは言えない気がするしなぁ……　微妙にこれも違うのか．

とりあえず全くよく分からん．

閑話休題．

http://www.kurihama-alcoholism-center.jp/tiar/ の「インターネット依存度テスト」に対して，その質問文のなかの「インターネット」を「〇〇」に置き換えてみたのが下のテーブル．設問７以外は「〇〇依存度テスト」に使える汎用テンプレートな気がする．「依存度テストジェネレータ」とか作れるんじゃなかろうか？　「エロゲ」とか入れてみると面白い．

gcc は

sudo apt-get install g++ automake libtool g++-multilib gcc-multilib libgmp-dev libmpfr-dev libmpc-dev bison flex zlib1g-dev libc-dev

くらいやっておいたうえで

../gcc-svn/configure -v --enable-languages=c,c++,go --prefix=/usr --program-suffix=-4.7.X --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7.X --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

程度で configure して export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu をしておくと make -j8 でコンパイル成功した．この export をしてない状況だと /usr/bin/ld: cannot open crt1.o: No such file or directory で怒られてコンパイル失敗する．

とりあえず gcc のコンパイルは速くていい．

ghc 7.2.2 もコンパイル．

sudo apt-get install libncurses5-dev libgmp3-dev autoconf automake libtool gcc make perl python ghc6 happy alex darcs libffi-dev docbook-utils docbook-xsl

程度のことをしておけば configure/make/make install で成功した．

とりあえず ghc のコンパイルは時間かかりすぎる……　（gccと比べて）

ついでに，sun の JDK を PPA で入れた．パッケージ提供者に感謝．

sudo add-apt-repository ppa:ferramroberto/java
sudo apt-get update
sudo apt-get install sun-java6-jdk

作業用マシンを 10.04 LTS から 11.10 に移行することにした．クリーンインストールで．

とりあえず，Unity になれない．Mac OS と同じくグローバルメニューになっている点が非常に慣れない……　とも思ったのだけど，よく考えるとメニューを直接叩く機会はあんまりないので問題ないかなという気がしてきた．まあ，このままつきすすもう．

Twinview で両画面にグローバルメニューが分割して現れるのは仕様なのか？　同じインジケータが両画面に現れていて無駄なのだけど．

とりあえず TeX まわりの環境が一発で整ったのはありがたい．

バージョン上げたらコンパイラが賢くなったので誤魔化しを見抜かれた．これまでは見逃してたくせにっ！

あー，めんどくせぇ．

全種類また試したいなぁとか思ってネスプレッソブティックに行って「16種類全部1本ずつください」してきた．おまけでカプセルボックス付き．

とりあえず，やっぱりロサバヤでいいやという結論．

結構悩んだ．そもそも嫌いな物を思いつくとか難しい気がするのだけど，悩んだ結果 perl が一番嫌いなんじゃないかと．「使いたくない＝嫌い」という解釈で．任意の目的に対して積極的に使用を回避したくなるのは perl しか思いつかん．

以下，答えを探している最中の思考．

sed：ロマン．頭の体操．やればなんでもできる便利な子．ワンライナーに必須．

C++：速い．演算子オーバーロードは素晴らしい．template で頑張るととても楽しい．

Haskell：遅延評価バンザイ．型推論バンザイ．高階関数バンザイ．参照透明バンザイ．

Java：どこでも動く．GCは素晴らしい．遅くない．リフレクションで頑張るととても楽しい．

awk：数値を使うワンライナーに便利．

bash：言語かこれ？　バッチ処理には十分．

Python：キレイなスクリプト言語．

アセンブリ言語：速度のために必須．インラインで使うけど．

Lisp：なんでもありの素晴らしき自由．mix．eval/apply．

FORTRAN：良くも悪くも数値計算に必要十分．

C言語：真のC言語は安全．union は素晴らしい．#define で頑張ると楽しい．

OCaml：高階関数とか型推論とか欲しいけと遅延評価とか要らないし汚いことしたい時用．

php：web に関連するものならこれで．HTML との親和性が一番良いんじゃないかなと．

JavaScript：ブラウザで動くLispだよね．

閑話休題．

これを次の自己紹介の項目に入れよう．

テンプレートは透ける．変換したらこーなった．

閑話休題．

理論の実証のために，いくつものデータ型に対して同じようなクラスやインスタンスやゴニョゴニョを沢山書く必要があった．が，それらはデータ型の定義さえ手に入れば機械的に作れるものなので，二個目の型に取りかかったあたりで面倒＆馬鹿らしくなってきた．

ということで，定義を生成するプログラムを Template Haskell を使って書きだしたのだけど……　こっちはこっちでめんどくさい．わかりやすいドキュメントがあるのか無いのか．つか，データ型を渡して型クラスとかインスタンスとかを生成させるという使い方（つまりは deriving のようなことをさせるの）は正しいのかどうかよく分からん．

とりあえず別の手法にいったほうが良いかも知れないなぁ．

The Cocke–Younger–Kasami (CYK) algorithm (alternatively called CKY)

とりあえず CMYK と同じ順番でいいのね．

どうでもいいけど Haskell で書くとメンドイ．

センターキューブのキャップが外れて正しい位置が分からなくなったので，バラして組み直した．かなりシステマティックな構造をしているので組み上げも比較的簡単．最後にハメるパーツをどれにするかで難易度が変わりそうだけど，センターから桂馬飛びの位置にあるヤツが楽かもしれない．全体を歪ませてから穴に向けて押し込むと結構簡単にはまってくれる．

時々「配列とポインタは同一視出来る」という説明を聞くのだけど，これって良い説明なのか悪い説明なのかよく分からない．特に，多次元の配列の解説と同時にこの説明があるのはどうなのかなぁとか疑問に思う．１次元の配列を扱う範囲に置いては特に文句はないのだけど．

多次元配列の解説においては，「多次元配列＝ポインタのポインタ」という説明になる．仮に float c[10][20] という配列と float **d というポインタがあった場合，この説明では c = d とした以降は c と d がプログラム中で同一に扱えることになる．が，実際には c と d はインクリメントとかデリファレンスの挙動とかが違い，同一視すると痛い目を見る．正しくは，c は 20要素の float 配列のポインタ(float (*)[20]と書くのか？)と同一視出来る程度であって float ** とは別物と．

ということで，下のプログラムを動かすと c と d が別物だとよく分かる．c と e は同じ挙動．

main(){
  float c[10][20], **d, (*e)[20];
  d = c;
  e = c;
  printf("%p %p %p\n", c, d, e);
  printf("%p %p %p\n", c+1, d+1, e+1);
  printf("%d %d %d\n", c == *c, d==*d, e==*e);
}

結果は以下の通り．

0x7fff7bca9320 0x7fff7bca9320 0x7fff7bca9320
0x7fff7bca9370 0x7fff7bca9328 0x7fff7bca9370
1 0 1

ホテルの予約を FAX で申し込みしなければならないとか面倒すぎる．なぜにインターネットで処理できないのか？

というか，送信だけならいいけど「予約の結果を送るから受信できるようにしておいてね」とか面倒すぎる．

シチューがうめぇ．

突然食べたくなったので生姜と大蒜と葱のクリームシチューを作った．風邪予防とも言う．ここんとこ寒かったり夜明け前に長距離バイクで走ったり標高の高いところに行ったりカメラ構えてじっとしてたりしたので．

さらに粗挽き黒胡椒を振ると能力アップ！

箕輪町に1万本のもみじが植えられた「もみじ湖」があるらしいとの情報を見つけたので行ってみた．

もみじ湖一番奥の景勝地の坂．まだ緑が残っていて全体的に色色々．黄～赤＋落ち葉で一面暖色に揃ってくれたほうが紅葉っぽいのだけど今年はばらばらなので無理そう？

別カメラの映像＠景勝地の坂．

一番奥から少し手前の駐車場付近．景勝地のはじまりくらい．大分赤い．曇りの日の８時半だけど人出はちらほら．小田代ヶ原と違って朝は混んでない．

ダム下流のひろばを上から．色づいてるけどやっぱり進行がばらばらな感じ．

もみじ湖．予想より大きかった．

閑話休題．

行きは，ついでなので国道20号線をその起点（日本橋）から終点（塩尻のR19とR153の交差点）まで走ってみた．R20終点からはR153を伊北IC直前まで南下してもみじ湖の西からr442で向かった．もみじ湖に行くだけなら諏訪からr50→有賀峠→r442で南下するのが近いのだけど，R20を走りきりたかったのでちょっと遠回りしてみたと（結果的にこの遠回りは幸いであった）．長い道のりは良いとして，面倒だったのは起点の日本橋をうまく通過すること．秋葉原から中央通りをそのまま行けばR17(R4)の起点でもある日本橋にはそのまま辿りつけるのに，なぜか１本隣の昭和通りからアプローチしようとして失敗しまくるとか．アホだ．

帰りは，もみじ湖から r442 を北上して諏訪ICへ向かった．Google map でルート検索しても高速を使わない条件下ではこちらのルートが出る．が，険道だった．路面はボコボコ，道路中央は石ゴロゴロ小石ジャラジャラ．道のすぐ横下はガードレールなしで沢．夜中にバイクで走ると軽く死ねる気がする．行きにこの道使わなくてよかった．

ついでに，昨晩初めて検問で止められた．なにやら都心部で一斉に飲酒の検問をやっていたらしい．「お帰りですか？」「お出かけです」とかいうアホな掛け合いをしつつ，引っかかるわけないのでそのまま終了．「都心抜けるときにもう一度止められるかも」とか言われたけどその後のR20では検問無かった．代わりに事故処理の渋滞には嵌ったけれど．とりあえず事故は無くなれ．渋滞は嫌いだ．

親切な Thunderbird は添付のテキストをメール本文の下にレンダリングしてくれる．まあ，何となく便利．

んで，とても大きなテキストファイルの添付されたメールが送られてきた．6MB超で24万行弱．

……メール開こうとしたら Thunderbird の反応が無くなった．とりあえず頑張れ Thunderbird！

閑話休題．

最近は数MBのPDF添付とか平気で送る習慣が広まっているし実際それで便利なのだけど，大きなテキストファイルをそのまま添付して送ると相手の迷惑になりかねないので気をつけることする．そもそもそのサイズのテキストを圧縮なしで送るとか通信路の無駄遣いなので圧縮も心がけることにする．

普段は草原らしいけど大雨が降ると水が溜まって湖になるらしい．4年ぶりだとか．

大量に生えている笹も水の中．

んで，以下湖の様子．早朝の霧を期待していたのだけど今日はダメだったというオチ．雨は降ったけど．

まず4時前．F2でISO800で4分露光．右の木が青いのはまわりにいた人の照明が当たったから．3時頃までは星も一応見えていたんだけどこのころ既に曇り．そして空の色が本当にこんな色だったのかは分からない．ヘッドライトなしでは山陰以外には何も見えないという暗さだったので．

そして5時半．F2でISO200で6分半露光．照明なしでも隣の三脚がうっすら見える程度に明るくなった頃．水面は穏やかだけど曇ってる．空の左が青く右が赤いけど本当にそうだったのかどうかよく分からず．

更にすすんで6時頃．F5.6でISO160で6秒露光．相変わらず曇り．でも大分明るい．色が変なのは色温度を変えたから．他にすることなし．

粘って7時．この頃にはカラマツの色もちゃんと写る状況．でも曇 orz

そして7時半．雨．何度か降られた．霧なし．残念．

帰り道の途中で．違和感ない．

ということで，霧は撮れなかった．残念．

今日の発見１：シャッター時間バルブにしておくとリモコンのシャッターボタン1回目で露光開始し2回目で終了する．本体のシャッターボタンだと押しっぱなしにしないといけないのでリモコンが便利．

今日の発見２：α900に付いてたリモコンでNEX5も動く．

今日の発見３：３時半でも既に先着が１名いた．４時前には５人以上に増えた．もっと早くに現地に到着すべし．というか人が来るともれなくヘッドライトの明かりがついてくるので露出が局所的におかしくなる．

閑話休題．

帰りに奧利根をまわってきたらダムより下の当たりは良い具合に黄葉してた．山の上の方は散ってたけど．

2011年11月02日なので，数字だけ取り出すと 20111102 で palindrome になっている．

んで，この話が出たときに近くにいた人間とこれがどれくらい珍しいことなのかを議論した：とりあえず存在したとしても１年に１日しか無い．年の1の位は0か1であるべきなので，10年に2回しか無い．というか，百の桁が0,1,2,3でないとダメなので25世紀から30世紀も存在しない．

まぁ，物凄く珍しい日であると．

詰め込み過ぎた．というか，一方だけ説明するだけでよかった気がする．デモが間に合わないから理論の紹介になったのが敗因．大本の原因は土日が潰れたことだけど．