컴파일 에러라든가, 잘못된 메모리 건드려서 프로그램이 죽어버리는 오류는 차라리 쉽다. 컴퓨터도 알 정도인 컴파일 에러는 오타가 대부분일테고, 메모리 잘못 건드려서 죽는 건 대충 어딘지 감이 오니까 쉽게 디버깅 할 수 있다. 문제는 논리적 오류, 프로그램이 죽지도 않고, 결과가 나오긴 했는데, 잘못된 결과가 나왔을 때. 가령, 100개 중 98번째 것만 잘못된다던가, 뭐, 그런 경우. 얼마 전에 이와 비슷한 에러가 있었다.
위와 같은 그림이 만들어 져야 하는데, 계속 저 제일 큰 검은, 둥근 모서리의 사각형이 너무 왼쪽에 그려진다. 실제로는 왼쪽이 잘려 나간다. 처음에는 내가 원본 데이터를 축소하면서 뭔가가 잘못 되어서 잘린다는 느낌이 들었다. 그래서 저 때 변형한 수식을 다시금 곰곰히 되살펴 보았다.
자꾸만 안되서, 중간에 암산으로 했던 부분까지 모든 단계를 차근차근 다 다시 계산해 봤다. 그런데, 그래도 역시나 식이 틀리지는 않았다. 그런데, 최종적으로 나온 수식을 보니, 특정 조건에서는 저렇게 잘릴 수 있다는 결론에 도달할 수 있다. 부등호가 성립하지 않는 조건이 나올 수 있는 것. 그래서, 아, 그래서 그랬던 거구나, 하고 일단은 납득. 그런데, 조금 더 생각해 보면, 직관적으로 생각했을 때 그림을 늘이거나 줄일 때 그 위에 있던 도형의 일부가 늘거나 줄어든 그림 밖으로 밀려나지는 않는다. 그렇게 되도록 수식을 작성했던 것이다. 그래서, 다시 뭐가 문제인가 곰곰히 살펴 보았더니, 사각형의 테두리를 갖고 최대/최소를 구해야 했는데 나는 중심점을 갖고 최대/최소를 구했기 때문에 특정 사각형의 폭만큼이 잘못 계산되었고 결국 그만큼이 잘려 나갔던 것이다. 그래서 코드를 살짝 수정하니, 지금은 잘 나온다. 아, 역시나, 이런 논리적 에러를 잡는 것이 항상 제일 어렵다, 멀티쓰레딩을 제외하면. 이것 때문에 거의 몇 시간을 써야 했다.
위와 같은 일은 얼마 전에 있었던 것이고, 지금은 자잘한 부분들을 손을 보아서 결과물이 그래도 그럴듯 하게 그려진다, 예~~. 난 이것을, 내가 지금 하는 연구의 한 결과물을 표현하기 위한 것으로만 생각하고 오늘 발표를 했는데, 교수님과 랩사람 몇 명이, 이거 좋다, 이것도 해보자, 한다. 여태까지 니가 한 것 중에 알아들을 수 있는 유일한 건데, 라고 한 사람도 있고, ㅋㅋㅋ. 생물학 랩에서 전산과수학을 버물여서 연구를 하기 때문에 사람들이 내 연구를 이해하기는 좀 힘들긴 하다. 뭐, 어쨌든, 내가 봐도 생물학 하는 사람 입장에서 이것은 직관적으로 와 닿기 때문에 괜찮아 보인다. 이럴 의도는 아니었는데, 의외의 소득, 교수님은 아예 이걸로 논문 하나 쓰라고까지 말씀하신다. 두 명 한테서 같은 얘기를 들었으니 어디 한 번 해볼까나.
