혹시 the art of computer programming 보고계시는 분 계신가요?

알고리듬 설명 뒤에 구현 예제도 포함되어 있나요?
궁금하네요.

책장에 장식용으로 꽂아 놓으면 아주 멋지죠. 8)
다른 허접 쓰레기류의 - 시류에 편승한, 얄팍한... 어찌보면 천박한 - 기술 서적들을 압도하는 위엄을 지닌 아주 멋진 책이죠.
학부 때 필요한 부분만 몇몇 곳을 읽었는데... 책장을 볼때마다 아쉬움을 느끼게 만드네요.

모두 이해했다면 빌게이츠가 자기에게 오라던. ;)

확실히 크누스 교수님과 호로위쯔(?) 교수님의 책은
훌륭합니다. 다만 이해하기 힘들어서 글치요 ㅜ.ㅜ

ps .
책에서나 보던 전웅님을 여기서 뵈니 참 감회가 새롭
군요. 전웅님 책 역시 훌륭했습니다. ^^;

흠.. 편가르기를 하자는 건 아닙니다. :-)

다만, Knuth 의 수학적 background 가 분명 CS 분야 발전에 중요한 역할을
했다는 점을 강조한 것뿐입니다. (사실 Knuth 는 CS 를 또 다른 "수학"
-존재하는 해를 더 빨리 찾기 위한- 이라 생각하고 있습니다)

어차피 당시에는 CS 가 존재하지 않거나 대중화되지 못했겠지만, CS 분야가
Babbage, Knuth, Turing, Von Neumann (알파벳순 ^^) 같은 수학자들의
도움을 많이 받은 건 분명합니다.

굳이 그렇게 단정질 필요가 있을까요?

옛날에는 수학자가 철학자고 미술가며 과학자이기도 했는데....

전산의 뿌리는 수학에 있으니......

그런데 TAOCP를 혼자 마스터하기는 힘들듯한테 저럴바에는 Knuth 제자로 들어가는게 더 낫지 않을까요?

갑자기 왜 수학 이야기가 나오나요?

쓰레드가 좀 틀어지는 것 같습니다.

어쨋든 알고리즘 공부는 정말 중요한것 같습니다.

저도 이제 막 그 책을 시작했습니다.

논문만 마무리 되면 시작하려고 작년부터 벼르고 있었지요.

전 1권만 보려구요. 나머지는 더 공부할 필요가 생길때 봐지겠지요.

Concrete Math 그 책도 사뒀답니다.

아.. 기대되요.. oops

글쎄요.. 튜링머신은 그 자체가 '수학적으로 정의된 계산 모델'인데요..-_-;
오토마타 책 보시면 아시겠지만, 정의는 완전히 수학적으로 되어있습니다.
튜링 머신이라는게 '계산한다'라는 걸 수학적으로 추상화시키려는 노력들에서 나온 계산 모델입니다.
'황제의 새마음'이란 책 읽어보시면 이런 계산 이론에 대한 연구의 역사가 간략하게 나마 나옵니다.
(본래는 AI에 대해 다루는 것이지만.. AI와도 밀접한 연관이 있으니..)
한 번 읽어보시죠.

컴퓨터가 수학적인 모델에 기반을 두고 있다고 이야기를 하는데 CS나 이와 연관된 쪽을 전공하지 않은 분들이 생각하는 수학과 컴퓨터의 기반 모델의 수학이
분야가 다르다는 것을 얘기하고 싶었던 것입니다.
gws님이 너무 일반적인 얘기로 컴퓨터가 수학과 밀접한 연관이 있다고 하셔서 구분짓고 싶어서 한 이야기입니다.
일반적으로 수학이라하면 대수(흠.. 이건 부울대수 때문에 좀 그렇긴 하지만), 기하, 해석학 등을 중심으로 한 고전적인 수학을 떠올릴텐데,
집합론을 필두로 한 현대수학과 논리학 중 컴퓨터의 계산 모델은 현대수학에 기반을 둔 것이다 라는 주장을 하려고 했던 것이죠.

