It was indeed my mistake (as usual). I make my branching array unique by some stl algorithms. unfortuantely, i forgot that IntVar::before and IntVar::same rely on the pointer position, so use of these function can make your program non-deterministic.
Best and thanks for all (and sorry for bugging), Max Code: std::sort(iva_.begin(), iva_.end(), boost::bind(&IntVar::before,_1,_2)); IntVarArgs::iterator newEnd = std::unique(iva_.begin(), iva_.end(), boost::bind(&IntVar::same,_1,_2)); On 06/29/2012 12:22 PM, Guido Tack wrote: > Hi, > > there are three features in Gecode that can result in nondeterministic > behaviour: parallel search, search strategies based on AFC, and > nonmonotonic propagators (currently circuit and nvalues). If you > don't use these features, the search trees will be exactly the same > between runs (even for randomised strategies, as long as you don't > change the random seed). > > Cheers, > Guido > > -- > Guido Tack > http://www.csse.monash.edu/~guidot/ > <http://www.csse.monash.edu/%7Eguidot/> > > > > On 29/06/2012, at 8:10 PM, Max Ostrowski wrote: > >> I have a problem with my software clingcon, that uses gecode. >> >> This piece of software is an SMT solver, that uses gecode as a theory >> solver. >> But i can also use it as a solver for arithmetic, without any SAT >> component. >> >> Now my question: Is the behavior of Gecode reproducible. >> Whenever i start my program with exactly the same parameters, i do get >> the same result (same gecode statistics). >> When i change a parameter (like not printing the solution) i do get a >> different result (in terms of fails, nodes, etc... ). >> >> The parameter i change should not affect Gecode at all (everything >> related to gecode is done with exactly the same input and in the same >> order). >> So do you use some memory position for hashing or some random generator >> initialized according to some position in memory or something else that >> explains this behavior. >> >> Currently i get between 3 and 8615650 fails for a simple LatinSquare >> program, just because i change output formatting. >> >> >> PS: >> I tried this with gecode 3.5, 3.7 and trunk. >> I also tested the whole program with "valgrind --leak-check=full" and >> nothing uninitialized was used or lost. >> >> >> Any ideas? >> >> Best, >> Max >> >> _______________________________________________ >> Gecode users mailing list >> users@gecode.org <mailto:users@gecode.org> >> https://www.gecode.org/mailman/listinfo/gecode-users >
_______________________________________________ Gecode users mailing list users@gecode.org https://www.gecode.org/mailman/listinfo/gecode-users
