幾霜::残日録::2005/03/17 (木)

　今日は雨かー。街中に出よと思っとったんやけどなぁ。でもアパートの契約更新とか大阪行きのバス乗車券の購入とかせなあかんし、傘持って出かけるか。

　舌噛んだーー。しかもかなり強く。いてー。

　ライブドアは司法に助けられたか。ま、当然の判断ではあるが。
　その筋に詳しくない私の予想では「ニッポン放送は増資せずフジの持ち株比率は下げない(もしくは上場廃止にならない程度に増資)。ライブドアはニッポン放送にフジ株の買い増しをさせない。その代わりニッポン放送(とポニーキャニオン)とフジテレビはライブドアにコンテンツを提供する(業務提携)」という感じで手打ちになるんとちゃうかなぁ。フジが折れへんかな。

　以下のような感じ。

1. NEXUSのデータファイルからPHYLIP形式でExport
2. seqbootでbootstrapリサンプリング
3. bootfix1.plにAltNexus形式の最尤系統樹を与えてリサンプリングしたデータと任意のモデルに基づく枝長をPAUP*に計算させるスクリプトを生成(リサンプリングしたデータファイルがinterleavedでない場合はnoオプションを付けること)
4. PAUP*で枝長計算
5. bootfix2.plでr8sに分岐年代を計算させるスクリプトを生成(検討したいクレードをmrcaで指定しておく必要あり。これでハマった)
6. r8sで分岐年代の計算
7. bootnodes.plで分岐年代値の95%信頼限界を推定

　結果の解釈には気をつける必要がある。たとえば最も末端の枝を考えたとき、リサンプリングデータではしばしば一段上のノードにくっついてしまう場合がある。そのような場合があるとreplicateが1,000でも実際に目的の末端枝が現れるのは1,000回以下になる。実はこのキットでは枝が現れる場合のみを利用しているので、出現した中での平均と95%信頼限界を算出しているようだが、これでいいのかはなはだ疑問だ。
　というのも、理想的には平均は元の最尤系統樹に同じ方法で時間軸を入れたものと一致するはずだが、10,000 replicateでも無視できないほど小さくなった。何せ95%信頼限界の中に元の系統樹から求めた時間軸が入らない有様。これは上位(もしくは下位)のノードによって「蓋がされる」ためだと思う。勿論分岐が下位側に来る場合にも限界があるのですが、今回の場合は枝が長かったのでそれはあまりなかったもよう。
　つまり、枝長の最大、最小はともに「壁」によって多くなるはずなのに、上位側の壁にぶつかったものは利用せず、下位側の壁にぶつかっているものは利用しているために枝長分布を過小に評価してしまっているように思われる。
　これを修正するには、両端の壁にぶつかっているものをカウントし壁の外側へ「ならす」ことで、元の系統樹から求められる枝長を中心とするように枝長分布を推定して95%信頼限界を求めなければならないのではないか。どうもこのスクリプトはそこまでの処理はやっていないような気がする(まだきちんと読んでないけどやっていれば上記のようなことは起こるまい)。
　結局、自分でスクリプト書くしか無いのか? んな時間無いぞ。ま、短い方へバイアスがかかっているにもかかわらず95%信頼限界の下限はこの値だ、ということが言えれば私の目的は達せられるのではあるが。補正用の基準値を与えるモードがあるので、もしかするとこのモードだとそこまでやってくれるのかもしれない。
　あと、こういう場合、replicateを増やせば見かけ上95%信頼限界はどんどん狭くなるわけですが、それはどう考えればいいんだろう。そういうのを標準化する手法が多分あると思うんですが、知らんぞ。

追記 - 02:26:17
　補正用の基準値を与えるモードは全replicateで当該分岐が出現していないと使えないらしい。あかんやん。

追記 - 02:58:36
『理想的には平均は元の最尤系統樹に同じ方法で時間軸を入れたものと一致するはず』
とは言えないんじゃないかという気がしてきたのは気のせいか? アレ? いかん、脳味噌こんがらがってきた。