Different CPU's compute float type diffrently

You could use a type which computes the same way on every platform, such as an integer (or fixed-point).

Quote:

Original post by Anonymous Poster IEEE floating point math is a *STANDARD*; CPU designers adhere to this standard and there is no way you could have 'slightly different results' unless the input parameters are 'slightly different'. The only this could happen if each computer is using a different C library for converting ASCII characters of floating-point numbers to their internal IEEE floating point binary representation. The better way to solve this is to generate a binary file and use that same binary file as input on all computers.

This is actually not exactly true. For example, The internal representation of floats in the x87 (x86 floating point co-processor) is 80 bits internally, while it is a constistant 64 bits on other architectures like the powerPC. This can lead to slight deviations in results both from long calculations (the deviation grows with longer calculations) and the conversion from method from 80 to 64 (or 32) bits. I've not looked at the spec in detail, but I believe the IEEE format defines the format and behavior of things like 0, NAN, and +/- infinity but leaves some wiggle room as far as the accuracy with which computations must uphold. Having some wiggle room is actually fairly common in such standards, such that new implimentations may exist either to represent an improvement over other implimentations (speed, die size) or so that new implimentations may be created without infringing upon previous implimentations. A standard that's too strict ends up defining an implimentation, rather than a format.


So, what types of processors are being used that are yielding different results? That information will help narrow down the problem.

I have heard of DirectX (D3D in particular) changing the precision flag on the CPU during certain operations, which can play havok if you're trying to do completely deterministic simulation.

Realistically I think your only options are either to go with fixed point or relax your requirements so that minute differences are handled correctly.

It should be possbible to get the same results even when using floating point types. The problem is most likely, as already mentioned, the differing internal representation of floats (and perhaps the fact that Direct3D switches it).
You can try to switch the floating point mode yourself around your sensitive calculations. Have a look at the function _controlfp() defined in float.h (assuming you use C/C++ on a x86 processor).

Quote:

CPU designers adhere to this standard and there is no way you could have 'slightly different results' unless the input parameters are 'slightly different'.

That's not true; the standard leaves several things to the implementor (such as the amount of precision of intermediate values).

By default, Intel CPUs store intermediate (register) values with 80 bits precision, and AMD uses 64. If you want the same result, you have to use the Microsoft-specific _controlfp() function (or the FP control word assembly instructions) to set the internal mode to 64 bits across the board. Also set the rounding mode consistently. You probably need to do this after you've called a third-party DLL, too, as many DLLs (anything from DirectX to printer drivers) change these on you without re-setting them.