This analysis is somewhat dated and leaves out one important fact: nowadays, floating point arithmetic is carried out using a set of special scalar SSE instructions (and not the ancient x87 co-processor, as was done in the author's benchmark).<p>SSE instructions remove performance pitfalls related to infinities and NaNs. The only remaining case where slowdowns are to be expected denormals (which can be set to flush-to-zero if desired.)<p>In other words: it's perfectly fine to work with infinities and NaNs in your code.
You may also want to read about posits:<p><a href="https://www.johndcook.com/blog/2018/04/11/anatomy-of-a-posit-number/" rel="nofollow">https://www.johndcook.com/blog/2018/04/11/anatomy-of-a-posit...</a><p>I'm a fan of these not because of the claims regarding precision, but because they drop all the complexity and baggage of IEEE floating point.
Groking that way that floats work really is a lot of fun.<p>Years ago a put together a math library (<a href="https://github.com/KimBurgess/netlinx-common-libraries/blob/master/math.axi" rel="nofollow">https://github.com/KimBurgess/netlinx-common-libraries/blob/...</a>) for a domain specific language that had some "limited" capabilities. All functionality had to be achieved through a combination of some internal serialisation functions and bit twiddling.<p>It was simultaneously one of the most painful and interesting projects I've done.
On a personal note, this representation annoys me:<p>value = (-1) sign * 2 (exponent-127) * 1.fraction<p>It should be:<p>value = (-1) sign * 2 (exponent-127) * (1 + fraction*2^-23)<p>It sounds trivial, but you can't reason mathematically about the first equation.
In my opinion, the confusion that arises when programmers get results from floating-point computations that are not what they expect stems from this:<p>> Floats represent continuous values.<p>But as you probably know, this isn't possible. The concept of infinite precision is interesting in theory, but disappears when any actual calculation needs to be made, whether on a digital electric computer or not.<p>I wonder if this is not a flaw in the crude mechanical representation of numbers, but a flaw in the decision to base floating-point computation on the concept of continuous numbers. I believe that a better model for floating-point computational representation and manipulation would be to reflect the rules of scientific measurements - that each number includes an explicit amount of precision that is preserved during mathematical operations.<p>This would not only keep JavaScript newbies from freaking out when they add 0.1 and 0.2, but prevent problems of thinking calculation results are correct, when they are not.<p>If you aren't getting what I am saying, let me give an example. Let's say, for some reason, you want to measure the diameter of a ball. You have a measuring tape so you wrap it around the widest part and record that it is 23.5cm. To calculate the radius, you should divide by π. If you do this in double-precision floating point, you will get 7.480282325319081, but this is nonsense. You can't create a result that is magically more precise than your initial measurement though division or multiplication. The correct answer is 7.48cm. This preserves the amount of precision in the least precise operand, and is arguably the most correct result.
The article content is decent, but I can't stand the fact that the author used this bit of CSS to make all the text unreasonably small: <style> body, div, ... { font-size: x-small } </style>