• これまでは、 connector vectors の処理だけ考えていた、ということ。
• 忘れたわけではなかったが、なかなか、ここまで浮上してこれなかった。

• ただし、こいつは resistance form から簡単に書けるはず （chebyshev を使っているので）。

• done.

• 今回の一連の努力の本題にたどり着く。
• が、今まで書いたコードを改めて見ると、 そうか noHI も HI も最初に書いたものは、まだ直鎖決め打ちだったんだ……。
• 古いものを忘れて、今回は逆に一般的なコードから書いてみよう。

• 昨日は source を import しただけ。
• 多 chains だとグループ化は本質的なので、 一般的に組み込む。 （本当のことをいうと、 non-Brownian にまで一般化したいけれど、 そっちはまた今度ということにする。）
• 出来た。

• 予定通り（というか、何というか）問題が発生。 core dump する。
• 調べてみたら、 未定義 pointer を free しようとしていた、という単純な間違いだったけど、 何も問題なくパスするよりは、トラブルが起きて、それに対処するという一手間があると、 ああ本当に動いているなと実感できる。

• bonds-groups は（まだどこでも使われていないが）そのまま import.
• bonds と bonds-guile は bonds-new と bonds-new-guile で置き換え。
  • plan 通り、とりあえず struct list_ex は外しておく。
• 旧 bonds を使っているものを新 BONDS に書き換え。
• excluded-volume の処理を書き直す。
  • これまでの実装が旧 bonds べったりだったため。
  • それなりの理由はあったけど、設計が悪いということで、 bonds と独立に書き下ろす。
  • guile の wrapper (excluded-volume-guile) も書き換えた。
• これで終わったかと思ったら、 stokes->ex_lub をコメントアウトしておく必要があった。 （struct list_ex を外しておくため。）
• 現状でテストを確認。
  • list-ex のチェックは（もちろん）はずす。
  • 何か全部問題なく動いているみたい（半信半疑）。 ……あ、当たり前か。よく見たら陽に bonds をチェックしていないや。
• で、今までなかった bonds のテスト・コードを書く。 guile wrapper のチェックのみ(check-bonds-guile.c)。
• あと、今回書き直した excluded-voulme についてもテストが同様になかったので、 これまた guile wrapper のみチェックを書いておく(check-excluded-volume-guile.c)。
  • 一瞬、うまく動いていないなくて焦るが。 変数の次元ありとなしの混同だった。
• ということで、 phase 1 終了。 （cf. 7/14/2008）
• 7/17/2008: と言いつつ、 phase 1 の残り部分があった。

• 作業場から libstokes/src へ。
  • 置き換える予定だった bonds.[ch] が、以前手を入れたまままだ未登録だったので、 暫定的に bonds-new.[ch] をそのままの名前で平行移動。
  • 帰宅後、 bonds.[ch] を一旦登録後に、 bonds-new 関係を bonds に置き換える（予定）。 -- DONE.

• 一つ memory 関係のトラブルに出会う。
  • 調べると allocation size が間違って小さかった。 これでエラーになるというのは、 linux の仕様なのかな？
  • いずれにせよ、見落としがちな bug が落ちて助かった。
• あれれ NITSOL が解けていない模様……。 これは少し置いておく。

• 既存の struct bonds を置き換える方針で、 そのように今書いている code を整理する。

• 特に performance が気になるので、押さえておく。
• どのレベルで比較するか迷ったが、 calc_force level で一発にする。
• 出来た。結果は完璧に同じ。時間はほとんど同じ。
• ということで merge に go sign が出た。

1. exclusion list は置いておいて、 既存の bonds を新しい BONDS に置き換え、 GROUPS を組み込む。
   • 7/16/2008: BONDS done.
   • 7/17/2008: GROUPS done.
2. fastSI を組み込む。
3. exclusion list を考え直す。 多分 GROUPS ベースで書き直すのがよいのだろう。
4. exclusion list の生成 algorithm をきちんと文書化しておく。

• 必要なパーツは、既に全部揃っているので。

• 色々と手を入れたので、色々と修正が必要だった。
• あれれ、一部 fail しているなあ。

• こっちも、分からなくなる前に、きちんと文書化しておく。

• できた。 N=100 で全ての config で pass. 終了。

