[Gecode] Distributors, batch recomputation
Christian Schulte
schulte at imit.kth.se
Wed Jul 14 11:49:37 CEST 2004
Your scenario is of course a desaster for recomputation. However, it is also
a desaster for non-recomputation: the addition of further constraints can
break it anyway (anyt constraint on either a or b will do). So it's boned
anyway.
But what is clear is that I have to come up with an invariant that describes
hwat are you allowed to do when you want to use recomputation. A simple
restriction (the same as used in Oz) is to restrict us to the case that
there is only one branching to be created at any time. That will do.
Christian
--
Christian Schulte, http://www.imit.kth.se/~schulte/
-----Original Message-----
From: gecode-bounces at ps.uni-sb.de [mailto:gecode-bounces at ps.uni-sb.de] On
Behalf Of Guido Tack
Sent: Wednesday, July 14, 2004 11:45 AM
To: Technical discussions about Gecode
Subject: Re: [Gecode] Distributors, batch recomputation
Am Mittwoch, 14. Juli 2004 11:18 schrieb Christian Schulte:
> I follow your conclusions but I do not follow your concerns. In which
> way does branching creation depend on the state of the space? Could
> you please elaborate.
Maybe I haven't really understood the way distributors are created
dynamically, but this is what I have in mind:
The Int::Combinators::Select propagator waits for an int variable to be
assigned and then e.g. creates a new distributor. Assume the following
setup:
intvar a,b
select(create new distributor 1, b)
select(create new distributor 2, a)
distribute naive [a,b]
Now without recomputation, you would probably create the new distributors in
the order 2,1, because a gets determined by distribution before b. In batch
recomputation, however, you do both distribution steps, determining a and b,
before propagation. Now I guess that the selection propagator waiting for b
will be invoked first (or at least I don't see why it shouldn't be ;-), so
the order in which the new distributors are created is 1,2. This will mess
up
the later steps in batch recomputation, because we will try to commit to
descriptions in the original order.
Guido
--
Guido Tack
Programming Systems Lab
http://www.ps.uni-sb.de/~tack
_______________________________________________
Gecode mailing list
Gecode at ps.uni-sb.de http://www.ps.uni-sb.de/mailman/listinfo/gecode
More information about the gecode-users
mailing list