2023年12月

Torch7 (~2010-2017)
- 最近では、Lua 経由で使用されていたため、Torch7 を一般に LuaTorch とも呼びます。トーチ 7 は、2010 年に Ronan Collobert @clmt と @koraykv によって書かれました。私は 2012 年から正式な「メンテナー」の立場で Torch7 に深く関与し、2014 年 4 月にこれら 3 人の原作者に加わりました。
Refactoring LuaTorch to be language agonstic (late 2015 to mid 2016)
- 線形代数とニューラルネットワーク用のすべての CPU と CUDA コードを備えた LuaTorch の C バックエンドは、Lua と深く結びついていました。そこで、 @lantiga, @neurosp1ke, @szagoruyko5, 私, @apaszke, @fvsmassaを中心とした多くのメンバーが、これらのバックエンドを Lua に依存せず、独立して使用できるようにリファクタリングしました。私たちは、LuaTorch を新しいモダンなデザインに移行する必要があるとオンラインで議論した後にこれを実行しましたが、そのデザインがどのようなものであるべきかを完全に枠組みしていませんでした。
Writing a new Python based Torch (mid 2016) 2016 年の初めにインターンシップを探して私に連絡をくれました。当時、@AIatMeta の LuaTorch チームは全体で約 3 人 (@GregoryChanan, @TrevorKilleen と私) でした。私は Adam に、モダンなデザインの LuaTorch の次のバージョンを構築するためのインターンシップに来てくれるように頼みました。 @colesbury はプロジェクトの合間だったので、彼もフルタイムで参加しました。私たちは、特に次の 2 つの目的のために、LuaTorch、LuaTorch-nn コードベースのフォークから開始しました。
1. TH/THC および THNN/THCUNN C バックエンド
2. LuaTorch のチェックポイントとの互換性を構築し、LuaTorch ユーザーがスムーズに PyTorch を継続できるようにします。これは、LuaTorch の「nn」コードを Python にトランスパイルすることで実現しました。 PyTorch ではこのパッケージを「torch.legacy.nn」と呼びました。それから、デザイン自体についても、私たちはたくさんのデザインについて議論しました。強いインスピレーションは次のとおりです。
3. torch-autograd (@awiltschko および @clmt によって作成されました)
4. Chainer ( @PreferredNetのチームによって作成されました)。@ebetica Chainer が大好きで、これが最高だと熱心に話してくれたので、一緒にこれを作るために参加してくれました。ナタリア・ギメルシェインやパートタイム @adamlerer など、他にもかなりの数の人々がさまざまな方法で関与しました。私たちは PyTorch の新しい設計のコードを最初から書きました。
The connection to JAX: inspiration of HIPS/autograd
- @awiltschko の torch-autograd (これは PyTorch の設計に大きなインスピレーションを与えました) は、@SingularMattrix, @DougalMaclaurin, @DavidDuvenaud と @ryan_p_adams,の HIPS/autograd ライブラリから直接インスピレーションを得たもので、その間接的な意味では、Ryan のライブラリから強いインスピレーションを受けました。実際、私たちは特定の起源についてあまりにも無頓着だったので、Autodiff エンジンに「torch.autograd」という名前を付けました。これは、autodiff コミュニティ内では物事を「autograd」と呼ぶのが標準であると考えたためです。その後、私たちのサブパッケージの名前が彼らの「autograd」パッケージと競合していることについて、@SingularMattrixとチームに謝罪しなければなりませんでした。その後、 @SingularMattrix @DougalMaclaurin らは JAX を作成し、HIPS/autograd の設計の探求を続けました。
The inspiration from Chainer -> PyTorch and the inspiration for PyTorch -> Chainer v2
- Chainer は強いインスピレーションを与えてくれました。私たちは Chains などのコンセプトがとても気に入りました。 Chainer の開発者は私たちの友人であり、彼らともよく交流しました。私は2017年に彼らを日本に訪ねました。私の意見では、Chainer のデザインは革新的なデザイン–で、当時としては非常に独創的で、かなり素晴らしいものです。私たちはそこからインスピレーションを得たことを誇りに思います。ただし、一般に誤解されたり誤って帰属されたりするのとは異なり、私たちは Chainer の設計をそのまま複製しただけではありません。人々は、PyTorch の設計が Chainer の設計とまったく同じであるため、その起源が単なるコピーアンドペースト–であり、それは共進化を理解していないためであるとオンラインに投稿しています。 PyTorch のリリース後、Chainer は PyTorch の優れたアイデアの一部を組み込むように進化し、最終的には同じように見えるように統合されました。たとえば、Chainer の nn Chains では、すべてのモジュールをコンストラクターに渡す (または add_link を使用する) 必要がありました。自己代入の概念 (ie) self.conv = nn.Conv2d (...) 、Parameter の概念は、Chainer v1 からの進化したアップグレードとして導入したものです。また、インプレース操作で正確性の問題を検出するための「変数バージョニング」など、autodiff エンジンの実装方法–を革新的に変更しました。また、その他のいくつかの新しいアイデア、最終的に v2 の Chainer に戻されたアイデアなども革新的に変更しました。Chainer のコミュニティが開発を停止したいと考えたとき、 @PreferredNet友好的かつ積極的に PyTorch コミュニティに参加しました (参考文献のリンク)。
Post-launch evolution (2017 to present)
- この投稿には PyTorch について説明するスペースがありません。
  - Caffe2 からのアイデアを追加する進化 (@jiayq @dzhulgako et. al)
  - 素晴らしいと思われるものにたどり着くまでの 5 つのコンパイラ設計 (Zach DeVito、 @ezyang @apaszke @jamesr66 Jason Ansel、Christian Sarofeen 他)
  - JAX と functorch の設計からのインスピレーション (Richard Zou、@cHHillee @vfdev_5 Animesh Jain)
  - 私たちの分散型設計と進化全体
  - スパースパッケージの起源 (@braizh) とその進化 ( @cpuhrsch et. al.)
  - PyTorch のドメインライブラリ
  - データロード (@colesbury @TongzhouWang )
  - コミュニティのデザイン、コミュニティの成長、インセンティブのデザインの革新 ( @ptrblck_de Alban Desmaison、私)
  - GPU コードにおけるいくつかの革新 (NVIDIA および Meta の主要人物数名) 私が含めなかった PyTorch の他の多くの部分–は、この時点である程度モノリスになっています。

