Also free for download: Physically Based Rendering, 3e. http://www.pbr-book.org/3ed-2018/contents.html

(edit: I realize it's in the article, but it deserves highlighting here again. This is a really good book.)

> This is a really good book.

Indeed! PBR is by far the best technical books I've read.

PBR derives the math and goes on to show how to implement it, all in a very understandable way, which at least in my experience is quite rare.

A lot of math is non-trivial to implement in a correct and well-behaved manner. Even just solving quadratic equations is not straight forward[1].

[1]: https://math.stackexchange.com/a/2007723

Even sqrt(x * x + y * y) is wrong. I'm slightly ashamed to say that I learned of the C hypot function only a few days ago. I've been doing this wrong for decades.

Indeed, overflow is also an issue that easily comes sneaking. Nice post on calculating the hypotenuse here[1].

[1]: https://www.johndcook.com/blog/2010/06/02/whats-so-hard-abou...

I would think overflow is a very rare problem for floats; I don't think any code I have ever written would need to handle the overflow case. The more significant problem should be precision loss.

Is the algorithm in [1] significantly more precise for inputs that don't result in overflow?

Edit: I made a small program to check a few values. It is seems like the algorithm in [1] is better in terms on precision, but only by a small margin (on the small set of values I checked).

sqrt(x*x + y*y) loses a lot of precision if x and y differ greatly in magnitude.

Do you have an example where this is true? I have not seen an example with > 2 ulp difference from the true value or > 1 ulp difference between the two algorithms.

Past comments: https://news.ycombinator.com/item?id=18958108

More to the point, it's not just gratis (you could get it gratis on libgen previously); it's libre, legally free, under a CC-BY license.