4 ms·

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

Also free for download: Physically Based Rendering, 3e. http://www.pbr-book.org/3ed-2018/contents.html 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.)

magicalhippo 6y ago
> 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 https://math.stackexchange.com/a/2007723
- ectopod 6y ago
  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.
  - magicalhippo 6y ago
    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-about-finding-a-hypotenuse/ https://www.johndcook.com/blog/2010/06/02/whats-so-hard-abou...
    - thethirdone 6y ago
      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).
      - deleted 6y ago
        [deleted]
      - sjburt 6y ago
        sqrt(x*x + y*y) loses a lot of precision if x and y differ greatly in magnitude.
        thethirdone 6y ago
        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.

magicalhippo 6y ago

> 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 https://math.stackexchange.com/a/2007723

ectopod 6y ago
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.
- magicalhippo 6y ago
  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-about-finding-a-hypotenuse/ https://www.johndcook.com/blog/2010/06/02/whats-so-hard-abou...
  - thethirdone 6y ago
    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).
    - deleted 6y ago
      [deleted]
    - sjburt 6y ago
      sqrt(x*x + y*y) loses a lot of precision if x and y differ greatly in magnitude.
      - thethirdone 6y ago
        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.