備忘録メモ。
GTX1080をUbuntu16.04,CUDA8.0でセットアップしたが，今までTITANやTeslaで動いていたコードがNaNを吐き出すようになった。使っていたライブラリはchainer。
調べたところconvolutional layerのforward計算の出力がNaNになっていることが分かった。chainerの本家のmnist exampleの層をconvolutionに変えても同様にNaNを吐いた。
gpuメモリの初期不良を疑ったが，LSTMなどの計算には問題は起きていなかったので，試しにcuDNNを外してみたところ、正常に動いた。
最新のバージョンのcudnnのみを入れなおしたところ，同様に正常に動いたことから，GTXがcuDNNフォルダに一緒に入っていた古いcuDNNを認識した結果NaNを吐くようになっていたらしい。
今までこんなことなかったので勝手に認識してくれるものだと思っていた...バージョン管理の大切さよ...
chainerでforwardの計算をするときに行列の対角成分をとりたい時があったが、これを計算するfunctionsが現行のchainer(v1.19.0)に確認できなかった。
ちなみにTensorflowだとdiag_part()がこれに相当する。
http://devdocs.io/tensorflow~python/math_ops#diag_part
Theanoだとdiagonal()という関数がある。がこれは成分でなく対角成分のみでつくった対角行列を返す？(試してない)
github.com
やりたい処理をnumpyで表現すると、具体的には以下のようになる。
>>> import numpy as np >>> x=np.arange(9).reshape(3,3) >>> x array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) >>> np.diag(x) array([0, 4, 8])
自作で対応する関数を作ってもいいのだが、暇もないので今あるfunctionsで作ることにした。
作ったのは以下の通り。
github.com
案は2つあって、
1. 単位行列を要素ごとにかけて列ごとの和をとる
2. batch_matmulを使って正方行列(nxn)と単位行列(nxn)をベクトル(nx1)ごとに分割して計算する
どちらが速いのか実際やってみた。
cpu計算とgpu計算で正方行列のサイズは100x100,1000x1000,10000x10000。
GPUは NVIDIA Corporation GM206 [GeForce GTX 960] を用いた。
100x100 matrix #cpu $ python chainer_diag.py 100 -1 time of diag_part_elementwise: 0.0002493858337402344 time of diag_part_batch_matmul: 0.00036978721618652344 #gpu $ python chainer_diag.py 100 0 time of diag_part_elementwise: 0.10309004783630371 time of diag_part_batch_matmul: 0.06094169616699219 1000x1000 matrix #cpu $ python chainer_diag.py 1000 -1 time of diag_part_elementwise: 0.0017409324645996094 time of diag_part_batch_matmul: 0.0019404888153076172 #gpu $ python chainer_diag.py 1000 0 time of diag_part_elementwise: 0.10210251808166504 time of diag_part_batch_matmul: 0.06030750274658203 10000x10000 matrix #cpu $ python chainer_diag.py 10000 -1 time of diag_part_elementwise: 0.11125564575195312 time of diag_part_batch_matmul: 0.0674281120300293 #gpu $ python chainer_diag.py 10000 0 time of diag_part_elementwise: 0.12932491302490234 time of diag_part_batch_matmul: 0.1076195240020752
gpu計算よりもcpu計算のが速い・・・
個別に比較すると、大体の場合要素ごとの計算よりもbatch_matmulを使った方が若干速いらしい。
ということで、batch_matmulを使う方法で実装しようと思う。
先輩方の博士論文の公聴会を聴講して、個人的に色々と刺さるものがあったので一応メモとして残しておく。
審査員の先生方から入ったツッコミをまとめると、主に以下の３点が刺さった。
「この博士論文にはまだフィロソフィーが足りない」という言葉は特に刺さった。傍から聞いてた自分も11回くらい射殺された。手法とか、ネットワークの設計とかでもなんとなくやってるんでは意味がなくて、細かいところにもちゃんと目的・理由付けを持ってないといかんなーと改めて思った次第。
ちなみに先輩方さすがうまいな、と思ったのは以下の点。ここらへん自分も学振とかの書類申請で書いてはきたが、ちゃんと説明できるようにしておきたい。
詳細についてはあとで追加するかもしれない。（気が向いたら）
いままでopencvをpythonから呼び出すのにcv2を苦労してパス通してたが、やらなくて良い苦行であったことを知ったのでメモ。
python2については下記の記事を参照のこと。
qiita.com
ただ、python3ではうまく入らなかったので、少し探してみた。
するとやっぱりあった。
https://anaconda.org/menpo/opencv3
リンク先を参考に
conda install -c menpo opencv3=3.1.0
するとcv2が使える。なんかバージョンがopencv2とopencv3で違うが、とりあえずcv2を使うだけならこれで良さそう。
WaveNetのArXiv原稿を読んだのでメモ
概要
生の音声波形の生成を行うDNN
自己回帰型モデル
前の全ての波形サンプルから次のサンプルを予測するための予測分布を持つ（自己回帰型なので）（途中の波形の履歴から次のデータを生成できる、くらいの意味）
10,000サンプル/secの音声波形を使った
TTSに適用すると、SOTAの性能。評価方法は人間による音声の自然性の主観評価、比べた相手はEnglish,Chinese両言語についての一番良いパラメトリックでいくつもの手法を組み合わせた手法
単体のWaveNetは多くの異なる話者の特徴を真に迫ってとらえている
Speakerのidentity(というパラメータ？)で条件づけることで対応する話者をスイッチ可能
音楽に適用すると、最新のすごくリアルな音楽の断片を生成できた
WaveNetは識別モデルにも適用可能であることを示し、音声認識でよい結果を出した
Introduction
PixelCNNdecoderやPixelRNNは良い生画像を生成できる。でも64x64=4096次元
特にPixelCNNに注目、これは音声（16,000 sample/sec）のような長い系列データでもうまく生成できるのか
この論文の貢献
・WaveNetを使って今までにない自然性を持つ音声の生成が可能なTTSを発表、人手評価による
・長期的な系列を扱うためにDilated causal convolutions（超大きな受容野を持つ）をもとにした新しいアーキテクチャを提案
・話者ごとに違った音声（声）を生成可能
・同じアーキテクチャで小さな音声認識データセットを使っても、強い結果を得た。また、音楽のような違う音声モダリティ（というかドメイン？）も生成できることを示した
アーキテクチャ
PixcelCNNから
条件確率分布はstack of convolutional layersでモデル化されている
プーリング層がない、出力は入力と同じ時間次元数（？）を持つ
出力はsoftmax層を使ったカテゴリ分布（カテゴリは次の値なのでx_tの数値のとりうる値だけある（量子化してるはずだがいくつか分からない））
最尤推定→扱いやすくてoverfitting, underfittingがみやすいから
Dilated causal convolutions
Stack of causal convolutional layers→図２
これを使うときちんと時系列を考慮して計算ができる（前の系列が後の系列に依存して生成されるというようなことがない）
Causal convolutionは[Oord 2016a]のmasked convolutionと等価→調べる
→あらかじめマスクテンソルとその乗算を要素ごとに、convoultion kernelについて行う
音声の場合次元が1次元になるのでいくらか実装が簡単
訓練中、条件付き分布はground truthを知っているので並列化可能（生成時はもちろん無理）
Causal convolutions は再帰結合をもたないのでRNNを訓練するより訓練時間が短くて済む
問題は多くの層を必要とすること、受容野を増やすため大きなフィルターが必要ということ（つまり、メモリをバカ食いする）
図２だと受容野は５つ（=５層＋filter length 1 -1）filter lengthとは？
この論文では受容野のオーダーを大きくしつつ、計算コスト（時間もメモリも）を少なく抑えるためにdilated convolutionsを使った
Dilated convolution(図３)は要は結合の飛ばしを入れた形
以前にも信号処理や画像セグメンテーションで使われている手法
Dilationは1層上がるごとに2倍増えてくようにする（理由は不明）
1,2,4,8,…,512,1,2,4,8,…,512,1,2,…
↑2分木の形にすると層を深くできないから？
Softmax distributions
画像も256値のsoftmax層を用いた多クラス分類とするとうまくいくことが報告されたので
音声でもsoftmax予測をする。音声は16bitでサンプルされてるので、216=65,536値の多クラス分類をする
でももっと扱いやすいように、μ-law companding transformation（？）をデータに適用して256値にした
どういう経緯でこれが出てきたかは不明
Conditional wavenets
条件付きに拡張
話者ごとのスイッチ、TTSにおけるテキスト入力が該当
全ての時間について入力は固定
TTSのパラメータ（時系列）を使いたい場合→transposed convolutional networkでupsamplingしてから音声信号に時系列のスケールを合わせる
Transposed convolutionせずにむりやり利用してもいいが、若干劣る
Experiment
音声生成
English multi-speaker corpus (CSTR vice cloning toolkit (VCTK))を使用
WaveNetは話者の条件付けバージョン→speaker ID のone-hot vector
109人からの44時間分のデータセット
テキストで条件づけてないのでしゃべってる内容はわからないけど人間っぽい話声の単語の羅列がスムーズにでてくる
しかしCloser inspection（近い検査？元のデータ？）に対し明らかに不自然な部分がある
→これはモデルの受容野サイズが制限されているから（約300msec）つまり、前の２－３の音素しかちゃんと思い出せないということ
話者の違いはちゃんと学習できていた（評価は？）
声だけでなく、acoustics, recording quality, breathing, mouth movementsの特徴もとらえていた（だから評価は？）
TTS
同じ単一話者のデータベース（GogleのNorth American EnglishとMandarin Chinese） のTTSをつくった？
前者は24.6時間の音声データ、後者は34.8時間のデータ。どちらもプロの女性話者
WaveNetは局所的にテキストから抽出された言語特徴（詳細不明）とlogF_0で条件付けして訓練した
外部モデルが言語特徴から予測したlogF_0とphone durationsはそれぞれの言語で訓練に使った
受容野のサイズは240 msec
ベースライン
HMM-driven unist selection concatenative [Gonzalvo 2016]
LSTM-RNN-based statistical parametric [Zen 2016]
使うデータセット、言語特徴量は同じ。
評価
主観のペア比較（A/B test?）2つの音源から好きな方を選ぶ、好みがなければ自然な方を選ぶ
Mean opinion score(MOS) 自然性を5段階のリッカート尺度で評価
図５はペア比較の結果
一番上はベースライン２つ
真ん中はWaveNet２つ
一番下は上2つの決勝戦（ただし、bestベースラインはサンプルごとに上のもの逐一とってきてるものと思われる）
WaveNet：言語特徴のみの条件付けだと自然なクオリティはあるが、韻律がおかしいところがあった（強調しないはずの単語を強調していて若干不自然）
これはおそらくF_0の高さの長期的な依存をとらえられてないのが原因
受容野のサイズが240 msec分と短いのがこの原因
F_0も条件付けにいれた場合はこの問題が起きないので良くなっている。
外部のF_0予測モデルは200Hzという低周波数で動いているので、F_0のうち長期のスケールを持つ周波数帯も学習できたといえる
表１はMOSの結果（高いほど良い）
WaveNetが最良の結果
音楽
The MagnaTagAtune dataset
200時間の音楽、29秒ごとのクリップに188種類のうち該当するタグがついている（ジャンル、instrumentation, tempo, volume, mood of the music
YouTube pianoデータセット
60時間のピアノソロ動画、単一の楽器のみなのでモデル化は簡単だと思われる
定量的な評価は難しいが、主観評価は可能
受容野を大きくするのが超重要
数秒の受容野をもってしても、ジャンルの別や楽器の種類、音量、音声の質を学習したりできなかった
しかし、生成したサンプルはしばしば調和的で審美的に良かった。条件付けがなくても同様
MagnaTagATuneは比較的タグにノイズがあったり、省略が多かったり（タグデータの欠損？）したので、クリーニングして、似ているタグは一元化してやると比較的良い結果を得られたことを確認した
音声認識
TIMITデータセット
Dilated convolutionの後ろにmean-pooling層を入れた
荒いフレーム（10 msecのスパン）（160 x dounsampling）→スムージングみたいなイメージ
pooling層の後ろはnon-causal convolutions(普通のconvolution?後ろの時間にも依存して出力？)
２つのロス関数、一つは次のサンプルの予測（分類）、もう一つはフレームの音素のクラス分類
モデルは単一のロス関数にするよりも汎化性能がよかった
Testsetに対して18.8 PER(phone error rate)
これはTIMITコーパスにおいて波形から直接学習したモデルで著者らの知る限りベストスコア
PILで画像をロードするとき、しばしば画像がロードできない現象が起きていたが、解決した。
自分のケースも
IOError: image file is truncated (0 bytes not processed)
というエラーだったので、おそらくこれで間違いない。
解決法としては、
from PIL import ImageFile ImageFile.LOAD_TRUNCATED_IMAGES = True
を追加するだけで良いらしい。
どうやらPILは極端に大きな画像など高速にロードできない画像はロードしないで見過ごす仕様になっているらしい。
デフォルトでFalseになっているLOAD_TRUNCATED_IMAGESをTrueにすることできちんとロードするようになった。
いままで「え？なんで他の人は普通にロードできるの？俺だけ？」と思っていたものだが、これで一つ懸念が解決して良かった。
やっぱ先人のコードを読むのは大事
pythonのビルトイン関数にfilterというのがある。これはリストに対して条件に合致する要素をとってくることができる。よくネットで見るのは、
>>> lis=["apple","grape","banana","apple pie"] >>> filter(lambda x:x=="apple",lis) ['apple']
ところが、pythonのバージョンによってはどうやらオブジェクトで返ってくる場合があるようである。
>>> lis=["apple","grape","banana","apple pie"] >>> filter(lambda x:x=="apple",lis) <filter object at 0x7fd0dd679860> >>> list(filter(lambda x:x=="apple",lis)) ['apple']
少し試してみた感じ、たぶん上がpython2で下がpython3？
思わぬところで注意が必要なようだ。
そもそも、filter関数を使わずに
>>> lis=["apple","grape","banana","apple pie"] >>> [word for word in lis if word=="apple"] ['apple']
とした方が、文字列の部分一致だとかリストのindex返したりだとか色々応用が利きそうな気もする。