• 書いた（note/20070507-dna/bead-rod.tex）。
• うん、結構よく書けたのではなかろうか。 手書きの紙片１０枚程度が、これで破棄できる。
• 7/10/2008: さらしておく。

• やっと 7/3/2008 の段階まで浮上してきた、ということ。
• COM の導入部分の定式化をサボっているので、まずは明文化するところから。
• やっと見通しが立った、というところかな。

• やっぱり、実際に動かして見ないと、理解できないし、先に進めない。
• ざっと、新たに定義した struct のテストをして、本題に移る。

• 雰囲気で書いたコードを、一つ一つ確認しながら、動くものにしよう、という話。
• 簡単な構造から食わせていって、その動作を確認していく。
• やっぱり、全然おかしな挙動をしていた。一番のポイントは map (graph) を undirected で組んでいたが、 directed にしないとダメな algorithm であった。
• その後、瑣末な間違いを訂正していって、多分、動くようになった。
• 今のところ、直鎖１本、直鎖２本、放射状、 リング、リング + 余剰な bonds を２ケース、 独立な粒子 + 直鎖で確認済み。

• とりあえず、書いただけ。未チェック。

• pos と conn の相互変換に必要な情報は、 粒子リストと、独立な bond リスト、か。
• redundant な bond を落とす一般的な方法が、悩ましいな、やっぱり。

• その１：各グループごとに bonds を定義する。
  • 既存の struct bonds に必要な要素を追加する。
  • 変換ルーチンとか組んでいて、よく考えて、思い至る。 システム全体の struct bonds を定義しておいて、 それと独立なグループ毎の struct を定義した方が、見通しがよさそう。
• その２：系全体の bonds と、それとは独立なグループを定義する。
  • 問題はやっぱり、系全体の bonds から、どうやってグループを切り分けるか、だ。
  • ぼちぼちと、いきなり、タイプしていく。
• 7/8/2008: 実装の続き。
• 7/9/2008: 続きの続き。

• 直鎖じゃない場合にも正しい？ 少し考えてみた。独立でない bond を落とせば、よい。
• 問題は、「独立ではない bond を落とす」 algorithm をどうするか、だな。 どこまで一般的に（直鎖を越えて）扱うか、ということ。
• 7/7/2008: 続き。

• それに際しては、さらにスケジュールを後ろにずらしてもらって、 ９月前半をイメージしている。

• 調査の結果、 fastSI_f の HI 対応を忘れていたというオチ。

• 現状で noHI がすべてパスするところは確認（N=100 まで）。
• HI が、しかし、何とも悩ましい状態。
  • ダメな部分を切り分けて、簡単そうな部分から攻めていく。
  • どうも、きれいに行く状況ではないみたい（結構デリケート）。

• うむ、 Hsieh et al の乗りでまとめれば、一般化するのは難しくない。
• 問題は計算の効率だが、それは code を書いてからにしよう。

• RUN4 の N=200, d=20 が終了（していたのは、昨日。予定通りの７日だ。）
  • うむ、 d=30 と同じ seed を使ってしまった模様。
  • 分布関数を見ると、期待される方向にずれはある。後できちんと押さえておこう。
• 計算の追加は、 今の coding が一段落してからにしよう。

• N=100 で NITSOL がこける問題、解決。
  • 問題は、またもや config の設定 （else if すべき所が一ヶ所 if だけになっていた、というおバカなもの）。
• 以上で no-HI 版のテストは終了とする。

• ノートに戻って、定式化を確認。
  • ふむ、 right-hand side vector のみの変更で対応できる。
• しかるべく、実装。
  • できた。 straight chain の F の決め打ちで、しかも non periodic だけ。
  • ついでなので corrector step の初期と update の統合もしておく。 （詳しい理由は知らないけど、微妙に違うんだよな。 この違いについては、後でちょっと調べておこう。）
  • これまでのチェックで通ることを確認ののち、古い（非統合）コードは破棄。
• これで、一応 HI 化はできたはす。
  • 不十分な点がもう一つ、 connector から position を作るのに、 COM を手で与えている。
• テスト：
  • 既存のテストに flag_noHI を追加。 一通り走るようになった！！
  • と思っていたら、 何かの加減で check_fastSI_solve_cubic が文句を言うようになった。
    • 見ると、いろいろ下らない bug や、思い違いがあった。
    • それらを修正後も、まだどこかで nan になっている模様……。
  • 7/3/2008: テストの続き。
