Hi,
I have a kernel that calculates a float value and another int value and writes it to gmem (actually an array of such vallues)
In another kernel I then read these values and use it.
I figured that the float value, as per the algorithm, is alway between zero and one. I thought to merge the two values into the float value like this:

Second kernel:
float fValue = pGMEMCalc[ threadIdx.x ];
int iIntValue = ( int )floor( fValue );
float fFloatValue = fValue - floor( fValue );

However the results are not the same as when I use two seperate arrays. Any suggestions? Is it related to floating point arithmetic order or such a thing?

From your example it is not clear how large is the range of the integer part.

In any case you should bear in mind that the floats have about 24 bits of precision, so,
if you are using some (maybe all) of those bits for storing the integer value, it is clear
that you are losing bits to store the float itself, which cannot thus recovered.

I make an example with decimal digits instead of bits:
Assume you have just 5 (decimal) digits of precision.
you can store a number like 0.54331 which has significant 5 digits.
Now, if you try to pack also the integer number 788 you obtain
788.54 because, with just 5 digits of precision the 0.00331 gets lost forever.

If what I’m saying has no meaning for you, then it is a good time to read a tutorial
on the representation of floating point numbers in computers.