AMDG Sebastian Mach wrote:
This was indeed the problem. The one box had boost 1.35 installed, the other one 1.41. Thanks for that hint.
I guess this is a) not the right place and b) the interest is probably low (and let it be because it's not in the consciousness of many people): * I realized that just replacing uniform_int.hpp with the older version (that is, in a project local directory) and renaming components was not easily possible * hence it might be hard in the future to trust boost::random in the little corner where I really need portable random number sequences (as users will literally work with seeds) * thus, I (and maybe some other persons) would love if, as with spirit::classic, backwards compatibility could be provided somehow, either via a typedef, a #define, or in the future with inline namespaces
Of course, if there is already a way that "guarantees" (not as in law), I would be happy (after all, I am already happy to have a small regression test generator which initially showed me the problem; if there is interest, it is at http://gitorious.org/picogen/picogen/trees/master/trunk/kallisto/test :) ). Otherwise, I must really stick to hand written RNGs, which are less portable in code, but more portable in sequences, as no RNG-lib I know seems go have this kind of portability as a guideline.
You could try using boost::mt19937 directly without uniform_int. The version of mt19937 in C++0x is guaranteed to produce a specific sequence (Required behavior: The 10000th consecutive invocation of a default-constructed object of type mt19937 shall produce the value 4123659995.), and the Boost.Random version will be kept consistent with the standard. Also, boost::uniform_int should not change again unless there is a bug in it, and I'm about 99% certain that it is completely correct now. In Christ, Steven Watanabe