Live data from Hacker News

A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

kolja.rs

31–40 of 55 posts

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#31

Nice work! I don't find all implementations using "while" or "goto loop" surprising though. "Now test if q̂ ≥ b or q̂·vₙ₋₂ > b·r̂ + uₙ₋₂; if so, decrease q̂ by 1, increase r̂ by vₙ₋₁, and repeat this test if r̂ That clearly a while loop. Lather, rinse, repeat.

I beg to differ.

A loop would also call for additional run-time analysis. And Knuth changed Step D3, if it were a loop he wouldn't have had to. Additionally, there is no loop in Program D, his implementation of Algorithm D in MIX.

If you read the whole chapter and not just the statement itself (though I'd argue the statement is enough), it's very clearly two if's.

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#32
post #20

That is so cool. Exceptional work, friend. That makes this thread a bit more interesting now. https://stackoverflow.com/questions/60479571/is-there-a-bug-...

Thank you! Indeed it's the infamous Step D3. In my opinion, with the new changes and the new Theorem B, this step will feel more natural, because it's essentially extending the 2/1 division into a 3/2 division.

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#33
A story from my life about not judging a book by its cover...and Algorithm D:

Some years after the turn of the millennium I was a CS student at UC Santa Cruz. I was taking various classes for my major and I ended up in a Comparative Programming Languages class, which was a quarter-long survey of different modalities - I remember Haskell, OCaml, C++, and there were maybe two others.

Anyway I had started noticing a particular student showing up in some of my classes. He stood out. Firstly because he was always asking questions, sometimes to the point of annoying other students. And then because he was older than the rest of us - in hindsight he probably wasn't older than his early 40s - but I was ~20 and as I came to learn, he'd lived hard. He had a stout, platinum blonde beard that seemed yellowed from the hand-rolled cigarettes I always saw him smoking outside the computer lab.

After class one day I started chatting with him. I wasn't much of a question-asker, and I found his willingness to do so in the face of obvious annoyance to actually be kind of brave, so I think I probably opened by complimenting him and asking if the reactions from other students bothered him. His answer, gravely-voiced, was clear: he was paying for these classes same as anyone else, and he wanted to get his money's worth. I found it a refreshingly self-centered take. I decided I liked the guy.

Over time we became lab-mates, working on projects together. He always reeked of tobacco; his fingers too were yellowed from those rollies. I learned that he'd never finished college his first time around, instead getting hired into industry and riding the wave of the dot-com boom. When the crash eventually landed, he washed out and found himself living the surf bum life in Mexico, soaked in alcohol and seawater. When he eventually decided he had to get his life together, he sobered up and moved back to the States. But he was unemployed, homeless - living out of his VW van - and a 40-something college student. He was a misfit.

So, let's see..right, Algorithm D. So for our Comparative Languages class, the OCaml project was an arbitrary-precision calculator. We worked through addition, subtraction, and multiplication, and then as the project deadline approached we turned our sights towards division. Me, I took one look at Knuth and decided to start instead with a brute-force implementation. But once that worked, we began tackling Algorithm D. Around 2am, still not done, I threw up my hands and said I was going home - I'd take whatever grade was coming. My partner also went home - to his van parked in the Engineering lot. I knew he didn't own his own computer, so imagine my surprise when I saw him the next day and he told me he had finished the Algorithm D implementation overnight.

Turned out he had gone back to his van that night with a pen and a ream of paper and worked the code out by hand, only typing it up in the morning. We were lab partners but I wasn't going to copy something I'd had no hand in; I got whatever grade I deserved and he got the perfect score. I'm sure the older heads have plenty of stories of coding by hand, but even by that time, circa 2005, such a thing seemed arcane, almost unheard of. I was duly impressed.

I occasionally wonder what happened to him - he was a smart guy and a good engineer, and I learned some important lessons from him. I hope he found his footing. And for the sake of his cubicle mates, maybe also kicked the cigarette habit.

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#34

Congratulations! It's funny that the reward schedule is not based on importance. It's just 0x$1.00 for an error and 0x$0.20 for a suggestion, no matter what. Personally I have 0x$4.40 in the bank, more than the author's 0x$1.00, but none of my four errors and two suggestions were as important as this one. Getting your name in the book is pretty cool though! This bug is only in the English description of the algorithm…

Thank you!

Honestly, while waiting for the check I wondered what it would be, and 0x$1.00 feels just right. The name in the book came unexpectedly, it's really a reward on its own.

No bug in MIX, and there is no MMIX implementation yet. The transition of the first three volumes from MIX to MMIX is still far ahead. The MIX program actually implements Step D3 differently from what's written in Algorithm D, and this implementation, more aligned with 1st and 2nd editions of the book, avoids the error. The bug is due to a 1995 change in the trial quotient computation (that from my perspective came as part of a transition to MMIX). This broke correctness of Theorem B, which then led to overflows post Step D3 (in only one peculiar, rare, odd case).

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#35

This may very well be the most epic post in HN history. EDIT : I recall fondly algorithm D... one of my first programming experiences in the 90s was trying to implement knuth's arithmetic algorithms for addition, substraction, etc. in 8086 asm. Got them right up until long multiplication (that one was a tremendous effort). Algorithm D was too formidable to even dare me attempt. Feel extremely happy to see people in 2…

Thank you, i'm flattered!

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#36
post #2

I found a bug in Algorithm D, the long division algorithm in Knuth's "The Art of Computer Programming". It was discussed on HN a couple of times https://news.ycombinator.com/item?id=26562819 as well as on other websites. I sent a letter to Knuth and received a check and an annotated reply. The updated Theorem B, which was unchanged since 1969 is now dated 2026. While searching for vulnerable implementations I also fo…

Wow, congratulations on finding this most epic bug!

Thank you!

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#37

Nice work! I don't find all implementations using "while" or "goto loop" surprising though. "Now test if q̂ ≥ b or q̂·vₙ₋₂ > b·r̂ + uₙ₋₂; if so, decrease q̂ by 1, increase r̂ by vₙ₋₁, and repeat this test if r̂ That clearly a while loop. Lather, rinse, repeat.

I beg to differ. A loop would also call for additional run-time analysis. And Knuth changed Step D3, if it were a loop he wouldn't have had to. Additionally, there is no loop in Program D, his implementation of Algorithm D in MIX. If you read the whole chapter and not just the statement itself (though I'd argue the statement is enough), it's very clearly two if's.

In the edition here (I also have a legal hard copy but not with me)...

https://www.scribd.com/document/956350280/The-Art-of-Compute...

... on page 274 the MIX jumps in lines 058 and 060 to label 3H if the tests fail, where qhat is decremented again. I'm not at all a Mix expert, but where is the counter that the loop is only executed twice?

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#38
post #20

That is so cool. Exceptional work, friend. That makes this thread a bit more interesting now. https://stackoverflow.com/questions/60479571/is-there-a-bug-...

Wow I had forgotten that I had answered that question on StackOverflow!

So at the time my conclusion had been that there was no mistake (interpreting the "repeat" as a loop), but it's arguable… maybe if the person who posted the question had asked Knuth instead, he'd have had a reward check?

Re: A decades-old bug in Knuth's long division (TAOCP Vol II, Algorithm 4.3.1D)

#39
post #33

A story from my life about not judging a book by its cover...and Algorithm D: Some years after the turn of the millennium I was a CS student at UC Santa Cruz. I was taking various classes for my major and I ended up in a Comparative Programming Languages class, which was a quarter-long survey of different modalities - I remember Haskell, OCaml, C++, and there were maybe two others. Anyway I had started noticing a par…

What a lovely story
Post reply on HN