No Such Blog or Diary

とりあえず原因らしき部分判明．結局ソースをすべて読み返してバグをつぶした．それにしても二年前によく動いていたものだなぁと．当時生成していた木だと縮約途中にほとんど高さがなくなっていたのが原因だろう．ということは，当時の結果は効率の良くなる状態であったこと結論付けられるのだが…　気にせんとこう．

二年くらい前のプログラムうまく動かず…　台数増やすと落ちるのだがサイズが小さいときには落ちない．ノード数が原因なんだか高さが原因なんだかよくわからず．とりあえず二分探索で閾値となる大きさとか調べよう．

まず，秋葉原まで歩いて行く道のりで三回ほどたばこの煙を食らった．歩きながら吸うなよと思う．そして，そんなに好きなら煙を吐き出すな．

次に，帰りの電車で優先席付近にいた人間15人中携帯電話使用が5人．目の前に電源を切れと書いてあるしアナウンスも電源切れと言っているに．電源入れたまま電波を切った状態だったのだろうか？そこまで器用には見えんかったが．

最後に，コンビニでアイスを買ってる最中に傘を盗まれた．というか，目の前の爺さんのさしている傘がどう見ても俺の物．珍しい壊れ方が特徴．で，声をかけようかと考えている隙にじいさんは隣のマンションの中へ．オートロックの向こうへ行かれてしまい追跡断念．ボケてたのか自分のが盗まれたからやったのかそいういう人なのか？　よくわからんけどそろそろ捨てようと思っていた傘なのでくれてやる分にはいいのだが…　黙って持ってくのはどうかと思う．（壊れてたからゴミだと思ったのだろうか？）

Quine の原理とかを調べていたら Mathworld と Wikipedia で見つけた．式の満たさせる部分を塗り分けるとこの式自体を描画できるとのこと．元々の論文（SINGGRAPH 2001）は陰関数の描画をうまくやるアルゴリズムの提案らしい．そのデモンストレーションの一部でこんな関数もうまく描けますよと．関数自体の原理は数字にエンコードされた二値のビットマップをデコードしているみたい．とてつもなくあほでいいなぁ．

午前中の SRM 355 に参加するも一文も解けずにぼろぼろ．

一問目はLPだとか思った瞬間にソルバ書くの面倒だからと破棄．

二問目は数式をこねくり回していたら最後の判定式を打ち込み終わったところで時間切れ．

三問目は面倒そうなのでやめ．

こんなでもレーティングがあまり下がらなかったのは全体的に出来が悪かったからだろうか？

ノード数を固定した場合の原理は理解した．下りた回数と上った回数の組で漸化式立てるときれいみたい．が，これに高さ制限を入れるとあまりきれいな式にならないような気がする．どっかに論文落ちてないかな？