幾霜::残日録::2005/10/13 (木)

　さて、何をやっているところでしょう?

　正解は・・・みなで科学的を議論しているの図・・・などではなく、しりとりをしているところ(笑)。

　今更ですが書き忘れていたので。

　三中先生曰く
要するに，ベイジアンMCMC（BMCMC）による系統推定のパフォーマンスを調べるにあたって，シミュレーション（端点5）をするときのモデル系統樹をふたつ“混ぜて”塩基配列を生成してみたら，収束するまでさんざんのろのろしたあげく，高い事後確率で「変な系統樹」にたどりつくということですね．
　私も一見して(というかタイトルを見ただけで)そのような内容だろうと思ったのですが、そんなくだらない内容のワケがない、と思って何度も読んで、でもやっぱりそういう内容なのでした。

　何故くだらないか。単純に、当たり前だからですね。私的にはScienceに載るようなレベルの話とは思いませんし、Molecular Biology and EvolutionやSystematic Biologyならもっと載らないでしょう。でも載った。それはおそらく、系統推定を理解して(使って)いる人には常識でも、系統推定を理解せずに使っている人には全く知られていないことだからなんじゃないでしょうか。要するに、専門家には「ハァ?」でも一般ウケはする内容なワケですね。

　最尤法でもできましたが、MCMCの系統推定への応用とMrBayesの登場によって、様々な領域の配列データにそれぞれ異なる分子進化モデルを適用して系統推定することが容易になってきて、実際にミトコンドリアDNA全領域にそれを適用した論文などが出てくるようになってきています。しかし、ミトコンドリアDNA全域なら問題は少ないと思いますが(母性遺伝で組み換えも無い−と言っても、変異の飽和問題には注意が必要)、核DNAの配列を混ぜたり、核DNAの様々な領域を使う場合、それぞれの領域が異なる系統に由来する可能性が当然あります。そういう場合に、この論文の内容が効いてくるはずです(最尤法や最節約法の場合でも)。なので、私は複数の領域を別々に解析した上で、それぞれの解析が全く異なる結果を返すのなら、統合して解析することはできないと考えて使わないようにしています。これは私にとって「当然」「常識」なのですが、何かで読んだわけでも、誰かに教わったわけでもなく、系統推定法の勉強を通して自然にそう思ってやっています。そして、他人がこうしていると聞いたことは一度もありません。論文でこうやったと書かれているのも見たことがありません。ということで、普通の系統解析「ユーザー」は、多分こういう問題を知らないのだろうと思います。そのような現状を踏まえると、かの論文はScienceに掲載するに足る論文だったと言えるのかもしれません。むしろScienceだからこそ載ったのではないでしょうか。MBEなら載らなかったのではないかと思います。

　今後、S/N比の良さそうなデータを選び出す方法や、多数の領域の配列データを統合して解析する方法が系統解析法の分野で発展していくでしょう。それに伴って、ますますこの問題は重要になってくるでしょうから、このタイミングでScienceに採り上げられたことは歓迎すべきことだと思います。要するに、自分の研究で使っている方法論はできるだけ理解して気をつけて使おうや、ってーことで。

　で、まぁ、以前に逝ってよしと言ったKjerの論文がまさにこれなんすよね。形態形質まで混ぜとるし。しかも形態形質にめっちゃ依存しとるし。MrBayesで形態形質も混ぜられること自体が問題な気がしてきた。全部ごちゃ混ぜの最節約法も使ってますよ(冷笑)。こういう論文、一つや二つではないですし、現在進行形で拡大再生産されてるんですよねー。そして、そんなクソ論文を書いたやつに「業績」では私が負けるという現実。あームカつく。「知らない人間ほど平気で書けるから業績が増える現象」は地質データだけではないのよねー。こういうのが蔓延するようになるときっと有能な人は新規参入してこなくなるんではないか。あれ、じゃぁ俺は無能ってことか(笑えなーい)。

　emergeって一気にインストールまでしてしまうんですけど、configureだけとか、makeまでとか、指定したところまで処理を行うのはどうすんだ?

　Rのインストールでconfigureスクリプトに
--with-blas='-L/usr/local/lib64 -lgoto -lpthread'
を渡したいんですが、emerge経由だと''がうまく渡っていない?ようで、
--with-blas='-L/usr/local/lib64
-lgoto
-lpthread'
の3つのオプションがconfigureに渡され、-lgotoなんてオプションは知らんとエラーを吐く。''ではなくスペースの前に\を入れるという手も試しましたが同様。どうしよう? もうPortageでRを入れるのは諦めて野良ビルドするか?

追記 - 18:23:47
　configureにオプションを渡す方法はebuild次第のようですね。Rのebuildはeconfを利用してconfigureを走らせているのでうまくオプションが渡らないんでしょうか。とりあえずEXTRA_ECONF変数でオプションを渡す方法も試しましたが同様でしたので、とりあえずemergeで入れてから上書きするのが良いんでしょうかねぇ。

　emergeにはチェックサムの確認を飛ばすオプションは無いのか? ebuildを書き換えたいんですけど、Manifestまで書き換えんのはめんどいんですよねー。portsではMakefileまでは確認してなかったので書き換えは楽だったんですがねぇ。ある意味正しいアプローチではありますが、確認しないオプションは欲しいなぁ。いや、あるのかもしれませんけど。
　Portageはportsよりもメンテナンスがきっちりしているようで、ツリー自体の整合性がおかしくなっていることはあまり無い感じ。portsでは修正されるまで待っていなくてはならないようなことがままありました。使っていくうちに問題が出てくるのはまだよくわかりません。ports + portupgradeと比べてシステムとして良いかはともかく、ツリーの方は良さそうな感じですね。