アイデアの帰属を明らかにすることは健全で素晴らしいことなので、もっと頻繁に行うべきです PyTorch がリリースされて以来、いくつかの新しいライブラリが PyTorch の設計とアイデアを使用しています–私たちが導入した特定の新しいアイデアは、最終的には他の多くのライブラリに伝わりました– 。これは素晴らしいことです。私たちは、これまでの仕事からインスピレーションを得てきたことを誇りに思いますし、その後の仕事にもインスピレーションを与えてきたことを誇りに思っています。また、私たちは– torch-autograd、chainer、その他、より小さな方法で私たちにインスピレーションを与えてくれた多くのプロジェクトからインスピレーションを得たことを常に明確に示していることに誇りを持っています –。私は、人々はこれを十分に行っておらず、自分の起源を明確に帰属させていない–と思います（p36）歴史を消去するためにエゴまたは企業の統制が機能するようになり– 、人々はここでもっと行動する必要があります。その意味で、フレームワーク設計を科学的な取り組みとして捉え、アイデアや進化についてオープンに議論し、その起源やインスピレーションを誇らしげに語る JAX の友人たちを私は本当に誇りに思います。

参考文献:

My reply in March'17 on the origins of PyTorch: https://discuss.pytorch.org/t/pytorch-tutorial-for-deep-learning-researchers/1001/3?u=smth
Chainer’s v1 design: https://github.com/chainer/chainer/blob/v1/examples/imagenet/googlenet.py#L11-L33
https://pytorch.org/blog/pytorch-adds-new-tools-and-libraries-welcomes-preferred-networks-to-its-community/
PyTorch’s autodiff innovations in a short paper: https://openreview.net/pdf?id=BJJsrmfCZ
The PyTorch paper: https://proceedings.neurips.cc/paper_files/paper/2019/file/bdbca288fee7f92f2bfa9f7012727740-Paper.pdf

GitHubの開いてるIssue一覧、結局検索で「author:kaityo256 state:open type:issue」で探せってことか。確かにそれで普通に見つかるからいいのか。

12月18日

1on1たくさん。sshfsとか、VSCode+Remote SSHをハンズオンに入れた方が良さそう。

12月17日

レポート採点完了。力作が多かった。

