7/12- スケジュール about dbgphmm

[ryought]

7/12

• forwardにk-mer probを組み込む。食わせたリード集合を出力するのに、各ステート/各k-merを何回ずつ使ったか？ #35
• ランダムなシードから初めて、山登りする。どんな感じの軌跡を描くかを可視化してみる #39
  • 似たような停留点がたくさんある？(配列はどういう感じ？)
  • 正しい基底の選び方もわかっている。zeroから始めて、どの基底を入れた時に一番スコアが上がるか？
  • zeroから始めて、最終的に正しい基底に行き着くために考えられるいくつかの経路。どういうスコアの変化をするのか？
• シードを選べるようにする　#37
• priorをlog-spaceで計算する #38
  • P(read|read)>P(read|true-dbg)なので、true-dbgの方の確率がpriorをつけることで高くなることを示したい。
  • priorをlog-spaceで計算しないと桁落ちしている領域。
• 最適化の方針 より良い部分構造がないか？もう少し簡単に最適化できないか？
  • ありえない操作は？
  • 枝刈り？
  • 一部のk-mer集合だけを最適化する？
  • 一部のリードだけを最適化する(これは速度にしか効かない)
  • 初期値をよくする
  • 目的関数を簡単にする(priorを無視してforwardのみにする)
  • 意外とEMアルゴリズムも良いのかもしれない。pathを固定して、k-merの個数分布に合うように最適化する、みたいな
  • Forwardの部分構造、Priorの部分構造を考える
  • 良さそうなk-merの値は事前にわかる(平均コピー数等から)。その近傍を探索する、という感じでも良いかも
  • max-(ave)weight circleは求められる？(辺に重みがついている。その周に含まれる辺の平均の重みが最大のものを探すのは可能か？)
• 現状のメソッドの性質をチェックする
  • k=8~40ぐらいで変化させた時にどうなるか

[ryought]

7/13

• 作業
  • priorの計算式を直す
  • gradを可視化する
  • 基底を追加した時のスコア上昇をチェックする
  • 途中のアセンブリ配列を出力できるようにする
• 現在の探索の性質を示したい
  • 全状態の何割ぐらいをチェックできてるか
  • 最適化の途中で考えているアセンブリ配列を出力するようにする
  • 色々なリファレンスで、どのぐらいのサイズなら見つけられるかをチェックする
  • 正解基底を入れた時の嬉しさ(スコア上昇度)を調べる
  • あるk-merのcopy数を変えたい。基底単位でしか動けないと、他のk-merへのペナルティが大きすぎて変化させられない？
    • 「基底に含まれるk-merのコピー数の、正解との乖離」vs「基底追加時のスコア上昇度」の比較
    • 基底に拘らずに、修正が必要なk-merを多くふくむサイクルをとってくる
• カウント k-merのコピー数が足りない/多いを判定する。足りないところ、多いところに追加する。
  • EMアルゴリズムになる？
  • Eステップ: pathを固定することで、各k-merの登場回数がわかる
  • Mステップ: その登場回数に一番近い、validなcopy数を作る
  • priorをだんだんきつくする
  • 一度消えたk-merが復活してくれない。side pathを有効化することができない。
• 温度 k-merのコピー数が自信ない or 基底の係数が自信ないことを測る。温度に表現して、自信がないところを積極的に変えるようにする
  • あるk-merのコピー数が間違っていそうかどうかを判定する。Forward algorithm風
  • この判定では平均カバレッジを使う？一方priorではゲノムサイズを使う？priorがない場合、この部分はどうなる？
  • →端っこがない場合(途中から始まるリード、途中で終わるリードがない場合)、リードの登場回数で作るのがoptimalそう。端っこがある場合は、そのredundantな端っこを落とす作業に他ならない
  • 分散を縮めて、だんだん総コピー数を制限していく、みたいな
• 実数最適化にrelaxすると簡単になるのだろうか
  • 微分の式とは？
• Forwardは最初に1回回せば十分みたいな結論にならない？

readcountからcdbgを作る。
どのへんのcycleが要らなさそうかを検討する
→priorの値がやはりおかしい……

cycle basisの値を見ると、結構明らかにわかってしまうみたいなところがある

サイクル基底を使わないとすると

• 修正が必要なk-merを多くふくむサイクルをとってくる
• 目標値があって、それを小さくするサイクルを作る

[ryought]

7/15
考えたこと
最適化の方針

大域最大に落ちることを保証したい
山の形状をチェック
プライヤーの重みを弱くすると山が緩やかになることを示す
最適値がある条件を満たすことを示す
(ある範囲にはない、matroidになる、みたいな)
ゲノムサイズをパラメーターにして最適化する

それが無理なら、何か適当な最適化手法を使う
(まずはこちらの方が楽なのかもしれない　中腹の鞍点が多数ある
頂上もたくさんあるはず
(コピー数を等倍したもの、正解とリード中の出現回数など)

出現回数上限なくす=整数制限をなくす

[ryought]

7/16
考察

• 実数最適化にしたら簡単になるのか？
  • priorの意味はなくなる(スケーリングできてしまうので)
  • copy数というより出現頻度ということになる
  • 勾配法？微分して登っていく
  • (結局出現頻度の回数だけ出てくることになりそう？)
• 実数最適化を外すときに、priorの影響が出てくる

作業

• コピー数が実数でも動くようにする
  • HMMを動かす(元々trans_prob, init_probがf64なのでeasy)
  • 負の場合？
  • 重みの更新
    • 基底に沿って0.1足す、みたいなのはできるが……
    • 基底を使わずにやる(あるk-merにεを足す。他のk-merにも必要なだけεを足す→分岐した時に、その分岐の個数だけ割り振る。どれぐらい変化するかは計算できる？)
• realでEMなやつを適当に実装する

次数の制限を加える

• 次数を守る必要を緩める
  • gradだったら、各k-merごとに独立にfreqを変化させられる?
  • emだったら、多分出現回数(=使用頻度)をそのままfreqに割り当てる?
    • これを証明したい。
• 整数制限
  • 1ずつ変化させないといけない

[ryought]

7/19

• EM(E: kmer-freq, M: assign copy-nums)を試したい。