Converting float to long pointer and back to float pointer

Question

I am trying to understand the below code snippet taken from here

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // ??? 
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
//  y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}

What I dont understand is the conversion from float to long pointer and back to float pointer. Why cant we simply do i=y instead of first referencing and then dereferencering the float.

I am new to pointer conversions, so please bear with me.

Answer 1

This code snipped is obviously the fast inverse square root. The pointer semantics there are not really used to do pointer things, but to reinterpret the bits at a certain memory location as a different type.

If you were to assign i=y this would be turned into a truncating conversion from floating point to integer. This however is not what's desired here. What you actually want is raw access to the bits, which is not straightforward possible on a floating point typed variable.

Let's break this statement down:

i  = * ( long * ) &y;

• &y: address of y. The type of this expression is (float*).

• (long*): cast to type. Appled to &y it steamrolls over the information, that this is the address of a floating point typed object.

• *: dereference, which means, "read out" whatever is located at the address given and interpret as the base type of the pointer that's being dereferenced. We've overwritten that to be (long*) and essentially are lying to the compiler.

For all intents and purposes this breaks pointer aliasing rules and invokes undefined behaviour. You should not do this (caveats apply¹).

The somewhat well defined way (at least it doesn't break pointer aliasing rules) to do such trickery is by means of a union.

float Q_rsqrt( float number )
{
    union {
        float y;
        long  i;
    } fl;
    float x2;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    fl.y  = number;
    fl.i  = 0x5f3759df - ( fl.i >> 1 );                   // ??? 
    fl.y  = fl.y * ( threehalfs - ( x2 * fl.y * fl.y ) ); // 1st iteration
//  fl.y  = fl.y * ( threehalfs - ( x2 * fl.y * fl.y ) ); // 2nd iteration, this can be removed

    return fl.y;
}

EDIT:

It should be noted, that the type-punning via union as illustrated above is not sanctioned by the C language standard as well. However unlike language undefined behavior the standard so far leaves the details of the kind of union accesses done in that way as implementation dependent behavior. Since type-punning is something required for certain tasks, I think a few proposals had been made to make this well defined in some upcoming standard of the C programming language.

For all intents and purposes practically all compilers support the above scheme, whereas type-punning via pointer casts will lead to weird things happening if all optimization paths are enabled.

---

1: Some compilers (old, or custom written, for specific language extensions – I'm looking at you CUDA nvcc) are severly broken and you actually have to coerce them with this into doing what you want.

Answer 2

OK, so you are looking at some ancient hackery from the time when floating point processors were either slow or non-existent. I doubt the original author would defend continuing to use it. It also doesn't meet the modern language transparency requirements (i.e. it is "Undefined behaviour") so may not be portable to all compilers or interpreters, or handled correctly by quality tools such as lint and valgrind, etc, but it was the way fast code was writ in the 80s and 90s.

At the bit level, everything is stored as bytes. A long is stored in 4 bytes, and a float is also stored in 4 bytes. However the bits are treated very differently. In integer/long, each bit is ranked similarly as a power of 2, and can be used as a bit field. In float, some bits are used to represent an exponent that is applied to the rest of the number. For more info read up on IEEE.

This trick takes the float value, and looks at the bytes as if it is an integer bit field, so then it can apply magic. The it looks at the resultant bytes as if they are a float again.

I have no idea what that magic is exactly. No-one else does, probably not even the guy who wrote it, as it isn't commented. On the other hand the doom and quake source did used to be cult code reading, so perhaps someone remembers the details?

There used to be many such tricks in the "good old days", but they are relatively unnecessary now, as floating point is now built in to the main processor and is as fast, and sometimes faster than, the integer operations. Originally, even uploading and downloading small ints from the co-processor could be done more quickly using such hacks than using the built-in methods.