Sometimes Floating Point Math is Perfect

I’ve written in the past about how to compare floating-point numbers for the common scenario where two results should be similar but may not be identical. In that scenario it is reasonable to use an AlmostEqual function for comparisons. But there are actually cases where floating-point math is guaranteed to give perfect results, or at least perfectly consistent results. When programmers treat floating-point math as a dark art that can return randomly wrong results then they do themselves (and the IEEE-754 committee) a disservice.

A common example given is that in IEEE floating-point math 0.1 + 0.2 does not equal 0.3. This is true. However this “odd” behavior is then extrapolated in some ill-defined way to suggest that all floating-point math is wrong, in unpredictable ways. The linked discussion then used one of my blog posts to justify their incorrect analysis – hence this article.

In fact, IEEE floating-point math gives specific guarantees, and when you can use those guarantees you can sometimes make strong conclusions about your results. Failing to do so leads to a cascade of uncertainty in which any outcome is possible, and analysis is impossible.

Advertisements

Commute Challenge 2017

I’m lucky enough to live just 2 km (1.25 miles) away from the place where I work. Because of this – and because I dislike driving – I tend to commute in a variety of non-car ways. A few months into my new job I noticed that I tended to use about six different commute methods on a regular basis: walking, running, cycling, unicycling, inline skating, and taking a bus. Having that many commute methods got me thinking: how many commute methods could I come up with? Could I commute to work using a different method every work day for a month?

And so was born the commute challenge. After much procrastination I tried this challenge in April 2017. One month, twenty work days, twenty different commute methods.

Traveling in Iran

In 1992, near the end of a very slow trip around the world, my fiancée (now wife) and I visited Iran for two weeks. I thought I’d share a few pictures and stories from that visit.

We entered Iran through the Taftan land crossing from Pakistan, having taken an all-night bus trip from Quetta. I don’t mean to criticize Pakistan by the description that follows – I am merely setting up our first impressions of Iran.

The bus trip was horrible. Imagine, if you will, a twelve hour trip in a school bus – famed for their comfortable seats and smooth suspension – on a road that was almost entirely washboard and potholes. We quite enjoyed Pakistan (it was safer then) but that bus trip was not one of our favorite bits.

Delete an inline function, save 794 kB

In the previous episode of “Simple Changes to Shrink Chrome” I discussed how deleting ‘const’ from a few key locations could lead to dramatic size savings, due to a VC++ compiler quirk. In this episode I’ll show how deleting an inline function definition can lead to similar savings.

The savings this time are less important as they are mostly in the .BSS segment, but there are also some modest code-size savings, and some interesting lessons. It’s worth confessing up front that this time the problem being solved was not caused by a compiler quirk – it was entirely self inflicted.

Doing this investigation has reminded me that the behavior of linkers is best described by chaos theory – the details of their behavior defy prediction by simple heuristics, and the results can be changed dramatically by tiny butterflies code changes.

Add a const here, delete a const there…

I just completed a series of changes that shrunk the Chrome browser’s on-disk size on Windows by over a megabyte, moved about 500 KB of data from its read/write data segments to its read-only data segments, and reduced its private working set by about 200 KB per-process. The amusing thing about this series of changes is that they consisted entirely of removing const from some places, and adding const to others. Compilers be weird.

Seattle to Portland on a Unicycle

This was originally written in the summer of 2005. I’m reposting it here to get all my writing in one place. For more information on long-distance and high-speed unicycling go to the unicycle section of my blog, available here.

The Challenge

In the spring of 2004 I purchased a Coker unicycle. This unicycle has a 36″ diameter tire and a reinforced air seat with hand grips and was designed for riding long distances. I started riding my new unicycle to work (an eight mile commute each way), and on some twenty to thirty mile rides with other Seattle area unicyclists. Around the same time I met Lars Clausen and read his book “One Wheel – Many Spokes”, about his unicycle ride across the United States. These events conspired to get me thinking about doing the STP (Seattle to Portland bike classic) on a unicycle.

The STP is a two-day 204 mile ride which draws 8,000 cyclists every year. A few people – notably Jack Hughes – have done it before on a unicycle. Other unicyclists have done STP level distances in a single day, so clearly doing it in two days was quite possible, but not easy.

VC++ /arch:AVX option – unsafe at any speed

Microsoft’s VC++ compiler has an option to generate instructions for new instruction sets such as AVX and AVX2, which can lead to more efficient code when running on compatible CPUs. So, an obvious tactic is to compile critical math-heavy functions twice, once with and once without /arch:AVX (or whatever instruction set you want to optionally support).

It seems like a good idea, and it’s been used in various forms for years, but it’s devilishly difficult to do safely. It usually works, but guaranteeing that is trickier than I had realized.