이 스레드의 원래 논제인 알고리즘 분석이나 Knuth 의 책에서 사용하는 수학은 주로 이산수학과 해석학이죠.

저는 소프트웨어 개발을 그림그리기로 생각합니다.

화가가 파스텔, 크레용, 목탄, 붓, 캔바스, 유성물감 등 기본적으로 사용하는 재질에 대한 이해와 그것들을 사용했을 때 어떤 효과가 있고, 주의점은 무엇이고 와 같은 것에서 출발하는 것이,
개발자가 선택하는 언어의 특징은 어떻고, 이 라이브러리는 어떤 형태로 사용하고, 주의해야할 점은 어떤 것이고 하는 것과 무척이나 닮아있다고 생각합니다.

화가가 유성 물감을 익숙하게 사용하게 될때까지 여러 그림을 그려보고 하는 과정을 거치듯이, 개발자도 EJB를 쓴다든가 C++의 STL 을 전면적으로 도입하면서 샘플로 짜보고 튜토리얼도 돌려보고, 삽질도 해보는것이죠.

그림을 그리는 과정이나 소프트웨어를 개발하는 과정은
이러한 기본적인 도구를 사용해서 어떠한 것을 만들어 나가는 과정이죠.

유치원생이나 서투른 화가지망생들이 자기가 그리던 그림을 감당못하거나,
무엇인지 모를 그림을 그리는 것처럼, 개발자도 요구사항을 잘못 이해하거나
숙련되지 못한 여러 새로운 기술을 쓰거나 hype에 휘둘려서 프로젝트를 감당 못하기도 하고요.

어떠한 기능을 구현하는데 필요한 구성요소들을 나누고,
그것들 간의 상호작용방식을 정의하고, 어떤 요소는 직접 개발하고,
어떤 부분은 프레임웍을 따르기로 하고, 어떤 부분은 오픈소스를 쓰고를 결정하고, 그에 따른 결과를 예상하며, 구현해 가는 작업이
무언가를 창조하는 사람의 그것과 다른 점이 있을까요?

네, 사실 이런 논점이라면 무언가를 만들어내는 사람들은 다 창조자입니다.
저는 그렇다고 생각을 하고요.

그리고 실제로 소프트웨어 개발의 많은 부분에서 그림그리기는 아니지만
건축쪽의 메타포를 많이 끌어다 쓰고 있습니다.
소프트웨어 아키텍쳐 라고 하는 '아키텍쳐'가 건축에서 가져온 개념이며,
건축쪽의 Christopher Alexander 의 패턴 관련책은
소프트웨어 패턴 하는 사람들의 궁극적인 바이블로 통하고요.
(아마 읽은 사람들은 많지 않을 것으로 생각됩니다만..)
(직원의 실수였겠지만) 영풍문고에서는 Patterns of Enterprise Application Architecture라는
Martin Fowler 책을 건축학 쪽으로 분류해 놓기도 했었습니다.

덧붙이기는 Cut & Paste 를 염두에 두고 한 말이었습니다.. ㅡ.ㅡ;;

'수학적'이라는 것에 대한 해석은 앞의 amun님께 드린 글과 비슷합니다.
'수학'과 맞서는 말로서 '논리학'을 쓰고 싶었는데,
(올리지 않은 글에서는 "'거칠게 싸잡아서' 수학과 논리학 두가지가 있다고 할때" 라는 표현을 쓰려고 했었습니다만) 오토마타나 계산이론이 논리학도 아닌 듯 싶어서,
컴퓨터에서 기반을 두고있는 (수학적) 모델이 일반인들이 '수학'이라는 것에서
받게 되는 고전적인 모델과는 다른 것이다 라는 말을 하고 싶었습니다.

일본에 번역서가 있습니다. 일본어 공부하시고 보시면 되겠네요. -_-;