熱ひいたかな?

昼食を簡単に済ませ、ぼけっとミヤネ屋を見ていたら熱のせいかだるくなってきたので、そのまま寝入る。
18:00頃起床。熱もひいたみたい。頬の熱っぽいのもとれたようだ。

冷たいお茶、熱いコーヒーどちらを飲んでも別にしみる気配はなさそう。

しばらくは左でものを噛むときはおそるおそるという感じになりそうだが、右の時も似たようなもんだったので1週間もすれば気にならなくなるだろう。

熱っぽい?

幸い、昨晩は鎮痛剤を飲むほどの痛みはなかったので、とりあえず安眠できた。

が、ちょっと微熱が出てるかも。左頬も腫れるほどではないけど、熱を持ってる感じだし。

今日はおとなしく読書でもしつつ寝てますか。

本まとめ買い

歯科の後で、痛みと鎮痛剤で微妙にふらふらしていたが、某所でもやしもん、もやしもん、とつぶやいていた人がいたお陰でもやしもんの新刊が出ていたことを思い出す。その足でふらふらしながら本屋へ。

お目当てのもやしもん(7)と文庫を久々に買い漁る。

・死者の短剣 惑わし(L.M.ビジョルド)
・プロバビリティ・スペース(ナンシー・クレス)
・天涯の砦(小川一水)
・太陽の中の太陽(カール・シュレイダー)
・消滅の光輪 上下(眉村卓)
・華氏451度(レイ・ブラッドベリ)
・くらやみの速さはどれくらい(エリザベス・ムーン)
・神曲奏界ポリフォニカ リベレーション・ブラック(大迫純一)
・神曲奏界ポリフォニカ クリムゾンS(2)(榊一郎)

最近、新刊のチェックをしてなかったのでビジョルドの新作が出ていたのに気が付いてなかった。
「くらやみの速さは~」は結構前から書評で評判になっていたので、逆にちょっと手をつけかねていたのだが訳者が小尾芙佐氏であることに気が付いて今更ながらに購入。

後は、ほとんどその場の勢いというか、判断が働いてないような気がしなくもない。

しばらく読書モードに入ろうかしらね。

痛っぁ~い

本日、予定通り左下親知らずの抜歯。
ま、確立までに5年10年かかるような再生技術のことなんか気にしちゃおれんということで。

手順は、右下のときとほぼ同じ。
手前の奥歯にひっかかっている部分にドリルで削って切れ目を入れて割る→やっとこ(らしきもの)で残りを一気に引き抜く→止血。

なんだが、残りを引き抜くところで今回はえらい難儀した。
前回はいつ抜かれたか分からないぐらいだったのに、今回は

1) やっとこで挟む→抜こうとするが抜けない。
2) やっとこで挟む→左右にぐりぐりねじる→ここがすげぇ痛い
3)1)に戻る

な感じで3回くらい繰り返してようやく抜けた。しかも今回はリアルに抜けた感触が実感できた(したくもなかったけど)。

抜くのに手間取った分前回よりも激しくスプラッタ状態だったようで、止血綿を3回も交換して長めに止血していた。
ついでに痛むのを見越して、帰る前に鎮痛剤まで飲ませられたし。

お陰で今のところ痛みはほとんどないが微妙にふらふらする。

今夜鎮痛剤が切れたら我慢できるんですかね。

FreeBSD 7.1R(amd64)インストール

ファイルサーバにしているPCの諸々のパッケージバイナリのバージョンがいい加減古くなってきたので、リーリス記念に7.1R(amd64)をインストール。

ただ、MLに流れている動作報告を眺めているといろいろと地雷臭がただよっているようなので、念の為システムディスクを余らせていた500GB HDに交換してクリーンインストールを敢行。

案の定、PCI-E Intel GbE NIC(em0で認識)がwatchdog timeoutを連発して、ネットワークが使い物にならない。幸い、オンボードNIC(nVidiaチップセット、nfe0で認識)の方は正常に動作しているので、こちらに切り替えて当座を凌ぐことに。emドライバの問題は既に報告済みらしいというか、いろいろクレームが上がっているっぽい。

とりあえず、NFS、Samba、X11、DLNA(mediatomb)サーバとしての動作には支障はないようだ。

ネットワーク系はrl/reドライバでもトラブっているようだし、MFCのタイミングが悪かったみたいね。
おまけにリリース直後にGnome 2.24.2がportsに取り込まれて、これまた(主にamd64で)問題になっているご様子で。

