Deviation in a deterministic application

I am currently working on a (legacy) programme that has been written in C++ and C#; it executes some heavyweight calculations but should be completly deterministic. i.e. the same inputs will yeild the same outputs... Problem is that 2 runs (on the same computer, using the same compiled executable) produce slightly different outputs.

The application reads and writes to a SQL se开发者_开发百科rver database (it has unique access to the DB so nothing else should be interfering with the DB values).

The only obvious difference between runs is that they are each assigned a unique name (just a string variable).

There are no random objects within the code and all loops run for either a pre-determined number of iterations or until a condition is met, they don't run for a certain amount of time.There is a small amount of multi-threading, which I have been assured is thread-safe, but I will check this for myself.

Are there any other obvious things that I should be looking for, which would cause this deviant behaviour?

Two ideas occur to me:

• uninitiased variables.
• floating point arithmetic is not associative.

The latter point can yield machine accuracy level differences under multi-threading. It's much more likely to be uninitiased variables though!

If it is C++ then another thing is memory allocation. It's possible that a value isn't being initialized somewhere and therefore taking whatever value happens to be in memory at that time.

some possible causes come into mind:

• floating point math may give slightly different results on 32 bit vers. 64 bit
• some iterative algorithms may use some sort of randomness to initialize some start vectors or so
• some implementations may use 3rd party libraries - preinstalled on a system. LAPACK or FFTW are some candidates. They might have different version and could cause that too.

Determinism is set according to the defined inputs.

Was your database reset between reruns? Perhaps a backup and restore of the database is in order, and your subsequent tests should be performed from fresh restores of the database. If that works, then you need to go back to the design documentation to determine if differing output is permissible depending on database input.

If the design document doesn't allow differing output depending on the database input, then you're program was not built to spec.

If your program produces differing output with the same database as the input, then it's probably reading the time somewhere (perhaps to store a timestamp), in which case, it cannot be considered 100% deterministic at all.

Either way, you likely have more inputs into the algorithm than you are tracking, hence the indeterminacy.