[gecode-users] Global cardinality slow

[Guido Tack]

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 <pwn1 at st-andrews.ac.uk> 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
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20150527/3589cf9a/attachment.html>