PyTorchの最近の動向

2022/11/26 Machin Learning 15minutesでの資料です。

Transcript

1. PyTorchの最近の動向 あるいは細かすぎて伝わらないPyTorch芸 Machine Learning 15minutes 2022/11/26 加藤公一 この資料は https://bit.ly/hamukazu20221126 で参照できます
2. 自己紹介 加藤公一（かとうきみかず） Twitter: @hamukazu 所属：ソフトバンク株式会社 仕事： データサイエンティスト兼AIエンジニア、社内の複数プロジェクトを掛け持ち 著書 監修
3. 宣伝
4. 宣伝 https://axross-recipe.com/
5. 話の概要 PyTorchの最近のアップデートで何が変わったか とくにver 1.11から1.13でなにが変わったか それらに関する個人的感想など
6. 動機 ちょっと前に作ったNotebookが動かなくなる問題 例：MNISTのデモプログラム 以前はなかったwarningが出る warningの中身：「dropout2dの入力が2次元なのはdepricatedで、将来のバージョンでエ ラーになるよ」
7. なにが問題か 既存の関数・クラスの仕様が勝手に変わる その結果、コードに手を入れてなくても既存のプログラム（Notebook）が動かなくなる
8. 勝手に仕様変えるなコノヤロウ vs その仕様はおかしいからすぐ直せ
9. 対策 再現性のためには、使用しているライブラリのバージョンとNotebookをセットで保存しま しょう。 「pip freeze」を使ったり、pipenvのlockファイルを使ったり。 この対策ができるから、ライブラリ作者は安心して仕様変更できる（？）
10. ここから本題 PyTorchの細かい仕様変更の話
11. ここからの話 ver 1.11 → ver 1.13 の仕様変更の話をします リリース日 ver 1.11 ：2022/5/11 ver 1.12 ：2022/7/29 ver 1.13 ：2022/10/25
12. torch.nn.Dropout2d Nはバッチサイズ、Cはチャンネル数、Lは画素数。 (N, C, L)の形式を仮定するようになった。 1.11でバッチサイズなしのテンソルをサポートするようになってから迷走してる？ 以前バージョンとの互換性については warningがでるだけなので、それほど問題はなさそう。
13. 範囲外の数値をint8型に変換しようとしたとき これは妥当な仕様変更（予想外の数値が代入されて動き続ける方が怖い） 既存のコードへの影響も少なそう（意図的にオーバーフロー範囲の数 値を代入することはあまりなさそう） 以前は無理やり代入できたがエラーになるようになった
14. 型変換周り clampは精度低い方に合わせてたのを改めた cdoubleへの変換は無駄に精度が上がってたのを 改めた まあ妥当な仕様でしょう 既存コードへの影響も少なさそう
15. 要素が整数のときのrequires_gradフラグ 定義域が整数である関数の微分を考えてもしょうがないのでこれで正しいように見える requires_gradというのは今後の計算で微分を計算するかというフラグ
16. もう少し詳しく >>> import torch >>> a = torch.tensor([1,2], requires_grad=True) Traceback (most recent call last): File "<stdin>", line 1, in <module> RuntimeError: Only Tensors of floating point and complex dtype can require gradients >>> a = torch.tensor([1.,2.], requires_grad=True) >>> a.data = torch.tensor([1,1]) >>> a tensor([1, 1], requires_grad=True) 整数要素テンソルを作るタイミングで requires_grad=Trueはもとからエラー 以下 ver 1.12.1の動き floatテンソルを作ってから要素に整数をセットすると通ってしまう（ requires_grad=Trueのままで） →これが改善された
17. torch.floor_devide floor_divide(-3,2)が-1だったものが-2になった →結果が変わる！！
18. floor_divide：なにが正しいか floor関数（床関数）というのは、通常はxを超えない最大の整数を意味する Python標準の整数値割り算（//）もそのような動きをする したがって新しい仕様（floor_divide(-3, 2) -> -2）のほうが自然な（混乱のない）仕様で ある だからといってそんなカジュアルに既存関数の結果を変えていいのだろうか？？ （もともと利用者が少ない？微分不可能だしNeural Networkに使えないし） ギャーって言ってる人いそう
19. まとめ • Notebookは突然動かなくなる ◦ それがいやならばpip freezeなどを使って必要な措置を • PyTorchはわりとアグレッシブに仕様を変更する ◦ 仕様が変更されて困る人より、仕様の自然さを優先 • 仕様変更にはそれなりに妥当な理由がある ◦ GithubのIssueに議論の書いてあります ◦ 不満があるなら議論に参加しましょう