• 今月はここまで。

• 自分のコードにやっとこさ間違いを発見。 正直に書くと、 x^y の計算で、結果を代入していなかった。 つまり

  x = pow (x, y);

  と書くべき所を

  pow (x, y);

  としただけで、のんびりしていた。 bug なんてこういうものだよね、 という教訓のために明記しておこう。
• その後、 GSL と速度比べしたら、あれれ倍近く遅いや。
• GSL のコードを見ると、きちんと戻り値で解の数を返しているので （これが欲しかったのだ。 しかも後で見たらきちんと document にも書かれているではないか…… 手を抜かずにきちんと読みましょう）、 GSL のルーチンをそのまま使うことにする。
• 一つ一つ bug を潰して行って、やっと６種類で妥当な結果を得る所まできた。 勝率１０割！！
  • FENE-Fraenkel では s を大きくとりすぎていて、 おかしい（精度が悪い）としばらく悩んだ。 論文に従って s=0.01 程度にしておく。

• これもなかなか骨が折れた。
  • ポイントは configuration を作る際、 FENE モデルでは bead distance を Q₀ よりも 小さく取らないといけないが、そこをしくじっていた。
• 速度を比較したところ、本当に高速 scheme がダントツだな （これを期待して頑張っていたわけだけど）。
  • N=3 だと 少なくとも３倍、全般的に５倍程度は出ている。
  • N=30 だと GSL が急に performance が悪くなる。 それでも NITSOL の３倍弱は出ている。
  • 調子にのって N=100 も見てみると、 いくつかの場合 NITSOL がこけるなぁ……。
• 6/30/2008: noHI のテスト、終了。

• 6/27/2008: さらに続き。

• 調べてみたら、３次方程式が正しく解けていない。
• 自分でコードを書いているのだが（6/24/2008）、そいつがうまく動いていない模様。参ったね。
• 結局、これで一日潰す。しかもまだ動いていない……。
• 帰宅後、 GSL を覗くとあったよ。 gsl_poly_solve_cubic. こいつは（当然）きちんと解けているな。

• ３勝３敗、勝率５割だ！（悪いな -- 内二つは線形だし。）
• 6/26/2008: 勝率５割なんて大嘘だった……。
• 6/27/2008: さらに続き。

• 以前一瞬やってる（9/21/2007）。 その時のテスト・コードを動くようにしておく。
• 1D は動いていて、 2D も組んではいる模様。動くのかな？

ボルツマンは「優美にすることは靴屋と仕立屋にまかしておけばいい」と言った。

• 私の記憶にあるのは maxwell が boltzmann の書いたものを評して言った 「彼の書くものは長すぎて困る」というようなもの（出典はなにだったっけなあ）。 これを見て「いかん、俺は boltzmann タイプだな」と思ったので覚えている。

では最後に自慢話をひとつ。
　ぼくは自分が科学にまったく携わってこなかった者としては、 いちはやくアインシュタインの相対性理論を理解できた 数少ない一人だったのではないかと思っている。 これは湯川秀樹博士とのちょっとした蜜月が支えになったからなのだが （このことについてはまた書くことにするが）、 明けても暮れても相対性理論に集中した濃厚な日々も役立っている。
　ずっとのちになって、当時、大阪大学理学部教授だった内山龍雄さんが 岩波新書に『相対性理論入門』（1978）を書くことになったとき、 内山さんから「どういうふうに書こうか悩んでいるんで、相談にのってよ」と言われ、 二人であれこれそのシナリオを練ったことがあるのだが、 そのとき内山さんは「君はどうしてそんなにおもしろく相対性理論のことが考えられるの？」 と聞かれた。正確ではないが、こんなふうに応えたのではないかとおもう。
　「アインシュタインがおもしろそうに考えたということばかりが気になってましたから」。

• いや本当に恐れ入るな、松岡さんには。 「いちはやく理解できた」ことにではなく、 「本物」な人の懐に飛び込む、その行動力なのか、人間的な魅力なのか、 そういうものについて。
• 4/17/2008: 本格的で本気な人に沢山会ってきた人としての松岡さん。
• 3/3/2008: 松岡さんのアンテナ（シェイクスピアのレコーダー）。

