Writing about Knuth's literate programming book reminded me about when I met him (at a conference) and asked why the following algorithm wasn't in TAOCP. He grasped the algorithm from a ten-second description, and said it wasn't there because he didn't know about it. Good reason.
My TA at university (when I invented it for an exercise) wasn't aware of it either, but unlike Knuth, my TA didn't understand it. And I hadn't commented the code at all. Sigh.
Here are some words in sorted order:
| Decimal | Binary | Word |
|---|---|---|
| 1 | 00001 | name |
| 2 | 00010 | next |
| 3 | 00011 | non |
| 4 | 00100 | of |
| 5 | 00101 | on |
| 6 | 00110 | one |
| 7 | 00111 | other |
| 8 | 01000 | perform |
| 9 | 01001 | piece |
| 10 | 01010 | play |
| 11 | 01011 | reached |
| 12 | 01100 | row |
| 13 | 01101 | same |
| 14 | 01110 | scrambled |
| 15 | 01111 | so |
| 16 | 10000 | software |
| 17 | 10001 | still |
| 18 | 10010 | successful |
| 19 | 10011 | that |
| 20 | 10100 | the |
| 21 | 10101 | this |
| 22 | 10110 | title |
You may observe that the boldfaced digits look like a binary tree. This property can be used to build a binary tree in O(n) given sorted input. Making an empty tree and repeatedly calling its insert operation is already quite fast, probably O(n log2(n)), so you may or may not care about the improvement. If the input happens to be in sorted order, lookups on a regular binary tree will be slow, but a tree built by this algorithm behaves well.
The algorithm:
At the end, n is the root of the tree.
A slight variation of the algorithm can be used to make sure the root has an almost equal number of left and right children.
Another variation can be used to rebalance an existing tree.
Donald Knuth invented literate programming
and published the
TexBook as an
example. The book is great, or so I've heard from many people who've
read it. So why is literate programming is practically unused today,
at least the kind Knuth invented?
(more…)
The TeXbook employs something called literate programming: Knuth wrote code and text together, effectively writing a narrative about that code, with that code as part of the narrative.
Knuth could do that, he's a genius. He was able to write a sizable program practically without bugs, in a note-book. Mortals like myself could not. I'd have to go back and rewrite earlier bits, and before long the narrative would stink. (more…)
The origin of udoc goes a long way back, to when I still was a student at the University of Trondheim, the world's first and only Quasar Toolkit user, and about to start working at Trolltech, which at the time was called Quasar Technologies (Hi Haavard) and occupied a room and a half overlooking a busy street in a rather unfashionable part of Oslo.
I wasn't very happy with the Qt documentation, which was then written using LaTeX macros and already obsolete. I was also an opinionated asshole and far too sure of myself, and I'd just learned about Donald Knuth's literate programming techniques, but I hadn't read his book. Naturally I looked at the existing litprog tools (there were quite a few) before discarding them all to write something good. (more…)