New var creation with right bit shift shows incorrect result using same initializer

While ((uint64_t)val << 19) / 32000000 does no rounding, but you still have some loss in accuracy unless the number is an integer multiple of "32000000". The final result has only three bytes, as needed for the next steps.

I'm too lazy to test the result in JavaScript using a 64 bit math module vs. normal numbers, but in C it is like this:

_#include <stdio.h> //remove the underscore at pos 1, needed for formatting here only

int main()
{
    printf("Hello World\n");
    __uint64_t a;
    double b;
    __uint64_t c;
    for (long i = 1; i < 0xFFFFFFFF; ++i) {   //no errors
        a = ((__uint64_t)i << 19) / 32000000;
        b = (__uint64_t)((double)i * 0.016384);
        c = a - b;
        if (c != 0) {
            printf("Err: %d, %d \n", i, c);
        }
    }
    printf("Done\n");
    return 0;
}

If you want to see more than "Hello World", "Done" change b = (__uint64_t)((double)i * 0.016384); to b = (__uint64_t)((float)i * 0.016384);.

It appears that attempting to use floating point to solve a 2's compliment equation is not the way to go as the need is, to shift ones and zeros and not a representation of a number using a mantissa and characteristic.

For me it doesn't look like there's any need to shift ones and zeros. Think about it.

@AkosLukacs:
The source is most likely this file here, found by searching for "<< 19) / 32000000".
For the linked code: A 32 bit frequency value is taken as input, converted to 24 bit (three byte values) with a loss in accuracy of 8 bit.