プロジェクトが大きくなってくると、既存のコードに直接新機能を追加するのは、本当にバグがどんどん増えていくものだね。今日一日で2つの似たようなバグを見つけた、本当に腹立たしい！

kernel_size と stride は一対一対応ではない

以前のコードで定義したモデルでは、nn.Conv2dの kernelsize と stride が一対一で対応していた。しかし、拡張後のモデルには以前書いた対応ルールに従わない層が一つあり、kernelsize に基づいて stride に値を代入するコードがそのまま問題を起こした。

今日突然assertで shape を判定するコードを書かなかったら、一生気づかなかったかもしれない。

if kernel_size == 3:
    padding = 1
    stride = 1
elif kernel_size == 5:
    padding = 2
    stride = 2
else:
    raise ValueError()

すべての畳み込み層の後にReLUがあるわけではない

以前のモデルでは、各畳み込み層の後にnn.ReLUが続いていた。しかし、新しい解像度要件に適応するために変換層を設計したが、その後にはnn.ReLUがない。その名前付けルールは以前の畳み込みと同じだ。同時に、シミュレーション計算の時、以前書いた判定ルールがそのままエラーになった。o(￣┰￣*)ゞ

-if quant.startswith('classifier_conv'):
+if quant.startswith('classifier_conv') and quant != 'classifier_conv_transfer':
    x[x < 0] = 0

とにかく、今日見つかった2つのバグはどちらも元のコードから移行して少し追加した結果、判定条件のミスが起きたものだ。これらの問題は避けられないようだ。最初から拡張性の良いアーキテクチャを設計しない限りは。でも、最初に将来起こりうる問題をどうやって予知できるだろうか？研究は製品開発とは違うし、しばらくすると新しいアイデアが出てくるから、それほど多くを考慮するのはさらに不可能な気がする。