The Art of Computer Programming
Well, Volume 4 was released in 2016 and is not out of date at all. Its a very good read, but on an obscure subject. But Volume 1 has lots of out-of-date advice and is somewhat of a shame, because its otherwise an excellent introduction to computing + the mathematics needed to understand computing. For example, the assembly language is based on the 1960s computers, such as decimal computing and 6-bit numbers (based on the days of old, before 8-bits were standardized). Functions are introduced by self-modifying code first and foremost: by rewriting "jump" instructions at the end of functions…
Part I In all my career in computing and related work, I've participated in interviewing for hiring and evaluating the candidates, and I hope to be hiring next year. So, would I take that 'matrix' seriously in hiring? Not really! Looking back, some of my thoughts on hiring were wrong! I suspect that using that matrix would also prove to be not very good! Some of the stuff in the matrix is okay to know but, really, next to trivial to learn: E.g., early in my career I skimmed through all three of Knuth's three volumes of 'The Art of Computer Programming' and studied fairly carefully his…
To my down-voter: TAOCP is essential foundation to understand the whys and wherefores of writing good code at any higher level; one must understand the mechanics and limitations of the systems one is using. Hoping for Moore's Law to save your performance is not the way to do things. Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed…
At the time it was a revelation. And I did too read all. I guess I'm no-one then, by your standards. I'd warrant you never read a dictionary in your childhood either. No-one. Well then. Creds are perhaps in order. So, now - 50 years experience, still working, very senior level tech equivalent to management, hardware and software designer from transistor days through graphical programming platforms. I started at the bit level and grew from there alongside the technology, all the way. Still surfing it. At this age I think that stands for something. If I were no longer working or able to cut…
Indeed! Here is Sudoku, formulated as a SAT problem. You can use for example SICStus Prolog to run it: sudoku(Rows) :- length(Rows, 9), maplist(same_length(Rows), Rows), maplist(row_booleans, Rows, BRows), maplist(booleans_distinct, BRows), transpose(BRows, BColumns), maplist(booleans_distinct, BColumns), BRows = [As,Bs,Cs,Ds,Es,Fs,Gs,Hs,Is], blocks(As, Bs, Cs), blocks(Ds, Es, Fs), blocks(Gs, Hs, Is). blocks([], [], []). blocks([N1,N2,N3|Ns1], [N4,N5,N6|Ns2], [N7,N8,N9|Ns3]) :-…
So the title starts "The books ...", and reading the article shows that by books they mean just fictional novels. but, the books we talk about on HN have included: Knuth, The Art of Computer Programming. Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein, Introduction to Algorithms. Jeffrey D. Ullman, Principles of Database Systems. Jacques Neveu, Mathematical Foundations of the Calculus of Probability. David G. Luenberger, Optimization by Vector Space Methods. Brian W. Kernighan and Dennis M. Ritchie, The C Programming Language. Robert Sedgewick and Kevin…
> How often do you find yourself needing to deeply understand the sort of "low-level" algorithms that "The Art" is about? I rarely find myself needing to understand the "low-level" algorithms that "The Art" book talks about. This is because I don't typically work at that level in my professional or personal projects. In fact, most of my personal projects involve functional languages, where I prefer to work at the highest level possible. While understanding low-level algorithms can be useful in certain contexts, it's not a priority for me in my day-to-day work. > How interested are you in…
a love letter to the art you can roughly split the art of computer programming as currently written into ten major arcs, each around 300–400 pages (including the answers to exercises): 1 introduction (math prerequisites, assembly programming) 2 data structures (lists, stacks, queues, trees, memory allocation, etc.) 3 random numbers (generating random numbers, testing for randomness) 4 arithmetic (floating points, polynomial arithmetic, etc.) 5 sorting 6 searching (comparisons, hashing, etc.) 7.1 binary tricks (includes binary decision diagrams) 7.2.1 generating combinatorial…
Beyond contributing to the change in my thinking over the past year, I'm not going to suggest that any of these books changed my life in the way that the Bhagavad Gita or Leviathan or Foucault's Pendulum might. Particularly since these are Computer Science related per the RFP. Anyway: 1. Art of Computer Programming: Combinatorial Algorithms, Volume 4a. This stuff is hard. It's harder than I can imagine. [It's worth noting that this probably clarifies my definition of "read", since I've only read a little bit of it so far and only really grokked a little bit of what I read]. 2. Programming…
Donald Knuth's The Art of Computer Programming has, in its first volume, a lengthy section on simulating an elevator. It is a single regular elevator (nothing "special" going on as in the post here), but even so, as he tries to make things precise, you realize how much detail is involved, and get some appreciation for the task of programming. It occupies about 15 pages (plus several pages of exercises and solutions). Knuth started working on TAOCP when he was a PhD student at Caltech: > The program developed below simulates the elevator system in the Mathematics building of the California…