たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

音響信号をどう表現するか

生波形か、変換した表現か

生波形の弱み

波形の違いがperceptualな違いに直結しない.
ゆえに波形の違いをlossに利用してもそれがperceptual lossの最小化に必ずしもならない (使うことはもちろんできるし、それで性能も出るときは出る)

特徴量の弱み

全変換する必要がある。
spectrogramなら位相も移す必要があり、Griffin-Limを使うか位相も機械学習で変換するか

WGAN入門

WGAN導入の流れ

  • Wasserstein distance (Earth-Mover Distance) は分布学習において有用
  • Wasserstein distanceを直接求める計算量は現実的でない
  • Kantorovich-Rubinstein 双対性によりWasserstein distanceを別の形式に変形できる
  • これをWGANと名付けよう
  • WGANはすごいぞ、ほらみろ実験結果だ

Wasserstein distance

直感的意味

確率分布間の離れ具合を示す指標.
Earth-Mover Distance (土の山を動かす距離) の名が示唆するように、ある分布をある分布へ"動かす"のに必要な労力、みたいな意味を持っている。
分布が一致してれば0になるし、離れていて形が違うほどdistanceが大きくなる

利点

KLやJSが定数損失を出しちゃう (勾配消失) 状態でも、Wassersteinなら勾配を提供してくれる例がある.

gがlocally Lipschitzでregularity assumption 1を満たすなら、Wasserstein distanceは連続、かつほとんどで微分可能

GANにどう持ち込んだのか

EMDは移動規則γによるコスト期待値の下界
双対問題と見ると、EMDは1-Lipshitz関数CriticによるCritic(dist1)期待値 - Critic(dist2)期待値の上界
CriticをFFNNとみれば、FFNN(true) - FFNN(G(z))のweight全域での最大値がDist_trueとDist_genのEMDになる。

分布間の距離を正確に計測し、距離が縮む方向にパラメータを動かせば分布間が近くなる.
正確なWasserstein distanceを求めるのは現実的ではないが、繰り返し計算でより正確な距離を推定することはできる。
だから、 Wasserstein distanceの繰り返し推定 -> 分布の移動
を繰り返せばいつか最適解にたどりつくはず。
前半がDiscriminator学習相当であり、後半はGenerator学習相当である。
Dが方向を学習し、GがDに基づいてよりよい生成器へ学習していく本質は似ている気がする。

WGANにおける色々な制限・前提

  • Lipschitz連続であること
    • originalのWGANはweight clipping

実際のアルゴリズム

CriticのlossはCritic(x_real) - Critic(G(z))のバッチ平均
Generatorのlossは - Critic(G(z))のバッチ平均
SGDで ncritic回 Criticを更新 (範囲超えたら都度clipping) したのち、1回Generatorを更新
超シンプル

WGANは本当に有効か

NS-GANやLS-GANと比較したとき、どんな違いがあるのか

  • NS-GANは勾配消失を起こすケースがある
    • 実務上、この勾配消失は頻繁におこるのか？
  • WGANは学習に時間かからないか？
    • critics (D) の繰り返し推定を多くすべきだが、それは計算時間を爆発させたりしないか？

論文読みメモ

いろんな距離

  • Total Variation (TV) distance
  • Kullback-Leibler (KL) divergence
  • Jensen-Shannon (JS) divergence
  • Earth-Mover (EM) distance, or Wasserstein-1

解説記事など

EMD, 双対表現

qiita.com

WebAssemblyを始めよう

WebAssemblyに触れてWebの未来を感じよう

WebAssemblyとは

WebAssembly (WASM) とは、Webブラウザで動く機械語です。
WASMはプログラミング言語であり、その実体はバイナリ命令の集合体、つまり機械語です1。
しかし、いわゆる機械語のイメージと異なり、Webブラウザで実行が可能です。
ゆえに、機械語の高速動作とWebブラウザのポータビリティという利点を享受でき (るように設計されてい) ます。

「高速動作するために機械語書けってこと…？」と思われるかもしれませんが、それは誤解です。
WASMはC/C++/Rustのような高級言語からのコンパイルターゲットとなることを意図されています2。
すなわち、CのコードをLinux用にではなくWebブラウザ (WASM ≒ 機械語) 用にコンパイルするということです (Cがブラウザで動く！)。
もちろんWASMを手書きすることも可能なので、機械語やアセンブリ言語の勉強として触るのも素晴らしいですね。