かつてぼくは「炭男」（すみおとこ）と称していたことがあるんだね。 「半巡通信」というたった８ページのパーソナルメディアを、最初は３００人に、 最後は４０００人に無料で送っていたころのことです。７年ほど続けたかな。 その「半巡通信」のなかで、「ぼくは炭男だ」と書いた。 その炭男が発火すると火元になる（笑）。

• 考えてみると、この日記が私にとっての「パーソナルメディア」なんだな、 「無料で送って」いる。しかし私には、届けたいと思う明確なターゲットが そもそも「３００人」もいないけれど。
• そういえば、 自分がやりたいことをやるメディアとしての「雑誌」というのは大塚英志をみて ふうんと思ったし（4/3/2003）、 「ベンチャー」は近藤淳也をみて ふうんと思ったし（9/5/2005）、 「（私）学校」は西郷隆盛をみて ふうんと思ったな（12/27/2006）。

• 作業場にて実装開始。
• まずは３次方程式の解から……。えっと、千里の道も一歩から、と。
• 6/26/2008: バグっている。

• とりあえず straight chain の決め打ち
  • また、である……後で一般化するのが、また大変なのは分かっているが……。
• あと、とりあえず noHI だけ。
• ただし force law は ILC 以外６種類、一通り組みました。
• 対応する非線形解法アプローチも GSL multiroot 版と NITSOL 版とも組んだ。

• 先週はじめた計算、予定通り終了（ってことは、７日）。
  • もう一本は、この調子だと倍ちょっとかかりそうだな。
• 結果は、ふむ、 d を大きくとりすぎていて面白くない （し、分布がきれいではない == 相空間を十分走り回っていない）。
• 計算の追加を流しておく。これも一週間の予定（１００％で）。
• 7/2/2008: 予定通り、終了。

• Somasi et al (2002) は、いわゆる Werner spring,
• Hsieh et al (2003) は Cohen's approximation,
• Hsieh et al (2006) は FENE-Fraenkel を使っている。
• ILC 以外は、代数的に計算できる。

• 5/7/2007: 論文の印刷。
• 10/12/2007: 勉強中。
• 11/16/2007: 依然、勉強中。
• 11/29/2007: まだまだ、勉強中。

• なんというか、諦めの悪い性分だなあと思いつつ。
• 具体的に使ってる仕事を探してみる。 あんまりなかったけど、一つ見つけた。 ううむ、確かに、しち面倒くさいことをやっている（やる必要がある）みたい。

• うむ、確かに諦めの悪い性分だ。

• 第７の spring type を導入（既に６種類も実装している、ということ）。
• こいつは３つパラメータが必要なので、 struct bonds に手を入れる。
• guile parser も update.

• 論文には結果の式は出揃っているみたいだけど、 途中がすっとばしてあり、しかも何か難解。 彼の本は手に入らないし、困ったなあ……。
• 6/20/2008: そうだ、一般相対性理論を勉強してみよう！

• こいつら、どう実装するのか、結構悩ましいな。
• それに多分、 stiff な bead-spring がやっぱり正解みたいだな。

• 初見（11/5/2007）ではスルーしていた部分にある、お話の背景が分かってきた。
• ということで、またこいつを実装してみようかな。 （今回は、すでにパーツは全部そろっているはずなので、簡単だろう。）
• 6/18/2008: 進む前に、もうちょっと。

• 先週仕込んだ結果、もう一つも終了。 （ってことは７日か - 6/10/2008）
• 結果を解析。平衡に行っているかどうかが（いつもの）懸念。 前みたいに、現状ではまず、 下限に注目しておくことにするか。
• 追加計算を仕込んでおく。（予定では一本は１週間、もう一本はそれ以上。）
  • 6/24/2008: 予定通り、一本終了。 もう一本は、倍ちょっとかかりそう……。

• 幾つかの高速化のアイデアと、 取り扱いの改善案（SCM での設定項目を増やすという話）。

• 先週仕込んだ結果、一つが終了。 （ってことは６日か - 6/10/2008）
• 結果を解析。落ち着いたかなと思ったら、最後の最後にまた動き出している様子……。 endless だなあ。
• 現状では下限を見て、そういうものだ、という結論で置いておくのがいいのかな。
  • 6/17/2008: 似たように……。