I liked this – exhaustive testing of 32-bit floating point math is practical.

http://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/

The random library introduced in Boost, put into TR1, and now part of C++11, is awesome. This is one of the must-use bits of the C++ Standard Library. It’s solid and pretty fast. My recommendation is that, unless you are really an expert, you use <random> for your random number needs, and be done with it.

The 10-second introduction to the theory of <random>

Engines are sources of random numbers; an engine returns unsigned integer numbers uniformly distributed in a range between a predefined min and a predefined max. Typically, this is the min and max of the unsigned integer range.

engine e;
v = e();

Distributions turn the uniformly distributed values into a desired distribution; linear, normal/gaussian, exponential, gamma, Bernouilli, etc.

dist d;
v = d(e());

That’s it! Well, the devil is in the details, but the details aren’t much more daunting than that – you need to pick an engine and a distribution, and you probably want to seed the engine, and you may need to worry about thread-safety. And of course, the standard uses much longer names than engine and dist.

Oh, and always use a distribution. It will do the mapping of random integers into your desired range properly.

A list of references to <random>

Random Number Generation in C++11 is the proposal to put <random> in the C++11 standard library. It’s also pretty readable. It has good sample code. If you’re going to read one thing on <random>, read this, because it clearly explains what engines are and what distributions are.

The C++ Standard Library: A Tutorial and Reference, Second Edition, by Nicolai M. Josuttis, has a chapter on <random> that’s pretty good.

Peter Seibel wrote a piece this past weekend on code reading – or rather, challenging it:

Code is not literature

I have to disagree. Or rather, I feel like he’s describing our current (defective) world, and taking it as a given that it’s how things should be.

Most code is unreadable. That is not a good thing, because it blunts or prevents one of the two major ways that you get better at something.

One way to get better is to just do it. And in fact, you will never get better at something unless you do it – you can theorize or otherwise gather information all you want, but that won’t help you when it comes to performing. However, there’s a limit to learn-through-doing, and that is that there’s just you, and you can only try so many things.

The other way to get better is to learn from others. Sometimes, but rarely, you can learn from them in person. But this doesn’t scale, so most learning is done through studying the output of others. You examine architecture, you deconstruct art, you read books.

It’s actually a shame that you need to decode programs in order to learn from them. While there is something to be said about the effort you put into learning something, it should not be herculean unless the payback you get is equally large.

In the past few years, I find myself rewriting programs to make them easier to read. I do this for myself, because I’ve found that I quickly forget exactly what I was doing, and if I have a hope of picking something up months or years later, I need to be able to read it. Fortunately, the same effort to make it more readable also makes it easier to work on, so it’s not lost effort.

And one thing really struck me, and that was the complaint that “in order to understand code, I have to rewrite it.” That is not a complaint, that’s a description of every other learning activity I’ve seen. If you want to really understand how a writer writes, you try to write in their style. For an artist with phenomenal skill or technique, you paint like them so you can learn it.

You don’t really understand something until you can make it.

Reading is an important step to understanding.