What is going on here?

What is going on here?

Attached: code.png (1804x568, 125K)

evil floating point bit level hacking

magic numbers

newtonian method

Why 0x5f3959df instead of just 1597594079?

Q predicted this

Why 1597594079 instead of just 0x5f3959df?

First line: make a float with the name Q_rsqrt
Second line: curly braket that tells the float what it is
Third line: create a long with the name i
Fourth Line: create a float named x2 and y
Fifth line: create a constant float named three halfs which is equal to 1.5F
Sixth line: empty for space
Seventh line: define x2 to be equal to the number provided by Q_rsqrt
Eighth line: define y as the number input via float
Ninth line: make i to the power of y and times it by itself and add y
Tenth line: bring i into the hexadecimal binary 0x5f3759df then increase i by 1
Eleventh line: make y i to the power of y times i
Twelfth line: make y y * 1.5 minus the power of x2 times y times y

Overall a very ugly way to make a fast inverse square root function.

Because they're subtracting, which isn't bitwise arithmetic.

It's hacker code to steal nude photos!

Finding the reciprocal of a square root
Tldr messy guy code xd lol I'm sooo random

sound reasoning

Attached: Brain Barrier.png (596x602, 376K)

...

what a waste of digits senpai

write it
compile it
play around with a few numbers
use print statements to see what the bit shifting does
come back and report your results

manipulating of a floating point value on the bit level because it's faster than doing it via normal math

John Romero wrote this code. It's a function for determining the probability (0

Attached: br.png (255x204, 50K)

By the way, Carmack, the /v/ hero, did not come up with this trick.

>le ebin hacker code

Its just a linear approximation, its like the creed of engineers.

who is Q?

The bitwise shit is for the initial guess of a standard iterative root-finding algorithm. Turns out that's not even the best magic number to use.

I always wanted to know is it pportable with those bitwise operations. Or is it x86 only?

bitwise operations aren't different on different archietctures
float32 is still a float32 on a x64

The representation is all that matters, and that's portable. What's not portable are FP operations, which may use different levels of precision on different machines, and that's if they're compliant to IEEE in the first place (which many operations are not part of).

Shorter to write

>The representation
>that's portable.
no

Neither of these.

Because base 16 is able to perfectly communicate the bit-level representation of 4 bits of a value. This is why octals are used sometimes too, because it perfectly communicates the bit-level representation of 3 bits. Let me demonstrate:

0b0111 is 0x7 in hex, 07 in octal, while it's 7 in base 10.
0b1000 is 0x8 in hex, 010 in octal, while it's 8 in base 10.

As you can see, octal exactly represents 3 bits of binary, gaining an order of magnitude at the same time as binary does.

0b1010 is 0xA in hex, 012 in octal, while it's 10 in base 10.
0b1111 is 0xF in hex, 017 in octal, while it's 15 in base 10.
0b10000 is 0x10 in hex, 020 in octal, while it's 16 in base 10.

And now you can see that hexadecimal exactly represents 4 bits of binary, gaining an order of magnitude at the same time as binary did. Meanwhile, what did base 10 do? It changed its order of magnitude at some retarded point in between all of these.

So 0x5f3959df is super-easy to convert into hexadecimal. It's:

0b0101 1111 0011 1001 0101 1001 1101 1111

If your compiler follows the strict aliasing rule, it is undefined behavior. If not, then it is portable to any system which uses IEEE 754 32-bit floating point.

/thread