一言でまとめるなら、「WebAssembly (WASM) とは、様々な言語のコンパイルターゲットとなれるWebブラウザ用の機械語」です。

WebAssemblyを見てみる

ではWebAssembly、すなわちWebブラウザのための機械語を見てみましょう。





Webブラウザで動かしてみる



    

  • Get the .wasm bytes into a typed array or ArrayBuffer
    • 

  • Compile the bytes into a WebAssembly.Module
    • 

  • Instantiate the WebAssembly.Module with imports to get the callable exports
    • 





compiled_module = await WebAssembly.compile(wasm_binaries)
new WebAssembly.Instance(compiled_module, )







    

  1. 

    WebAssembly (abbreviated Wasm) is a binary instruction format ref  ↩
    2. 

  2. 

    Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. ref  ↩
    3. 






    
    
  



    
  

  




      
      
    
  
    
      
        

  

    

  
    

    
      
    
      

  

  機械学習を育てるx個のステップ



  
  


  

  




    


    

  
    
上手く学習しない！改善したい！何しよう…？



バグの検証



実装は正しくなされていますか？

既存モデルの別ドメイン流用であるなら、報告論文にあるドメインで再現が取れるか確認しましょう。

この段階でバグの不安を取り除くことが重要です。



データ数の検証



データ数は充分ですか？

データ数を段々減らして学習し、データ数 vs 性能 のグラフを書きましょう。

性能が飽和していない場合、データ数を増やすと性能が上がるでしょう。

データ集めが難しい場合、データの水増し (data argumentation) も検討できます。



データクオリティの検証



データは適切な前処理をなされていますか？

不要な情報の除去、標準化等、分野のベストプラクティスに学びましょう。



不調原因の検証



学習がどの段階でうまくいっていませんか？

重みの数値や誤認識データ、生成データなどの傾向を見て、何が学習を阻んでいるか (例. 勾配消失、モデルcollapse) をしっかりと見極めましょう。



ハイパーパラメータの検証



ハイパーパラメータは適切ですか？

ハイパーパラメータを1つずつ動かし、パラメータ vs 性能 のグラフを書きましょう。

Grid法など様々な最適化手法があるため、どれを使うか検討して見極めましょう。



それでもうまくいかないなら



モデル (ネットワーク) が不十分な可能性が高いです。

次は上手くいくと願いながら頑張りましょう。


    
    
  



    
  

  




      
      
    
  
    
      
        

  

    

  
    

    
      
    
      

  

  Windowsで圧縮した巨大zipがPythonで展開/解凍できない！



  
  


  

  




    


    

  
    
結論



それはライセンス関係で解凍できない。Pythonのzipfileで圧縮しなおせばok



現象



こんなエラーが発生した。



raise NotImplementedError("compression type %d (%s)" % (compress_type, descr))
NotImplementedError: compression type 9 (deflate64)




zipが解凍できないとは何事だ…？

別のzipは解凍できるのに、1.6GBあるファイルは解凍できない、なぜだ。



deflate64の闇



このissueに全てが書いてある.

github.com

要するに、この圧縮方式 (type 9, deflate64) はプロプライエタリな圧縮方式であり、python公式モジュールは意図的に対応していない。

そしてWindowsでは大容量ファイルの圧縮にdeflate64を利用するらしい。

すなわち、Windowsで圧縮した巨大zipファイルはPython非対応圧縮方式なためにPythonで解凍できない。omg...



解決方法



一度Windowsで解凍し、Pythonのライブラリを使ってzipにし直す。



1. モジュールを直接呼び出す



Pythonはコマンドラインの-mを利用して、ライブラリを直接利用できる。なので



python -m zipfile -c "new_zip_name.zip" source_dir_path




を叩けばおｋ

ただし、ディレクトリごと圧縮されるので、zipファイル内にsource_dir_pathディレクトリが１階層挟まることにはなる



2. ziplib



1.のディレクトリ挟まる現象を避けたい場合は、zipfileを使って圧縮し直す。

コマンドラインからPython REPL起動して以下を実行すればいい



import zipfile
zip = zipfile.ZipFile("new_zip_name.zip", mode="a", compression=zipfile.ZIP_DEFLATED)
 
for f in files:
    zip.write(f)