연구 중 바보짓 기록 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
프로젝트 규모가 커지면서 기존 코드에 새로운 기능을 추가하면 정말 점점 더 많은 버그가 생기네요. 오늘 하루 동안 비슷한 버그 두 개를 발견했는데, 정말 짜증 납니다!
kernel_size와 stride가 일대일 대응되지 않음
이전 코드에서 정의한 모델에서는
nn.Conv2d의 kernelsize와 stride가 일대일로 대응했습니다. 하지만 확장된 모델에는 이전에 작성한 대응 규칙에 맞지 않는 레이어가 하나 있어서, kernelsize에 따라 stride를 할당하는 코드가 바로 문제를 일으켰습니다.오늘 갑자기
assert로 shape을 확인하지 않았다면 아마 평생 발견하지 못했을 거예요.모든 컨볼루션 뒤에 ReLU가 있는 것은 아님
이전 모델에서는 모든 컨볼루션 레이어 뒤에
nn.ReLU가 따라붙었습니다. 하지만 새로운 해상도 요구 사항에 맞추기 위해 변환 레이어를 설계했는데, 그 뒤에는nn.ReLU가 없고 이름 규칙은 기존 컨볼루션과 동일합니다. 그런데 시뮬레이션 계산 시 이전에 작성한 판단 규칙이 바로 오류를 일으켰습니다. o(￣┰￣*)ゞ어쨌든 오늘 발견한 두 버그는 모두 기존 코드를 가져와서 뭔가 추가했는데 판단 조건이 잘못된 경우였습니다. 이런 문제는 처음부터 확장성이 좋은 아키텍처를 설계하지 않는 한 피할 수 없는 것 같아요. 하지만 처음부터 나중에 생길 문제를 어떻게 예상할 수 있을까요? 연구는 제품 개발이 아니고, 시간이 지나면 새로운 아이디어가 떠오르니까 더더욱 그렇게까지 고려하기 어려운 것 같습니다.