研究でのうっかりミス日記2プロジェクトが大きくなるにつれて、元のコードに直接新機能を追加すると本当にバグが増えますね。今日一日で似たようなバグを2つも見つけてしまい、本当に腹立たしいです！kernel_size と stride は一対一対応していない以前のコードで定義されたモデルでは、nn.Conv2dの kernelsize と stride が一対一対応していました。しかし、拡張後のモデルには以前の対応ルールに合わない層があり、kernelsize に基づいて stride を割り当てるコードが直接問題を起こしました。今日突然 assert で shape をチェックしなければ、一生気づかなかったでしょう。PYTHONif kernel_size == 3: padding = 1 stride = 1 elif kernel_size == 5: padding = 2 stride = 2 else: raise ValueError() すべての畳み込みの後にReLUがあるわけではない以前のモデルでは、各畳み込み層の後に nn.ReLU が続いていました。しかし、新しい解像度要件に合わせるために変換層を設計しましたが、その後に nn.ReLU はなく、名前のルールは以前の畳み込みと同じでした。そのため、シミュレーション計算時に以前書いた判断ルールが直接エラーになりました。o(￣┰￣*)ゞDIFF-if quant.startswith('classifier_conv'): +if quant.startswith('classifier_conv') and quant != 'classifier_conv_transfer': x[x < 0] = 0 要するに、今日見つけた2つのバグは、元のコードから移行して何かを追加した結果、判断条件が間違っていたというものです。これらの問題は、最初から拡張性の高いアーキテクチャを設計しない限り避けられないように思えますが、最初から後で発生する可能性のある問題に気づけるでしょうか？研究は製品開発ではないので、しばらくすると新しいアイデアが出てくるため、そこまで考慮するのはさらに不可能に感じます。
研究でのうっかりミス日記2
研究でのうっかりミス日記2
プロジェクトが大きくなるにつれて、元のコードに直接新機能を追加すると本当にバグが増えますね。今日一日で似たようなバグを2つも見つけてしまい、本当に腹立たしいです！
kernel_size と stride は一対一対応していない
以前のコードで定義されたモデルでは、
nn.Conv2dの kernelsize と stride が一対一対応していました。しかし、拡張後のモデルには以前の対応ルールに合わない層があり、kernelsize に基づいて stride を割り当てるコードが直接問題を起こしました。今日突然
assertで shape をチェックしなければ、一生気づかなかったでしょう。すべての畳み込みの後にReLUがあるわけではない
以前のモデルでは、各畳み込み層の後に
nn.ReLUが続いていました。しかし、新しい解像度要件に合わせるために変換層を設計しましたが、その後にnn.ReLUはなく、名前のルールは以前の畳み込みと同じでした。そのため、シミュレーション計算時に以前書いた判断ルールが直接エラーになりました。o(￣┰￣*)ゞ要するに、今日見つけた2つのバグは、元のコードから移行して何かを追加した結果、判断条件が間違っていたというものです。これらの問題は、最初から拡張性の高いアーキテクチャを設計しない限り避けられないように思えますが、最初から後で発生する可能性のある問題に気づけるでしょうか？研究は製品開発ではないので、しばらくすると新しいアイデアが出てくるため、そこまで考慮するのはさらに不可能に感じます。