これは早期に7.1.1Rか7.2Rのリリースで挽回されないと7ブランチ自体がだめって言われそうだなぁ。

Haskell::GR-nの生成(その7′)

その7でGR-100までの生成を目指していたが、GR-85時点で67457.77秒かかるようになってしまったので、一旦中止。この調子では後2週間かけてもGR-100まで届きそうにない。

とりあえず現時点での測定結果。

g7.txt

GR-70あたりからの計算時間の増加量が尋常でないようだ。

OGR-nの探索(その7)で計算済みのOGR-nをテキストファイルに書き出すようにしたので、GR-nの生成でも計算に先立ってこれを読み込めば、低位のGR-nの生成のスピードアップが期待できる。
低位のGR-nの生成のスピードアップが図れれば、高位のGR-nについてもそれなりにスピードアップが可能かもしれない。

抜くべきか、抜かざるべきか

slashdot.jp の記事より

歯の再生技術、今後5~10年以内に確立するかも

再生技術の要となる幹細胞バンクとして、乳歯、親知らずが有力な候補になるかもとのことなんだそうな。

来週、残りの親知らずの抜歯の予約を入れている私はどうすればいいんでせうか。

もっとも、先に抜いた右下の親知らずの中心部分はしっかり虫歯状態になっていたので、残りを抜かずにほっておけば後年虫歯に苦しむはめにはなりそうなんですが。

地アナ放送延長?

Gigazineの記事から

地デジ普及の遅れを受けて、2011年7月24日以降もアナログ放送が受信可能に

一瞬タイトルだけ見てかくっと来たが、CATV加入世帯のみ対象なのね。
CATV局で受信した地デジ放送をヘッドエンドでアナログ波に変換して一緒に送信することで、地アナ受信期間を延長するということらしい。

この不況で地デジ対応機器の普及が予定よりも遅れているというのが言い分らしいが、そもそもスケジュールに無理があったんだからこの手の対応も織り込み済みにしておけよ。

で、今頃ヘッドエンド改修・リプレースのための補助金をばらまくための画策をしているんだから、場当たりすぎるのにもほどがある。

大体、CATV未加入世帯は切り捨てですか。
いっそ定額給付金でCATVに加入させますか?

筆まめ



親が今年から自分で年賀状を作成することにしたらしく、筆まめを購入。

リンクシミュレータ用に自分でも購入。
要は電話で使い方を聞かれたときに手元に同じソフトが動く環境がないとよう説明せんだけのことなんですが。

年賀状は書かない人なので本来この手のソフトには用の無い人種ではあるんだが、事務書類や申請書の類の送付の時の、封筒の宛名印刷に使えるのは便利かと思い直し購入に踏み切る。

住所録の管理から、差出/受け取りの履歴による宛先の仕分け、お任せデザイン/レイアウト、デジカメ写真の貼り込みなどなど、何から何まで面倒をみてくれる。果ては名刺/のし袋/賞状/CDラベルの作成までサポートしているんだとか(パッケージ裏面棒読み)。

まあ、メジャータイトルだけのことはあるんですかね。

自分用にはDVD版を購入したが、デザイン集/電話帳・会社住所録までインストールしたら、2時間以上かかった。データが大量にあるのはわかるんだがもうちょっと何とかならんか。

試しに封筒の宛名印刷をやってみたが、標準サイズの封筒だと特に悩むことなく言われる通りに操作すれば、印刷まで辿り着ける。プリンタによっては郵便番号の印刷位置を微調整する必要があるかもしれない。

Haskell::OGR-nの探索(その7)

ファイルI/Oの手習いとして、その6’のコードに計算したOGR-nの結果を一通りテキストファイルに書き出す機能を追加。さらに、2回目以降に実行した場合既に計算結果があれば、それを元にOGR-nのリストを作り、途中から計算を始めるようにした。

ogr7.hs

後、2分探索の部分もちょこっとだけ最適化。

ファイル出力の部分はある程度定石を覚えれば、それほど悩むことはない。
問題は、ファイル入力->オブジェクトの生成のようなパターン。

Haskellの遅延I/Oの元ではテキストファイルの入力処理は

do
  inh <- openFile 〜 ReadMode
  cs <- hGetContents inh

  ごにょごにょ

  hClose inh

