> The bits of a float as an integer literal are proportional to its log2 value (plus a constant), …

I watched a video[0] a while back about that. Once that coincidence(?) was explained, Q_rsqrt finally made sense.

[0]: https://youtu.be/p8u_k2LIZyo (~20 minutes)

Bit twiddling integers doesn't require unsafe type punning like this. It's also largely safe to assume a nominal two's complement machine is all your code will ever run on. If not, you'll know to be careful. You can't make such blanket assumptions with floating point representations.

Great points. Out of curiosity, what are some examples of modern architectures that don’t use IEEE 754 floats? Realistically, how often would one ever write code that needs to be portable between an architecture that uses IEEE 754 and one that doesn’t? I could only imagine this ever being an issue for code that needs to be deployed to a wide variety of exotic embedded systems, which is an extremely niche case IMO.

>what are some examples of modern architectures that don’t use IEEE 754 floats

Mainstream? I can't think of one. Googling the question yields a stackoverflow question from 2010 that lists the 5 or 6 major architectures (x86, PowerPc, SPARC, Arm,.. ) and about a dozen more as supporting x86. So it's a fairly safe assumption to make.

One area where vanilla IEEE754 isn't used that immediately came to my mind is high performance ML at companies like facebook and Google, the generic range-precision tradeoff that FP offers is inefficient and they ended up designing several new formats with smaller sizes or larger ranges. Googling "Alternatives to FP in ML" or "Custom FP format <company-name>" yields a lot.

Another "niche" area is finance, insurance, taxes and anything nearby, fixed point in those area is, I hear, a must. Because all the usual invariants of high school algebra that FP breaks actually have significance. (imagine the well-known FP flaw "x+epsilon == x, with epsilon non-zero" playing out in these contexts.)

In any case, number portability in a language like C++ is a breeze. You design a myNumber class and overload all relevant operators and that's it. Compiler will make sure to inline the calls if they're a one-line simple floating point operations, but otherwise you can freely change the implementation of the class and the calculations never look different.

> Another "niche" area is finance, insurance, taxes and anything nearby, fixed point in those area is, I hear, a must. Because all the usual invariants of high school algebra that FP breaks actually have significance.

In particular, double-entry bookkeeping (standard practice for centuries) uses the accounting equation [1] as a checksum. If the two sides of the equation are ever unequal, then there's been a mistake somewhere that needs to be corrected.

If you add the same value to a large asset account and a small liability account, for example, you can run into problems: The internal rounding performed by floating point arithmetic can mean that the increase to each side of the equation is slightly different, throwing the system out of balance.

[1] https://en.wikipedia.org/wiki/Accounting_equation

In addition to sibling comments, two more oddballs are MSP430 floats and DSPs.

MSP430-style floats are common in industrial automation and such, since many sensors either use or used to use MSP430s to collect data. And, of course, in that field, legacy carries more inertia than a 50,000-ton press....

Newer DSPs tend to use IEEE-754 floats, but this was not always the case. Older DSPs used every trick in the book to go faster, and "compatibility with standard floating-point formats" was never in their product requirements. So you can guess at what manner of horrors came out of that! Fortunately, their customers are mostly the sort of people who (1) didn't mind changing to standard floats, since it's not like things were stable before; and (2) are very, very comfortable writing this stuff directly in assembly. So they definitely know whether their architecture has an instruction to take the absolute value, needs a short branching program, or just needs a single bit-operation.

> what are some examples of modern architectures that don’t use IEEE 754 floats?

Lots of medical devices support floating point format from IEEE-11073 instead. I'd guess there are a significant number of them in existence and they need to be done well.

>Bit twiddling integers doesn't require unsafe type punning like this.

Not only that but, at least for Fast Inverse Square Root, it's not advantageous to carry out the bit twiddling since the rsqrtss instruction is faster and more precise, and vectorized instructions are faster still for large strings of floats.

Back when that code was used (in Quake 3, and before, a for a bit after it), there was no rsqrtss instruction.

Well, with bit twiddling for floats, you have some very important questions. Like, do you maintain the distinct NaN values or are you okay with all NaNs producing a valid (but possibly different) NaN value.

What if the twiddle wasn't obscure and the article was unwarranted?

Given the amount of discussion this article has sparked on HN, I’d argue that as obvious as it might be, the technique is nonetheless obscure. The amount of highly experienced and accomplished programmers I’ve encountered who have no idea how floating point numbers work is astoundingly high.

If a similar article were written about how shifting an integer to the right by one bit is equivalent to dividing it by two, I highly suspect it would attract no attention on this site, aside from a couple dismissive comments grousing about why such a basic fact needs its own article.

You can of course have some idea how floating point numbers work, but still not know how to bit twiddle abs().

I don't know what to take from the fact that Java stdlib didn't use it until Java 18? It does seem like it wasn't obvious to at least someone who knew something.

> If a similar article were written about how shifting an integer to the right by one bit is equivalent to dividing it by two, I highly suspect it would attract no attention on this site,

Nah, it would be full of comments of people saying "well of course I knew that! doesn't everyone who's anyone? I can't believe how many newbies don't though!" :)