에잇, 그냥 할 껄,

괜히 꾀부리다 결국 알아낸 것은 원래 하려던 것이 더 빠를 것이라는 것.

논문을 쓰다 보니 다시 한 번, 이번에는 좀 더 방대하게 계산해야 하는 것이 생겼다. Pearson's correlation coefficient 를 계산하는 것인데, 말 그대로 정말 볓 백만번도 넘게 계산해야 한다. 지난 번에 이것 계산하는데 3일 정도 걸렸었는데, 이번에는 데이터 양을 급격히 늘려야 하기 때문에 어쩌면 엄청나게 오래 걸릴지도 모르기 때문에 속도 개선에 돌입. 코딩 전에 우선 좀 더 빠르게 하는 방법이 없을까를 궁리하다가 생각이 난 것은 correlation theorem. 그래, FFT 가 무지하게 빠르다니까 어디 되나 볼까 해서 인터넷좀 찾고 해서 (PCC랑 correlation theorem 을 같이 써 놓은 글은 안 보인다, 짱구를 살짝만 굴리면 되기 때문에 명시적으로 쓰여 있는 문서는 없는 듯) matlab 으로 잘 먹히나 확인해 봤다.

잘 맞는다, matlab 이 잘 돌아간다기 보다는 내가 생각한 것이 틀리지 않는다는 의미로, ㅋ. 난 이렇게 proof-of-concept, 즉 아이디어를 확인하는 차원일 때는 matlab 이나 R, excel, maple 등의 프로그램을 사용하고, 잘 맞는다 싶으면 구현에 들어가곤 한다. 어쨌든 잘 맞아서, 이번에는 그럼 계산횟수가 얼마나 되나 fast fourier transformation 에 관련한 글을 읽어 봤다. N log N 이라... 그것 뿐만이 아니라, fft는 미리 계산해 놓는다 쳐도, 두 개의 fft 를 곱해서 inverse FFT 시켜야 하는데, 이 곱하기 연산에 이미 N 번의 계산이 들어가 버린다. 그런데 내가 원래 하려던 방법은, 그냥 단순무식하게, 두 개의 데이터 d1 과 d2 에 대하여, sum(d1), sum(d2), var(d1), var(d2) 를 미리 계산해 놓으면 매번 계산해야 하는 값은 d1*d2 (* 는 convolution) 인데, 이것도 N 번의 계산만 필요로 한다, 지금은 그냥 inner product 이니까. 그렇다면 굳이 N log N + N, 뭐 결국 N log N 이지만, 여하튼 괜히 fft 까지 써가면서 할 필요가 없던 것. 아, 뭐야... 그냥 코딩이나 할껄.

   그런데 이런 경우가 꽤 많았다. 혹시나 해서 막 해 보았지만 결국 결론은 안되는 것으로 나버리고, 그래서 나중에 결과 말할 때는 말하지 못하게 되는. 랩후배한테도 얘기하기를, 내가 "이거 되요, 라고 말하면, 다른 것 한 대여섯가지 시도해 보았는데 그런 것들은 안 되더라구요, 가 생략된 거야", ㅋㅋㅋ. "이건, 뭐, 원래 그런 거니까 너무 안된다고 실망하지 마라", 라고. 정말이다. 꽤 여러 가지 시도를 해 보았지만 결국 의미없는 것으로 판결이 났기 때문에 결과를 말할 때는 그러한 시도들은 얘기하지 않게 될 때가 많다. 그러니까, 애써서 데이터를 분석한 방법이 의미없는 것으로 판명이 난다 해도 별로 대수롭지 않은 일, 병가지 상사거든, ㅋ.  에리뜨!였다면 그러한 시행착오를 미연에 방지할 수 있었을까? 모르겠다, ㅋ, 어쨌거나 쓰이지 않는 시도들도 결국은 경험으로 남게 되는 거니까. 내가 Lokta-Volterra equation 이란 것을 알게 된 것처럼. 뭔가 있다는 그 자체를 아는 것이 어떨 때는 그것을 어떻게 하는지 구체적으로 아는 것보다 중요할 때가 있다. 그 구체적 방법이야 차근차근 시간 내서 배우면 되는 것인데, 그러한 방법 자체가 있는지 없는지조차 모른다면 아예 시작조차 못하겠지. 내가 생각하는 경험의 가치란 바로 이렇게 어떤 것이 있다는 것을 알게 되는 것 그 자체이다. 있는지조차 모르면 찾지도 못하거든.