6/28以降にやりたいことの展望 about dbgphmm

[ryought]

セミナーまでに最低限やること

モデルが有用な場合だけに絞って論文を書く

サイクルを見つける、勾配法を実装する
bellman fordの改良版を実装する
色々なmock genomeを作って実験する

[ryought]

話したいこと

• 新しい変分近似のcompressionがどの程度良いか？
• 総合的に(=com+ext)、どのぐらいの精度で復元できるか？ランダムに色々なゲノムを作って実験してみる。ゲノムの違いvs精度、みたいなグラフを
• スコアの変化を可視化する

e2eのテストを作る。fuzzテストを実装する。

[ryought]

緊急

• 並列でテストできるようにする。結果をファイルに書き出す。
• compareの結果を知りたい。read中のk-merのうち…というのを知りたい。

refactoring

• Genomeを専用のstructに変更する。内側はStyledSeqのvec。genome_sizeをmethodとして計算できるようにする
• DatasetをJSONでoutputできるようにする？
• dbg中のfrom/into塩基列変換を完全にしておく。特にpathやcycle(つまりnode列)を塩基配列にする部分。塩基配列から、対応するnode列に変換する部分。さらに、cycleの時は始まりの位置に関して自由度があるので、適当な基準で固定したい。
• 出力するファイルの形式を固定する。
• sampling、Fulllengthの時のread_lengthは不要。Optionにするか、ReadTypeのFragmentedの中にread lengthを入れる。

parallel testing

色々なパラメーターを並列に計算したい。
ある関数を実行する。
サマリーファイルを出力する。
各パラメーターに対応するファイルも出力する。

出力は基本的にJSONにしたい
サマリーファイルは一行に1objectみたいなjson。
jsonの時と、普通に書き出す時を分けたい。

[ryought]

7/7にやること

• お試しでSchedulerを作ってみる
• compression_v3とextensionを組み合わせてどうなるかをチェック(ログの出力を更新する)
• compressionの様子を可視化する方法を作る。tandem repeatの時のdbgを可視化して、q関数の値を見れるようにする。

[ryought]

7/8の報告で話す内容と準備

主題1: Q関数を偏微分して向上させる方法はあまりうまくいかない

やったこと

compression (k-merのdbgのlogP(R|G)+logP(G)の最大化) をEMアルゴリズムとして頑張って解く

• Eステップは、HMMのBaum-Welchと同じように遷移・出力の使用率を計算する
• Mステップは、求まるQ関数は例えばmin-flow等で厳密に最大化することはできない複雑な関数。そのため、変分近似のようなことをして、min-flowで近似的に解く。
  • 非凸cost関数のmin-cost-flowになる。負のサイクルが意味のない場合がある。2通りの解決策(1つは厳密、1つは近似的というか発見的)が準備できて、今はとりあえず後者を使っている。
• ハイパーパラメーターはlambda(事前分布の係数)とlog0=L0(log0=-inftyとすると、コピー数を0にすることが禁じられてしまう。それを緩和するためのヒューリスティック)。
  • lambdaは大きくすればするほど、ゲノムサイズが大きすぎるときの罰則が強くなる。そのためサイズを小さくしようという圧力が高まる。
  • L0は小さい(=-inftyに近い)ほど、コピー数を0と推定する罰則が強くなる。L0が小さすぎると「とりあえず全部のk-merを残しておこう」という推定になる。L0が大きすぎると、気軽にk-merを消されてしまう。

compressionの目標

• (概念的には) MAP推定 logP(R|G)+logP(G)を最大化する
• (extensionと組み合わせる枠組みの上では) k-merの時点でいらないものはk+1-merの時点でもいらないはず。dbgのノード数を減らすことができる

compression自体の動き
例えばリード中の全k-merから始めて、色々なlambdaとL0で比較する。
評価指標は

• TN/FN: compression自体の目標はk-mer
• n_under_estimated_kmers: コピー数が
• ヒストグラム: 真のコピー数がxのk-merの、推定コピー数のヒストグラム。
• スコア(事後確率): 真のモデル(つまり全部正しいコピー数のdbg)をベースラインにできる。

compressionの枠組みがあまり良くなさそうな理由

compression+extensionで考える限り、compressionではコピー数を少なめに見積もることが許されない。

これまでは、ひとたびコピー数を間違えて0xにすると復活できないので、compressionでは「FN(本当は存在するのに0xと判定される)を減らしつつTN(本当に0xなものを0xと判定する)を増やし、dbg中から明らかにいらないk-merを削っていく」ことを目標にすれば良いと考えていた。

しかし、k-merの推定されたコピー数が真のコピー数よりも少ない場合にも、extensionによって問題が起きる。extensionではコピー数を増やすことができないので、
TODO 実例を示す

「小さいk-merのコピー数から決めていく」、そもそも無理では？

真のコピー数よりも絶対上にいるように推定し続けるのは無理では？

検証したいこと

• 本当にMAP推定ができているのか？真のモデルとスコアを比較する。
• MAP推定ができたとして、意味があるのか？

サイドプロジェクト

[ryought]

compressionの性質を測る

点が試行のやつ
パラメーターを色で表現する

• x=TN/y=FN

横軸がイテレーションの図

• 確率値(尤度と事前分布) リード推定値、MAP推定値をベースラインとする
• ゲノムサイズ(コピー数の和)と、k-merの種類数
• kmerの正答率関係: TN/FN・n_under_estimated_kmers