I’m in Milford, UT right now after a night in a hotel. It’s been eight days of biking so far at a fairly stiff pace, out of necessity due to the 37-day cap. Nevada (particularly) and Utah are so spread out and empty that most of my days have been 100+ through it, including one 135 mile day (and, perhaps surprisingly, an even worse day yesterday at 118 miles, due to the first real headwind of the trip). And don’t forget there’s no water between towns, and often no houses, even. But this is what’s between the west coast and the east coast, so you make it work. What must be done, can be done. (In my case, using two completely-filled 100oz. water bladders, which yesterday was just enough to get me through the longest waterless stretch on the route at 84 miles. Although I was sucking dry for the last dozen miles of it, which happily coincided with a long downhill stretch where I didn’t miss the water too much.)

I said I’d try to occasionally post here, but I’m finding that for this trip Twitter’s a much better medium both in terms of ease of use and suitability for pictures plus a few words, so look there for future updates. They’re pretty intermittent, tho — cell coverage out here is very sparse, and by all accounts T-Mobile is the worst provider in the world to have out here (rookie error on my part), so I tend to save up drafts and post them all at once when I do find coverage.

Anyway, back to riding now. Onward through Utah to the Continental Divide, and to the Great Plains beyond!

I tend to take very long vacations. Coding gives me the flexibility to work from anywhere, so when I travel, I keep working by default and take days off when something special arises. Thus I usually take vacation in very short increments, but very occasionally I’ll be gone awhile. And when I’m gone awhile, I’m gone: no hacking, no work, just focused on the instant.

My last serious-length vacation was August-September last year. And since then, I’ve taken only a day and a half of vacation (although I’ve shifted a few more days or fractions thereof to evenings or weekends). It’s time for a truly long vacation.

For several years I’ve had a list of long trips I’ve decided I will take: the Appalachian Trail, the John Muir Trail, the Coast to Coast Walk in England, and the Pacific Crest Trail. I’ve done the first two in 2008 and 2010 and the third last year. The fourth requires more than just a vacation, so I haven’t gotten to it yet. This leaves one last big trip: biking across the United States.

Tomorrow I take a much-needed break to recharge and recuperate (in a manner of speaking) by biking from the Pacific to the Atlantic. (Ironically, the first leg out of San Francisco is a ferry to Vallejo.) I have a commitment at the back end August 25 in San Francisco, and a less-critical one (more biking, believe it or not!) August 26. The 24th must be a day to fly back, so I have 37 days to bike the ~3784 miles of the Western Express Route (San Francisco, CA to Pueblo, CO) and part of the TransAmerica Trail (Pueblo to Yorktown, VA). This is an aggressive pace, to put it mildly; but I’ve biked enough hundred-mile days before, singly and seriatim, that I believe it’s doable with effort and focus.

Unlike in past trips, I won’t be incommunicado this time. I’ll pass through towns regularly, so I’ll have consistent ability to access the Internet. And I died a little, but I bought two months of cell/data service to cover the trip. So it goes. I won’t be regularly checking email (or bugmail, or doing reviews). But I’ll try to make a quick post from time to time with a picture and a few words.

I could say a little about gear — my twenty-five pound carrying capacity in panniers on a seatpost-mounted rack, the Kindle I purchased for reading end-of-day (which I’ve enjoyed considerably for the last week…as has my credit card), the 25-ounce sleeping bag I’ll carry, the tent I’ll use. I could also say a little about the hazards — the western isolation (you Europeans have no idea what that means), the western desert (one Utah day will be 50 miles without water, then 74 miles without water), the high summer climate, the other traffic, and simple exhaustion. But none of that’s important compared to the fact that 1) this is finally happening, and 2) it starts tomorrow.

“And now I think I am quite ready to go on another journey.” Let’s do this.

The latest addition to the Mozilla Framework Based on Templates (mfbt) is mozilla/FloatingPoint.h. This header implements various floating point functionality.

Functionality overview

mozilla/FloatingPoint.h currently implements the following functionality, all centered around working with double-precision floating point numbers. (There’s no single-precision support only because Mozilla seemingly doesn’t need it. The only code I can find that does this sort of thing for single-precision numbers is nsCoord.h, and that only barely. We can add single-precision equivalents when we need them.)

