191–200 of 357 posts
Note that, to get an idea of the contents, you can see the previously published fascicles, and earlier drafts online (pre-fascicles): • Mathematical Preliminaries Redux: https://cs.stanford.edu/~knuth/fasc5a.ps.gz • 7.2.2 Introduction to Backtracking: https://cs.stanford.edu/~knuth/fasc5b.ps.gz • 7.2.2.1 Dancing Links: https://cs.stanford.edu/~knuth/fasc5c.ps.gz • 7.2.2.2 Satisfiability: https://cs.stanford.edu/~knut…
[flagged]
Well, what happened was that he spoke for nearly two hours on self-referential aptitude tests. The kind of "20 questions" game where the 20th question is "The maximum score obtainable on this test is (a) 18 (b) 19 (c) 20 (d) indeterminate (e) achievable only by getting this question wrong" and all of the others are inherently recursively linked. I had no idea these things existed, even less of an idea why anyone would want to study them, and came away later with both mind dripping down the side of my skull and a greater appreciation of SAT solvers and compiler design in functional programming languages. Highly recommended.
(And if anyone wants to do the quiz, it's here: [1] https://www-cs-faculty.stanford.edu/~knuth/paradox.pdf)
Can someone honestly tell me if they have actually read these books AND found them useful ON TGE JOB? What do you guys do for work? I tried reading part 1?? Like ten years ago and it was pretty much assembly language or something I believe. And gave up since it wasnt something that I needed in academia back then and there were far better ways to learn DSA
One job involved indexing arbitrarily large books (gigabyte+ was not uncommon) on an embedded CPU with less than 1MB of RAM available to the indexer (this is 15+ years ago, before smart phones). It also involved searching hundreds of those books in a few seconds with ~8MB of RAM available. Indexing was taking place on a single core CPU while the user was using the device, so the indexer had to be able to stop its work within a few milliseconds of any user action and resume later without losing progress. On the surface, Knuth's concepts felt old fashioned (abstract assembly language and talk of multiple tape drives for intermediate storage). But that mapped very well onto this indexing problem. Books and indexes resided on an SD card and individual files on the SD card could act very much like Knuth's individual tape drives. Doing append only operations on those files (as you would want to do on a tape drive) proved fast and reliable. My 1MB of RAM would have been an embarrassment of riches when the original volumes of TAOCP were released. I don't remember if any of the algorithms that shipped as part of that device were straight out of TAOCP, but the thinking involved was heavily influenced by those books. Whenever I was stuck, it was back to Knuth.
My next job was focused on distributed systems. We were rebuilding an ads system because the older one couldn't handle the scale needed. That involved lots of MapReduce and lots of stream processing (before there were good open source stream processing packages to build on top of, this started in 2010). Those same tape drive oriented algorithms came right to the surface again. When processing TB or PB of data, you want single pass algorithms wherever you can come up with them - merely linear isn't good enough. Same as tape drives - there's a huge benefit if you can avoid having to rewind. And so many stream processing primitives (windowed joins, groupings, etc.) are exactly what people were doing with tape drives 50 years ago. Now we were using many GBs of RAM spread across many machines, but relative to the amount of data being processed, it was still miniscule.
This all required spotting the similarities between the world Knuth drew his examples from and the constraints I was working under. But once I did, his concepts were quite useful. And the framework for thinking about things was more valuable to me than any specific algorithm or data structure. It was much more useful to me as a narrative to read rather than a reference to pull something out of.
Note that, to get an idea of the contents, you can see the previously published fascicles, and earlier drafts online (pre-fascicles): • Mathematical Preliminaries Redux: https://cs.stanford.edu/~knuth/fasc5a.ps.gz • 7.2.2 Introduction to Backtracking: https://cs.stanford.edu/~knuth/fasc5b.ps.gz • 7.2.2.1 Dancing Links: https://cs.stanford.edu/~knuth/fasc5c.ps.gz • 7.2.2.2 Satisfiability: https://cs.stanford.edu/~knut…
[flagged]
It's used by many to perfect their craft.
A few years ago I had the pleasure of meeting Knuth in his home, my wife was doing some photography for him. He took me to his room and showed me his setup, he was researching Soduku algorithms at the time. His hands were blisteringly quick, moving between EMacs panes, triggering evaluations and printing of results, as fast as any 20 year old. In his 80s , he hasn’t seemed to suffer any mental decline. I started talk…
Well, the editor wars are over folks.
More seriously, Don Knuth is a treasure. One of the coolest things about computing science is how all the greats in the field are either alive, or within the living memory of people who are.
Earlier quoted context omitted.
He's already well over the avg life expectancy for American men. But hey, good genes exist and it's possible he's got another 20 lucid years.
The average age is from birth. What’s the expected age having lived to be 84? People can live well into their 90’s. Hopefully he’s got another book in him. These people are still alive, for example: Jimmy Carter: 98 Henry Kissinger: 99 Warren Buffet: 92 Charlie Munger: 98 Mel Brooks: 96 Alan Greenspan: 96 Noam Chomsky: 94 in December
~50% of 84-year-old men will die by age 90.
~0.4% of 84-year-old men will live another 20 years.