年賀状頼んだ。

いろいろバタバタする。

なんかX(Twitter)は騒がしすぎるな。しずかなインターネットを試してみるかなぁ。

12月16日

レポート採点途中まで。

12月15日

ようやく先週の疲れが取れてきたのだが・・・

大きいドキュメント書いた。ずっと前から書こうと思っていたのだが、腰が重かった。

腰が重い仕事、もう一つこなした。

推薦文二通書いた。良い感じである。

12月14日

学生さんと話していて、デバッグの正しい(?)考え方が伝わっていない気がした。デバッグとは、「どこが間違っているかを探す」よりも「どこは絶対正しいか探し、それを容疑者から外していく」ことの方が大事。

ChatGPTなどにより、とりあえずコードを作ってしまい、後からデバッグするという形をとると、これがうまくいかなくなる。モジュールごとにテストしながらプログラムを組み上げ、バグったら、そのコードそのものよりも、テストコードを書く方が早い、ということをなんとか伝えたい。

課題研究発表会(M1中間発表)の練習会。

12月13日

会議の前に重要なことを思い出した。危なかった。

会議。

年末調整の書類提出。予めシステムにイメージをアップロードしておいたものに対して、原本を提出する。システムから原本を貼り付けるための台紙をダウンロード、印刷し、セロテープで貼り付けて事務に提出。A4一枚に原本1枚。今年は11枚あった。

なんか、学生に個人的に伝えているプログラミングのノウハウをドキュメント化したい。特に、デバッグしながら、ステップバイステップで開発する形。今はChatGPTとかを使って、とりあえず完成形を出しちゃってから修正・デバッグやっているのがあまりよろしくない。

12月12日

講義。

最近心身ともに疲れててダメだ。夜、「SNSにお気持ちを書いてはいけない」というポストを見かけて「そうだよなぁ」と納得。最近いろいろダメだ。

12月11日

1on1して会議して1on1して。

もうこの会議で発言するのやめよう。僕は必要ないはずだし。

12月10日

WSLのターミナルでcode .と入力したらエラー。

