親知らず(右下)の抜歯

本日は半日病院通いだったのだが、終わった後一旦家に帰り先のブログを書いて一服してから歯科医に向かった。

今回は右下の親知らずの抜歯。

手前の奥歯に引っかかっている部分をドリルでカット。この時先生が「う~ん、面倒やなぁ」とかこっちが顔面蒼白になりそうなことをつぶやくので、これはいよいよ噂に聞く怖い治療が始まるのか?!と身構えたり。

ドリルでの作業が終わると、ステンレス製のやっとこ(のようなもの?顔にタオルをかけられていたので形状は見えなかった)で一気に抜いたらしい。というか、麻酔が完璧に効いていたのでいつ抜かれたのか全然わからなかった。
その後は止血綿を銜えさせられてしばらく放置プレイ。実はこの時点でも抜かれたのかどうかわかっていなかった。

5分ほどして、「は~い、これで終わりです。口ゆすいでくださいねぇ」と言われて初めて抜歯されてたことに気が付く。ちょっと間抜けっぽいんですけど。

その後先生の説明。抜いた現物を見せながら、先生曰く抜歯した歯の根元の部分が結構太めしっかりしているらしく、もっと歳をとって骨が硬くなって(柔軟性がなくなって)からだと抜くのが大変になるらしい。

折角なので抜いた現物は記念にもらって帰ることに。歯肉がちょっとこびりついていて微妙にグロい。

鎮痛薬と抗生物質の処方箋を出してもらって、帰りに薬局へ。
明日、経過観察と傷口の消毒にもう一度通院することになった。

それにしても、トータルの治療時間で40分もかかってなかったんですけど。治療内容もえらいあっさりしてた気がするし。あんなに怖がって損した気分。
それとも実はとっても腕のいい先生だったりするんですかね。

今のところ麻酔が効いているのか、痛みはほとんど無い。口内から血の味が抜けないのはまだ微妙に出血してるんかな。

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

次の2点を元にその3のコードを書き直してみた。

  1. GR-nの長さの下限をn*(n-1)/2で推定していたが、今はOGR-nが計算できるのでOGR-nの探索に当たって、あらかじめOGR-(n-1)以下を計算しておき、これを下限値とする。また、OGR-nの長さの下限値をOGR-(n-1)の長さ+1で推定する。
  2. その3まではOGR-nの探索に当たってGR-nの長さのサンプルを取り、サンプルの最小値からn*(n-1)/2までの間で最小となる組み合わせを探索してOGR-nとしていた。今回は上記1の推定値との組み合わせから長さを増加させていき、最初にGR-nの条件を満たしたものをOGR-nとする。

ogr4.hs

このコードによるn<=11までの計算時間の測定値は次の通り。なお、コマンドラインオプションについている +RTS -K1024Mは実行ファイルに組み込まれているランタイムシステムに対して指示を与えるためのもので、スタック領域を最大1024MBまで拡張することを許可する(デフォルトで最大8MBまで)。

% time ./ogr4 7 +RTS -K1024M
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,3,10,16,21,25],[0,4,9,15,22,23,25])
7:([0,2,7,13,21,22,25],[0,3,4,12,18,23,25])
0.148u 0.001s 0:00.14 100.0%    708+937k 0+0io 0pf+0w
% time ./ogr4 8 +RTS -K1024M
8:([0,1,4,9,15,22,32,34],[0,2,12,19,25,30,33,34])
2.088u 0.000s 0:02.08 100.0%    662+876k 0+0io 0pf+0w
% time ./ogr4 9 +RTS -K1024M
9:([0,1,5,12,25,27,35,41,44],[0,3,9,17,19,32,39,43,44])
25.232u 0.022s 0:27.17 92.9%    659+872k 0+0io 0pf+0w
% time ./ogr4 10 +RTS -K1024M
10:([0,1,6,10,23,26,34,41,53,55],[0,2,14,21,29,32,45,49,54,55])
288.654u 0.255s 4:48.95 99.9%   659+872k 0+0io 0pf+0w
% time ./ogr4 11 +RTS -K1024M
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])
10576.996u 8.109s 2:56:47.39 99.7%      659+872k 0+0io 0pf+0w

OGR-11で計算時間が爆発しているのは同様だが、計算時間そのものは40%程度削減できている。
OGR-8、9、10では逆に計算時間が増大しているがこれは長さの下限の推定値がn*(n-1)/2を下回っているのとOGR-(n-1)以下をあらかじめ計算することによるオーバーヘッドから来るものと予想される。n>=11以降では1の推定値のほうが上回っているようなので、今回のコードのほうが計算上有利だと思われる。

1はOGR-nの探索のためのコードを書き出した頃から考えていたのだが、計算した長さのリストを各関数に持ち回るのが面倒だったので今まで伸ばし伸ばしにしてきた。今回、コードを書き直すに当たって下限の推定値を求める関数 lm を呼び出している関数全てを calc_ogr 関数のwhere節以下に移動し、長さのリストをcalc_ogrに渡す以外は前と同様に lm を呼び出すことで1の推定値が得られるように変更した。

1を反映させたコードを昨晩書き走らせてみたのだが、OGR-11の計算で4時間たっても終わらなかったので、あきらめて寝てしまった。
ところが今朝起きて一番に2のアイデアがひらめき、10分でコードを書き直せた。その3のコードのように計算のキャンセルを考える必要もなくなり、GR-nのサンプルも計算しなくて良くなったので想像以上にコードがシンプルになって我ながらびっくりな感じ。

このような形で閃きが得られたのは本当に久しぶりな気がする。
λの神様のクリスマスギフトか、はたまたH.カリーさんのお恵みか。
ま、思考のピースが寝ている間に適当にガベージコレクションされただけってところかも知れないが、ちょっとだけ幸せなクリスマスになった。