우리 아버지는 수학자가 아닌 엔지니어였는데, 선형이 아닌 문제는 전부 Newton-Raphson으로 풀었음
어릴 때 HP85a에서 BASIC으로 Newton-Raphson을 구현하던 게 내 첫 프로그래밍 기억 중 하나였음
나중엔 HP 계산기에서 RPN으로 구현하기도 했고, 아버지의 끔찍한 BASIC 프로그램을 디버깅하기도 했음
아버지는 수치해석 루트 찾기 하나와 2차 미분 계산법만 배워서, 화학공정 엔지니어로서 평생 써먹었음
참고로 관련 문서는 여기에서 볼 수 있음
그리고 아버지는 “결심한 FORTRAN 프로그래머는 어떤 언어에서도 FORTRAN을 쓸 수 있다”는 신념으로 살았음
내가 함께 일한 가장 뛰어난 개발자는 SVD(특이값 분해) 하나로 수많은 선형대수 문제를 해결했음
SVD는 제대로만 쓸 줄 알면 공학 계산에서 정말 강력한 도구임
내 아버지도 엔지니어였고 Fortran을 사랑했음
한 번은 내가 OOP를 설명했더니 “쓸모없다”고 단정하고 다시는 돌아보지 않았음
Newton-Raphson은 Knuth의 명언 “증명은 했지만 실행은 안 해봤다”를 실감하게 하는 알고리즘임
단순한 예제에서는 완벽히 작동하지만, 실제 문제에서는 처참히 실패할 때가 많음
“나는 1000가지 발차기를 연습한 사람을 두려워하지 않는다.
하지만 한 가지 발차기를 1000번 연습한 사람은 두렵다”는 말이 떠오름
Newton-Raphson을 평생 써먹은 아버지에게 딱 맞는 비유 같음
Differential Evolution도 널리 적용 가능한 간단한 기법임
구현도 쉽고, 위키 설명을 보면 꽤 흥미로움
엔지니어들도 각자 문제 해결의 테마가 있는 것 같음
어떤 동료는 늘 가장 단순한 해킹을 찾아냈고, 또 다른 이는 코드 자체를 사랑해서 가장 우아한 표현을 추구했음
전직 물리학자는 늘 마이너한 메일링 리스트를 읽으며 깊이 있는 이해를 쌓았음
나는 문제의 구조를 오래 파고드는 편인데, 결국 문제의 해법보다 그 과정에서 얻은 도구들이 더 유용했음
또 다른 유형도 있음
Reddit에서 본 걸 바로 실험해보는 인프라 엔지니어가 있었는데, 지금은 자산이 5천만 달러쯤 됨
또 다른 엔지니어는 모든 기술을 직접 트레이닝 세션으로 배워 통합했음
그리고 어떤 유명한 엔지니어는 세상에서 가장 훌륭한 주석을 썼음 — 문제, 트레이드오프, 성능, 미완 부분까지 에세이처럼 정리했음
결국 최고의 엔지니어들은 공통적으로 “될 때까지 시도하는” 성향을 가졌음
나는 주로 코드나 파이프라인을 추적(trace) 해서 결과가 어떻게 나왔는지 파악함
특히 결과가 잘못됐을 때 유용함
“Go To Definition” 기능이 가장 강력한 도구라고 생각함
컴퓨터공학 수업에서 느낀 건, 수학은 패턴 인식과 요령이 중요하다는 점이었음
요령을 모르면 진전이 없고, 수업에서도 이런 트릭을 직접 가르쳐주는 경우는 거의 없었음
교수들은 학생이 이미 알고 있다고 가정하거나, 모르면 게으르다고 생각했음
Feynman은 자서전에서 자신이 남들과 다른 수학적 트릭을 가지고 있었기 때문에 성공했다고 했음
흥미롭게도, 그가 자주 쓴 적분 계산법인 Feynman’s trick은 사실 250년 전 Euler가 고안한 방법이었음
관련 설명은 여기에서 볼 수 있음
Feynman은 자기 책을 반복해서 읽으며 “모든 게 여기에 있다”고 말했음
스스로의 이해를 계속 갱신했음
그의 트릭은 대부분 고전적 미적분학 범위에 있었음
화려하진 않았지만, 그 한정된 영역을 완벽히 마스터했음
대학 시절, 교수님이 문제를 설명하다 내가 졸고 있으면 내 이름을 불렀음
나는 잠결에 “중국인의 나머지 정리”라고 답했는데, 90% 확률로 맞았음
대수학 수업이었는데, 그만큼 자주 통했음
한 번은 강의 중 교수님이 문제를 풀지 못했음
잠시 쉬고 연구실로 가서 노트를 가져왔는데, 거기엔 단 한 줄이 적혀 있었음 — “트릭을 써라”
누군가 Tricki.org를 소개했는데, 수학 문제 해결 기법 위키로 꽤 흥미로웠음
지금은 유지보수되지 않지만 여전히 참고할 만함
알려줘서 고맙다는 반응이 있었음. 정말 괜찮은 자료였음
프로그래머에게는 그래프 사고가 매우 유용함
어떤 사람은 SAT도 좋은 트릭이라고 하지만, 나는 직접 써본 적은 없음
SAT, SMT, ILP, MILP 같은 기법들도 함께 언급됨
응용수학에는 이런 농담이 있음 — “우린 Taco Bell 같다. 같은 여섯 재료를 섞어 다른 메뉴를 만든다”
나도 반복해서 쓰는 몇 가지 기법이 있음
결국 세상을 움직이는 아이디어는 몇 개 안 되고, 한 교수님은 “최근 수십 년간 진짜 혁신은 압축 센싱뿐이었다”고 말했음
컴파일러의 어려운 부분은 파서(parser) 임
기존 파서를 찾아서 그 언어의 웹 템플릿으로 출력하면 됨
데이터베이스 쿼리는 역색인(inverted index) 으로 바꾸면 더 낫고,
무엇보다 데이터 지역성(locality) 을 신중히 고려해야 함
Hacker News 의견
우리 아버지는 수학자가 아닌 엔지니어였는데, 선형이 아닌 문제는 전부 Newton-Raphson으로 풀었음
어릴 때 HP85a에서 BASIC으로 Newton-Raphson을 구현하던 게 내 첫 프로그래밍 기억 중 하나였음
나중엔 HP 계산기에서 RPN으로 구현하기도 했고, 아버지의 끔찍한 BASIC 프로그램을 디버깅하기도 했음
아버지는 수치해석 루트 찾기 하나와 2차 미분 계산법만 배워서, 화학공정 엔지니어로서 평생 써먹었음
참고로 관련 문서는 여기에서 볼 수 있음
그리고 아버지는 “결심한 FORTRAN 프로그래머는 어떤 언어에서도 FORTRAN을 쓸 수 있다”는 신념으로 살았음
SVD는 제대로만 쓸 줄 알면 공학 계산에서 정말 강력한 도구임
한 번은 내가 OOP를 설명했더니 “쓸모없다”고 단정하고 다시는 돌아보지 않았음
단순한 예제에서는 완벽히 작동하지만, 실제 문제에서는 처참히 실패할 때가 많음
하지만 한 가지 발차기를 1000번 연습한 사람은 두렵다”는 말이 떠오름
Newton-Raphson을 평생 써먹은 아버지에게 딱 맞는 비유 같음
구현도 쉽고, 위키 설명을 보면 꽤 흥미로움
엔지니어들도 각자 문제 해결의 테마가 있는 것 같음
어떤 동료는 늘 가장 단순한 해킹을 찾아냈고, 또 다른 이는 코드 자체를 사랑해서 가장 우아한 표현을 추구했음
전직 물리학자는 늘 마이너한 메일링 리스트를 읽으며 깊이 있는 이해를 쌓았음
나는 문제의 구조를 오래 파고드는 편인데, 결국 문제의 해법보다 그 과정에서 얻은 도구들이 더 유용했음
Reddit에서 본 걸 바로 실험해보는 인프라 엔지니어가 있었는데, 지금은 자산이 5천만 달러쯤 됨
또 다른 엔지니어는 모든 기술을 직접 트레이닝 세션으로 배워 통합했음
그리고 어떤 유명한 엔지니어는 세상에서 가장 훌륭한 주석을 썼음 — 문제, 트레이드오프, 성능, 미완 부분까지 에세이처럼 정리했음
결국 최고의 엔지니어들은 공통적으로 “될 때까지 시도하는” 성향을 가졌음
특히 결과가 잘못됐을 때 유용함
“Go To Definition” 기능이 가장 강력한 도구라고 생각함
컴퓨터공학 수업에서 느낀 건, 수학은 패턴 인식과 요령이 중요하다는 점이었음
요령을 모르면 진전이 없고, 수업에서도 이런 트릭을 직접 가르쳐주는 경우는 거의 없었음
교수들은 학생이 이미 알고 있다고 가정하거나, 모르면 게으르다고 생각했음
Feynman은 자서전에서 자신이 남들과 다른 수학적 트릭을 가지고 있었기 때문에 성공했다고 했음
관련 설명은 여기에서 볼 수 있음
스스로의 이해를 계속 갱신했음
화려하진 않았지만, 그 한정된 영역을 완벽히 마스터했음
대학 시절, 교수님이 문제를 설명하다 내가 졸고 있으면 내 이름을 불렀음
나는 잠결에 “중국인의 나머지 정리”라고 답했는데, 90% 확률로 맞았음
대수학 수업이었는데, 그만큼 자주 통했음
한 번은 강의 중 교수님이 문제를 풀지 못했음
잠시 쉬고 연구실로 가서 노트를 가져왔는데, 거기엔 단 한 줄이 적혀 있었음 — “트릭을 써라”
누군가 Tricki.org를 소개했는데, 수학 문제 해결 기법 위키로 꽤 흥미로웠음
지금은 유지보수되지 않지만 여전히 참고할 만함
프로그래머에게는 그래프 사고가 매우 유용함
어떤 사람은 SAT도 좋은 트릭이라고 하지만, 나는 직접 써본 적은 없음
응용수학에는 이런 농담이 있음 — “우린 Taco Bell 같다. 같은 여섯 재료를 섞어 다른 메뉴를 만든다”
나도 반복해서 쓰는 몇 가지 기법이 있음
결국 세상을 움직이는 아이디어는 몇 개 안 되고, 한 교수님은 “최근 수십 년간 진짜 혁신은 압축 센싱뿐이었다”고 말했음
컴파일러의 어려운 부분은 파서(parser) 임
기존 파서를 찾아서 그 언어의 웹 템플릿으로 출력하면 됨
데이터베이스 쿼리는 역색인(inverted index) 으로 바꾸면 더 낫고,
무엇보다 데이터 지역성(locality) 을 신중히 고려해야 함