Acton’s book is an entertaining read, but how well has it stood up? Computing power and software have advanced so much in the 40 years since he wrote it, it’s not clear that the cautionary tales he tells are still as relevant. He might tell you a story of how 20 minutes of thought could have saved an investigator 20 hours of computing time. Now however, that same computer program, or a more robust off-the-shelf one, might run in a couple of seconds. So why think? ;)

You could argue that the complexity of problems has grown as computing power has grown, so that thought is as necessary as ever. However, I might counter that more complex problems are difficult to tackle in the way the problems in Acton’s book can be tackled. Don’t the problems in Acton’s book seem rather… quaint?

I think if I were going to recommend a book for learning practical, hands-on numerical computing, I would recommend Numerical Recipes.

I think the principles in Acton’s book are still valuable, though the specifics are outdated. For example, most computing is now done in double precision rather than single precision. Loss of accuracy still happens when you’re not careful; you see the same problems but for a smaller range of inputs.

Acton doesn’t deal with sorting, but bubble sort is still slower than heap sort, even though both are instantaneous for small data sets. The idea of what is “small” has changed over time, but the principle remains.

However, there is one important area that Acton doesn’t address at all if I remember correctly, and that is random methods: random number generation, Monte Carlo integration, etc. These methods have become far more common in practice (at least in my practice :)).

There is a nice battery of tests ready to go in C++. If the RNG makes it through that in good shape, great.

One kind of disturbing aspect of the chapter is that its existence implies software developers should be going off and writing their own RNGs. Why bother when there are good ones out there that have been through very rigorous scrutiny?

The problem with plotting random data, especially uniform data, is that we can’t visually detect any meaningful flaws in the data.

Jason: I don’t want to encourage anyone to develop their own uniform random number generation algorithm. But some people will need to implement existing algorithms in new languages. And even more people will need to transform a uniform random sequence into a sequence with another distribution, maybe a distribution unique to their problem.

Even though, this post is no longer a current subject of discussion. I write to appreciate your efforts in putting together a collection of numerical gems in this blog. I have benefitted quite a lot from this blog. Remain blessed.

I share your love of Acton’s book and Steve’s recognition that it is, in some respects, outdated. I like Acton’s mindset of thinking about what you are trying to calculate and being willing to find different algorithms when you are up against the potential for or reality of catastrophic loss of precision. The original book had the title embossed into the red cover, with the letters highlighted in silver. Also embossed, but not highlighted, was the word “usually”. Lovely.

Just came across this link from the CompSciFact twitter account. Are you aware of the typo in the first footnote on page 131? The word “lest” should be “least”, I believe. I know this is a few years old, so maybe it’s not helpful now.

I’m reminded that sometimes, even though you may THINK you want random, it may not be what you want. From this tweet from earlier today, what the tweeter really wants is “random, or even a cheap approximation, unless the current entry has come up TOO recently:” “iPad, I appreciate your shuffle. I do. And you know I like Enya “The Longships.” But not as every third song. #shuffleparalysis”

And I hope I’m not too much of an insufferable pedant in pointing out that this is about testing pseudo-random number generators (PRNG) – a “true” random number generator will (almost?!) always pass such tests.

I’m disappointed not to see more than a brief mention of the different needs for random number generation for cryptography, given the number of cryptosystem failures that happen when people use inadequate RNGs.

(Even just a sentence in bold-face all caps about never mistaking good distribution properties for cryptographic unpredictability would have helped :-)

That’s a can of worms I chose not to open. My chapter only deals with one aspect of random number generation, transforming a uniform distribution into the distribution you need, because that’s the most common task. I’ve since written a series of blog posts on how to test the core uniform generator, though that’s very different. And I lightly touch on cryptographic applications in a few posts.