nope. RANDNBR generates a new random number (a double) between 0 and 1. This has nothing to do with hex, he is simply saying
n = 1.0 - (2.0 * (RANDNBR));
so, we could get
n = 1.0 - (2.0 * 0.0) == 1.0
or
n = 1.0 - (2.0*1.0) == -1.0
or any number in between -1 and 1.
The 0x7fffffff is a dirty trick. 0x7fffffff is the largest possible (32bit) integer value. however, 0xffffffff is the smallest possible integer value (the highest bit in an int is the minus sign. therefore, 0xffffffff == -0x7fffffff, ie the lowest negative number possible).
So, the quick way to strip that out, is to mask out the minus sign with an AND bitwise operation (&). Just check the 0x7f and 0xff in binary and it should make sense :
0x7f == 01111111 == 127
0xff == 11111111 == -127
[font=Verdana]
perform a bitwise and and you get :
0x7f == 01111111 == +127
so,
(random() & RANDMSK)
ensures you get a positive number.
[/font](random() & RANDMSK) / RANDMSK
[font=Verdana]
would give you 1 or 0 (since it’s an integer division, and disregards the decimal place). So, to fix that problem, we tell the compiler to divide by a double to keep the decimal :
[/font]
(random() & RANDMSK) / (double)RANDMSK
[font=Verdana]however, all of that is moot anyway, since if his random() function returns all possible int values, he could have just done :
z = random() / (double)RANDMSK;
[/font]which would return a double between -1 to 1 anyway. I think he’s just trying to seem clever, but failing 