Hi, thanks for the report, I’ve had a quick look and there seem to be some problems in the algorithm, the 10th fixpoint alone does 1.5 million propagations (so it looks like severely slow convergence), and then later every 6th fixpoint is really slow. I’ll have to look into this some more but it does look like a bug.
Cheers, Guido -- Guido Tack http://www.csse.monash.edu/~guidot/ > On 26 May 2015, at 7:39 am, Peter Nightingale <[email protected]> wrote: > > Hi, > > I'll point this out, it's not really a bug but it's something you might want > to look at. The attached flatzinc solves very slowly. > > At first I had no annotation on the global_cardinality constraint and Gecode > took a very long time -- I did not run to completion. I added ::domain to > that constraint and it solves in 109 seconds, 981 nodes -- so the time to > reach a fixed point at each node is about 1/10th second. Minion solves the > equivalent model in 492 left (assignment) branches (I guess the same node > count as gecode) and just over 10 seconds -- so I guess reaching a fixed > point in 1/100 s. > > Does gecode partition the gcc constraint or just remove assigned variables? > That might explain the difference with domain consistency > > Also, did the default propagation level change on gcc? I don't remember this > test causing a problem previously. > > Before you tell me -- I know magic sequence is a stupid benchmark! > > Cheers, > Pete > <magicSequence.eprime.param.fzn.test0>_______________________________________________ > Gecode users mailing list > [email protected] > https://www.gecode.org/mailman/listinfo/gecode-users
_______________________________________________ Gecode users mailing list [email protected] https://www.gecode.org/mailman/listinfo/gecode-users
