What in the actual fuck is this

>then access the value???
Oh that makes sense, I might be retarded.

So it works in this case but if you used another language or compiler even it might not?

Why wouldn't you just program this in assembly at this point?

Normie here. What does it do?

This code is bad! It is hacker code used to steal nude photos! Stay away!

It's a very fast way of computing the reciprocal square root of a number. This was used in Quake 2 for lighting effects.

Yeah. You're supposed to use unions like this.
union U
{
float f;
long l:
};

U u;
u.f = some_float;
u.x // equals the value of some_float when reinterpreted as a long
But that's still not guaranteed to work everywhere because different machines may have different float or long implementations.

I can't believe noone knows what beautiful genius came up with this, but there's a breakdown here:

betterexplained.com/articles/understanding-quakes-fast-inverse-square-root/

fun fact: this code violates the strict aliasing rules and thus contains undefined behaviour
it is possible for it to get broken by modern compilers on aggressive optimizations

>some_float when reinterpreted as a long

Is there any other point in history when this is an acceptable thing to write in actual code?

Fast inverse square root, approximating something that takes a long time to compute, to make games run faster when used to draw lighting effects. The little inaccuracies aren't noticeable, so its not worth calculating it every time the dynamic lights shift.

afaik the only standard-compliant way to reinterpret that variable is to use memcpy
compilers are intelligent enough to handle memcpy specially so no call to memcpy is actually made in such case (its more of an abstract hint of your intent to reinterpret)

Yeah, legal type punning is done using memcpy. Compilers are smart enough to elide the copy.

I could swear I've seen gcc have a major fit about code that does that, but I'm compiling with -Wall -Wextra right now and it seems happy with that function.

gcc has -fno-strict-aliasing, i compile all my C code with it because type-based aliasing rules in such a language are imho broken by design
microsoft c compiler disables strict aliasing by default

A good starting estimate for the linear approximation used to approximate the inverse square root, expressed in hex.

tis-interpreter is underrated. It always manages to find shit like this.
finv.c:11:[kernel] warning: out of bounds read. assert \valid_read((long *)(&y));
stack: Q_rsqrt :: finv.c:23

Well I worked with hardware that did a similar thing.
>outputs a stream of floats (processed analog data) and a concurrent, synchronous stream of bit indicators
>floats don't require full 24 bits of precision so bit indicators are packed into least significant bit of the fraction

Wait I get it, -fno-strict-aliasing seems to be default, you need -fstrict-aliasing to generate errors on this shit.

>dirty approximation of square root for floats
Inverse square root to be exact.

I knew this fuckery had Carmack's finger in it.

It does, but he didn't write it.

en.wikipedia.org/wiki/Fast_inverse_square_root

Attached: SATOSHI_B.jpg (1001x1024, 774K)

It depends on your optimization level.

>It depends on your optimization level.
C. Not even once.

I tried to implement the same function in a standard compliant and platform independent way using ilogb and scalbn to check if it produces much worse code. Unfortunately yes, calls to ilogb and scalbn are not inlined. I thought that the point of these functions were to make exponent/mantissa juggling legal and fast. Why these functions are not defined in header files?

If you have a float, and you cast it to int like (int)x, the float gets converted properly, e.g. the bit arrangement of the new value is no longer a float. If you do what's in the pic, the type becomes an int, but the bit arrangement of the new value is still that of a float.

Shit, I flipped it backwards from what the pic is doing, but this still applies

>look, I just found out about !

Just google it if you don't understand it, retard. There are entire wikis dedicated to DOOM's source code, and that's a pretty well known trick even predating DOOM.

it's not really a joke

>Why these functions are not defined in header files?
Just more C retardation. They're allergic to defining simple functions in header files for some reason.
Just like qsort for example.

looks like evil floating point bit level hacking

magic

Attached: 1527009793487.jpg (720x479, 80K)

So if you use this in a game that has demons, they're really nasal demons?

Attached: nasal demons.jpg (3754x2306, 396K)

czech casting. look it up.

huh?

Attached: Capture.png (548x769, 112K)

x >> 1
is the same as
x /2

X >> 2
Is the same as
X/4

XIs the same as
X/8

Retard

exactly.

IIRC Carmack said it was put in by a consultant from SGI.

We need more threads like this.

brainlet

Bit shift

if you write valid standard-compliant C, you have nothing to fear and your code will always work no matter what

if you dont, your fault

>actually try this
>transform '14' to float, bitshift right
>0x5f3759df - 0x20b000000 = 0xfffffffe543759df
>out of range

Delete this right now. You're embarassing yourself.

it is quite possibly the most talked about line of code in history. maybe try searching about it

>realize I'm supposed to be working in DWORD mode
>'4' to float bitshift right
>0x5f3759df - 0x20400000 = 0x3ef759df = 0.48310754F
> 0.48310754F * (1.5 - (2 * 0.48310754F * 0.48310754F)) = 0.4991535750882127
> 0.4991535750882127 * (1.5 - (2 * 0.4991535750882127 * 0.4991535750882127)) = 0.4999978519074232
>it's accurate

The pointers are deferenced, though. Taking the address is perfectly valid, so the compiler cannot legally reorder the pipeline.

Sorry, I use real programming languages

Neato

>use "real" programming languages
>doesn't know what bitshift is

Noice

Bitshifting is for wannabe hackers.
I use thinks like integers, booleans, and chars.

> evil floating point bit level hacking
Can't you read?

> not knowing that code runs on a processor

I like to think OP was looking for a technical answer, but that's easily available from searching. The originators of the function itself are also easily available, yet people in this thread seem to think they're still unknown. I share this board with fucking retards.

There's a whole world of algorithms you haven't seen, kiddo.
graphics.stanford.edu/~seander/bithacks.html

It's actually much more simple than it looks. Understanding how that all works only requires a basic understanding of newton's method and how floating point numbers are represented and two's complement. en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code