11–20 of 100 posts
> But floating point numbers are always greater than LNS numbers
Unless I'm missing something, they are never smaller, but they can be equal (at powers of two).
> E.g. x1/2x^{1/2}x1/2, x−8x^{-8}x−8, x2x^2x2, though you probably wouldn't use it for positive exponents since you can just use multiplication to get an exact answer.
1/2 is positive. As is 1/3.
float rsqrt(float number) { return 1.0f / sqrtf(number); }I wonder how it holds up to something like this on a modern processor and compiler: float rsqrt(float number) { return 1.0f / sqrtf(number); }
While this may look disappointing, it should be clear that adding 5% (or even 0.1%) error to inverse square root calculations is not something compilers are in the business of.
Now, when you give the compiler more leeway (and -ffast-math is substantial leeway for anything less ephemeral than triangle normals on screen), you get much more interesting things:
Turns out x86 has a (microcoded) instruction for this (and newer processors also have vectorized versions[1] of it). The compiler adds Newton-Rhapson for good measure.
[1]: https://uops.info/html-lat/KBL/VRSQRTSS_XMM_XMM_XMM-Measurem...
God, this is such an old meme at this point. What's next, telling me how good lisp is?
Obligatory XKCD: https://xkcd.com/1053/
But not searching to see if something had been posted before on a forum is a bit different[0]
This is an explanation of the fast inverse square root that I hope is easy to understand. I also managed to improve on it a little bit.
i = * ( long * ) &y; // evil floating point bit level hacking
Learned this recently with Arm AC6.
[Also, this kind of genius analytic approximation of hot functions that do math makes me all tingly]
FYI: Type punning like this doesn't work on all compilers i = * ( long * ) &y; // evil floating point bit level hacking Learned this recently with Arm AC6. [Also, this kind of genius analytic approximation of hot functions that do math makes me all tingly]