のような感じで書くことができる。csにはオープンしたファイルの内容がString型として束縛される。一見、ファイルが全てメモリ上にロードされてしまうように見えるが、遅延I/Oのお陰で評価に必要な部分しか読み出されない。
で、ごにょごにょしている部分でcsにいろいろな関数を適用して、必要な計算を行う。
ところが、このごにょごにょの部分も普通は遅延評価されてしまうので、hCloseまでに正格評価を行わないと、必要な評価の前にファイルハンドルがクローズされてしまい、csには空のStringしか束縛されていないということが起こる。

ごにょごにょの部分で作るオブジェクトが単純な値やリストであれば、seqなどの正格評価を摘要するための演算子を用いればいいのだが、複雑な composite object になるとかなり厄介。
そういう用途に、Control.Parallel.Strategyモジュールがあるのだが、このあたりは正直まだ理解不能な領域だったり。

普通にテキストフィルター的な(ファイルのオープン/クローズを気にしなくてもいいような)処理を記述する場合は、遅延I/Oは直観的にコードを書き下せるのでとても便利なんだが。
このあたりの迂遠さというか、正格/非正格評価の区別をプログラマに要求するあたりが、関数型言語板なんかでのHaskell嫌いな人の攻撃材料になってるんだろうなぁと思ったり思わなかったり。

結局、

writeFile “/dev/null” $ show ほにゃらら

みたいに、オブジェクトを一旦プリンタブルな文字列に変換して、出力プリミティブを適用するという、かなり滅茶滅茶なやりかたでその場をしのいでいる。

実際のところの計算時間は、その6’のn=13の計算を一旦キャンセルして再度やり直し中。
n=12まで完了していて、

3:([0,1,3],[0,2,3])
0.000u 0.001s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
4:([0,1,4,6],[0,2,5,6])
0.000u 0.002s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
5:([0,1,4,9,11],[0,2,7,10,11])
5:([0,2,7,8,11],[0,3,4,9,11])
0.000u 0.002s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
6:([0,1,4,10,12,17],[0,5,7,13,16,17])
6:([0,1,4,10,15,17],[0,2,7,13,16,17])
6:([0,1,8,11,13,17],[0,4,6,9,16,17])
6:([0,1,8,12,14,17],[0,3,5,9,16,17])
0.000u 0.006s 0:00.00 0.0%      0+0k 0+0io 0pf+0w
7:([0,2,3,10,16,21,25],[0,4,9,15,22,23,25])
7:([0,1,4,10,18,23,25],[0,2,7,15,21,24,25])
7:([0,1,7,11,20,23,25],[0,2,5,14,18,24,25])
7:([0,1,11,16,19,23,25],[0,2,6,9,14,24,25])
7:([0,2,7,13,21,22,25],[0,3,4,12,18,23,25])
0.028u 0.001s 0:00.02 100.0%    1264+1048k 0+0io 0pf+0w
8:([0,1,4,9,15,22,32,34],[0,2,12,19,25,30,33,34])
0.346u 0.001s 0:00.34 100.0%    855+708k 0+0io 0pf+0w
9:([0,1,5,12,25,27,35,41,44],[0,3,9,17,19,32,39,43,44])
4.583u 0.022s 0:04.60 100.0%    840+697k 0+0io 0pf+0w
10:([0,1,6,10,23,26,34,41,53,55],[0,2,14,21,29,32,45,49,54,55])
83.079u 0.120s 1:23.22 99.9%    840+696k 0+0io 0pf+0w
11:([0,1,4,13,28,33,47,54,64,70,72],[0,2,8,18,25,39,44,59,68,71,72])
11:([0,1,9,19,24,31,52,56,58,69,72],[0,3,14,16,20,41,48,53,63,71,72])
1891.324u 1.534s 31:37.07 99.7% 840+696k 0+0io 0pf+0w
12:([0,2,6,24,29,40,43,55,68,75,76,85],[0,9,10,17,30,42,45,56,61,79,83,85])
7698.658u 9.628s 2:08:46.74 99.7%       840+696k 0+0io 0pf+0w

と、n=9以降のスピードアップに貢献してくれている。
n=13は現在計算中。

当初は、nの増加につれてGR-nの生成とは比べ物にならないほどの勢いで計算時間が増加していたので、あまりこの手法の導入に必要性を感じていなかった。
最近のコードの改良である程度実用的な時間で計算できるようになってきたので、計算過程を記録して途中から計算を始めることにもメリットが出てきたと思う。

なお、空でもいいからカレントディレクトリにogr.txt(結果が出力されるファイル)という名前のファイルがないとエラーになるのは、一応仕様です。