MOZ_DOUBLE_IS_NaN(double d)

Determines whether a value is NaN (not a number).

MOZ_DOUBLE_IS_INFINITE(double d)

Determines whether a value is positive or negative infinity.

MOZ_DOUBLE_IS_FINITE(double d)

Determines whether a number is finite — that is, not NaN or positive or negative infinity.

MOZ_DOUBLE_IS_NEGATIVE(double d)

Determines whether a number is negative. This is useful because d < 0 does not answer this question! There are two zero values, +0 and -0, and IEEE-754 requires that (-0 < 0) be false. (There are good reasons for this, but this isn’t the place to get into them. If you haven’t read it, read What Every Computer Scientist Should Know About Floating-Point Arithmetic right now. It probably gives the answer, and much much more knowledge as well.) This method properly distinguishes -0 as being negative.

MOZ_DOUBLE_IS_NEGATIVE_ZERO(double d)

Determines whether a number is -0.

MOZ_DOUBLE_EXPONENT(double d)

Returns the exponent portion of the number. Floating point numbers are represented as a sign bit s, a binary fraction b0..p, and an exponent E. The represented number, then, is (-1)s(b0..p)2E. This method returns the number E for a floating point number.

MOZ_DOUBLE_POSITIVE_INFINITY()

Returns positive infinity.

MOZ_DOUBLE_NEGATIVE_INFINITY()

Returns negative infinity.

MOZ_DOUBLE_SPECIFIC_NaN(int signbit, uint64_t significand)

Computes a specific NaN value, with a bit pattern specified by provided parameters. The bit layout IEEE-754 specifies for floating point formats interestingly requires that multiple bit patterns be treated as NaN values. This method allows the user to create such custom NaN values if he needs to. (99% of code should never, ever touch this method. Instead, most code should use…)

MOZ_DOUBLE_NaN()

Computes an unspecified NaN value. If you need a NaN value and you don’t know that you need a specific NaN, use this method instead to get one.

MOZ_DOUBLE_MIN_VALUE()

Returns the smallest non-zero positive double value.

MOZ_DOUBLE_IS_INT32(double d, int32_t* i)

Determines if the provided number is a signed 32-bit integer. (-0 doesn’t count as such; +0, the “normal” zero value, does.) If it is, *i will be set to that value when the method returns.

(There’s one more method in the header, currently, that used to have users. Sometime in the last couple months, however, that method’s users all disappeared, and I didn’t notice it when rebasing. Thus I’ll be removing it shortly, and I haven’t mentioned it here.)

Why add some of these methods? Aren’t isinf, isnan, and so on good enough?

There are standard methods implementing some (but not all) of this functionality. In the best of all possible worlds we could simply use isnan and other such methods directly. In practice we’ve encountered a number of problems.

First, Microsoft’s compilers gratuitously Think Different and don’t expose isnan and friends, so on those platforms you’d have to use _isnan instead. (std::isnan isn’t usable there because some of our code still must work as both C and C++.) Obviously, we don’t want to #ifdef every place we need to use the method.

Second, we’ve found various compilers have bugs when using either the standard methods or Microsoft’s bogo-named methods. Most commonly this bustage occurs with PGO builds; interestingly, both MSVC and gcc have problems here, despite their optimizers obviously not sharing any code.

Third, we’ve found even some obvious bitwise algorithms trigger PGO build failures, again on entirely different compilers. (You can’t win.)

Basically, then, we can’t use the standard methods, we can’t use some bitwise methods, and whatever we do we have to be really careful about to make sure we don’t break anything. Hopefully this header will satisfy those requirements.

Where’s this header again?

The header is located at mfbt/FloatingPoint.h in the source tree. However, per standard mfbt practice, you should use #include "mozilla/FloatingPoint.h" to include it. Knock yourself out using it.

WebKit (well, one twisted soul, I think) has started a meme collection. It’s true that Mozilla has a quotes database, which sometimes we are even gracious enough to share with them [more here]). But we have no meme collection.

Mozilla Internetizens, fix this. Pronto.

UPDATE: jdm follows through with Mozilla Memes. Next step: ADDRESS THE GAP.

UPDATE 2: The gauntlet has been thrown down.