Vol.0, No.0

はじめに

自由気ままに研究をする生活は思ったほど自堕落でも非生産的でもなくそれなりにコミットを繰り返す生活ではあるけども、一体何を今週していたのか後で振り返ってもよくわからないまま今年が終わろうとしている。。おそらく1年後には「今年も早かった。何をしていたのか全然覚えていないなあ」ということになってしまうのは必定。やはり何か文章時な足跡は残した方がいいのではと思う。

記録メディアになりそうな世間で広く使われるWebサービスを見回してみると、Twitterはあまりにも時間軸に縛られむしろ文脈が霧散してしまう。Github Issueは実行前の決意表明なり問題意識が結論なく浮かび上がっているだけで知識の蓄積には程遠い（ような使い方しか個人的にはできていない）。Mediumは首尾一貫したそして成功したストーリーでないといけない雰囲気がある。そして、ここはメモに特化しすぎて日記ではない。まあ一つカテゴリーを作ればいいかもしれないが、図表の貼り付けやらwebからデータを保存して貼り付けたりをしながら記事を打ち込んでいくのはのは面倒臭いものである。

だったらその前処理としてポチポチiPhoneやらipadでも打てるような、執筆が習慣づけるような（メインマシンでベンチマークを実行していても入力できることが肝心）そういう手軽な媒体（それは結局Pagesに決定した。）で作成して、そのplain text版をここに貼り付けることにしてみよう。

Splr開発の行き詰まり

さて、これまでのSplrの開発においてはリスタートは極力減らす方向を取ってきた。これは、

• 3SATなどのインスタンスでは明らかに、リスタートを減らし深く組合せを調査するdeep searchが非常に有効である。
• そもそも静的リスタートが提唱された時代に、early restartは求解可能性に支障をきたす可能性が指摘されている。
• 多少のリスタートを繰り返しても組合せ爆発に対応できるのか疑問。
• リスタートによりランダムに部分解を見つけても、統合できなければ完全解には到達しない。むしろ相関のある割り当て集合を（探索空間を絞って）早く見つける方が得。

という理由による。しかし、どう頑張っても解ける問題が限定されてきて、ある種の問題には全滅という状況を見ていてどうも求解能力そのものが行き詰まっている。パラメータチューニングではどうにもならないのではないかという気がしてきた。これが今月1番重要な問題である。

爆発的リスタート導入の検討開始

ということで積極的にリスタートを行う方向に舵を取ってみることにした。根拠は以下の通り。

• 現在解けている問題に対してはせいぜい少し遅くなるだけではないだろうか。
• 問題の特性を動的に取得したいなら様々な観察は必要。100万次元ならそれに見合った「観察」はするべき。だとすると100万リスタートは目指してもよいかもしれない。
• 意図せずして特定の問題カテゴリーに強いソルバーよりもランダムに解ける方がベース実装として望ましいのでは。
• うまくいけば、不思議なdeep searchのコードを消すことができるかも。

いろいろやっているが今のところ、性能向上は見られず、解ける問題は変わらない。探索可能空間はそれほど変わらないようだ。

Splr Version 0.2.1リリース

リスタートの研究は時間がかかりそうなのでClauseIdをstruct化したものを0.2.1としてリリースした。

今回はここまで。今回は準備号Vol.0, No.0として、こんな感じで来年から本格的に始めてみよう。