$ code .
Updating VS Code Server to version af28b32d7e553898b2a91af498b1fb666fdebe0c
Removing previous installation...
Installing VS Code Server for x64 (af28b32d7e553898b2a91af498b1fb666fdebe0c)
Downloading: 100%
Failed
--2023-12-10 00:50:11--  https://update.code.visualstudio.com/commit:af28b32d7e553898b2a91af498b1fb666fdebe0c/server-linux-x64/stable
update.code.visualstudio.com (update.code.visualstudio.com) をDNSに問いあわせています... 13.107.246.46, 13.107.213.46, 2620:1ec:bdf::46, ...
update.code.visualstudio.com (update.code.visualstudio.com)|13.107.246.46|:443 に接続しています... 接続しました。
エラー: update.code.visualstudio.com の証明書(発行者: `CN=Microsoft Azure RSA TLS Issuing CA 08,O=Microsoft Corporation,C=US')の検証に失敗しました:
  発行された証明書はまだ有効ではありません。
update.code.visualstudio.com に安全の確認をしないで接続するには、`--no-check-certificate' を使ってください。
ERROR: Failed to download https://update.code.visualstudio.com/commit:af28b32d7e553898b2a91af498b1fb666fdebe0c/server-linux-x64/stable to /home/watanabe/.vscode-server/bin/af28b32d7e553898b2a91af498b1fb666fdebe0c-1702137011.tar.gz
Please install missing certificates.
Debian/Ubuntu:  sudo apt-get install ca-certificates

証明書が有効でないというエラー。あれ？と思ってChatGPTに証明書の有効性を確認するコマンドを聞いて実行。

$ openssl s_client -servername update.code.visualstudio.com -connect update.code.visualstudio.com:443 | openssl x509 -noout -dates
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G2
verify return:1
depth=1 C = US, O = Microsoft Corporation, CN = Microsoft Azure RSA TLS Issuing CA 08
verify return:1
depth=0 C = US, ST = WA, L = Redmond, O = Microsoft Corporation, CN = update.code.visualstudio.com
verify error:num=9:certificate is not yet valid
notBefore=Dec  9 18:17:28 2023 GMT
verify return:1
depth=0 C = US, ST = WA, L = Redmond, O = Microsoft Corporation, CN = update.code.visualstudio.com
notBefore=Dec  9 18:17:28 2023 GMT
verify return:1
notBefore=Dec  9 18:17:28 2023 GMT
notAfter=Jun  6 18:17:28 2024 GMT

「verify error:num=9:certificate is not yet valid」。まだ有効でない？ここで、さっきのメッセージに「発行された証明書はまだ有効ではありません。」と書いてあったことに気づく。WSLの時計がずれてたんだ。

sudo /usr/sbin/hwclock -s

これで動いた。10分毎に実行するようcronに入れてたんだけど、実行されてないっぽいなぁ。

JCPのProof見た。「Fig. 10 (a)」みたいな奴、わざわざ「Fig.~~\ref{fig:label}~~(a)」と、括弧前に空白を入れてたんだけど、Proofでは消されている。

塩漬け仕事、一つ片付けた。すぐ終わるんだけど、なんか腰が重いんだ。

届いた荷物を片付けるため、遠い部屋に行く
鍵を居室に忘れたことに気づいて戻る
居室で鍵を探し、また遠い部屋に行く
違う鍵を持ってきたことに気づき、居室に戻る
居室で鍵を探したら、さっき持っていいた鍵が正しい鍵であることがわかる。

今日はもう駄目だ。多分何してもミスる。

12月9日

疲れが重くのしかかっている。

プログラミング基礎同演習のレポート少し採点。

12月8日

1on1とか。

「日々しなければならない仕事だけで一日を終わらせない」というのがそもそもこの日記を書く動機だったのだが、もはやday単位でそれを実行することは不可能。というわけで、「日々しなければならないこと以外」のためにC++ MIXで発表したのだが、わりとスケジュールに無理があってちょっと疲れた。

自分の研究がまったくできていないのでなんとかしなければ。

12月7日

研究室ミーティング。輪講。PRML最後。

自分はt-SNEについてざっくりと理解について話した。

12月6日

渡辺研配属面接。

その後、C++ MIX #8へ。

12月5日

プログラミング基礎同演習。今日はオブジェクト指向。

その後いろいろバタバタする。

12月4日

1on1。

メール処理。

水曜日のスライド作った。

今更だが、ChatGPTのハルシネーションの例が増えたのでメモ。

「GCCのGIMPLEは何の略ですか？」

ChatGPT-3.5「GCCのGIMPLEは「GNU Compiler Collection（GCC）のインターナル中間表現 (GNU Compiler Intermediate Representation)」の略です。GIMPLEはGCC内部で使用される中間表現形式であり、コンパイラの最適化およびコード生成の段階でプログラムを表現するために使用されます。GIMPLEはプログラムをより抽象的な形式で表現し、さまざまな最適化処理が適用される前にプログラムを単純化および標準化するのに役立ちます。この中間表現は、GCCの内部で使用され、ユーザーが直接操作する必要はありません。プログラムの最適化やコード生成についての詳細な情報を含むため、GCCの開発者にとって非常に役立つものです。」

ChatGPT-4「GCCの「GIMPLE」は、「Generic and GIMPLE」の略です。GCC (GNU Compiler Collection) では、GIMPLEは中間表現の一種として使用されており、高レベルのソースコードと低レベルの機械語の間でコードを変換する際に重要な役割を果たします。この中間表現は、最適化や他の変換処理に適した形式で、プログラムの構造を維持しながら、コンパイラがより容易に解析できるように設計されています。」

GitHub演習のレポート採点した。ギリギリになってしまった。

12月3日

子供のお迎えとか。疲れた。

12月2日

学科分け説明会。

渡辺研の展示(数独、GitHub演習のゲーム、京のCPU)が数年変わっていないので、そろそろ新しくしたい。

プログラミング基礎同演習のレポート採点した。

12月1日

来年度前期の物性研の申請した。

学生さんからの報告を受けて、だいぶRBMの理解が深まった気がする。是非論文にまとめたい。

学科分け説明会の準備。

GitHub演習ゲームプレイ用PCのセットアップ
GitHub演習ゲームをfork
GitHub演習の説明のチラシを印刷
数独印刷
京コンピュータのCPU展示用の紙印刷

2023年12月

12月31日

12月30日

12月29日

12月28日

12月27日

12月26日

12月25日

12月24日

12月23日

12月22日

12月21日

12月20日

12月19日