Talk:AC-3 algorithm

I'm not sure the pseudocode is right: the arc-reduce(x,y) function only reduces the domain of x, therefore you also need to call arc-reduce(y,x) to reduce the domain of y and add (z,y) arcs to the worklist if it was indeed reduced. This is done once in the current implementation, as the code for initiating the worklist

worklist := { (x, y) | there exists a relation R2(x, y) or a relation R2(y, x) }

puts (x,y) and (y,x) in the worklist. However, suppose we have reduced the domain of x while checking (x,y), then later reduced the domain of y for the first time while checking (y,x) (hence, with the current implementation, the (x,y) arc is not put back in the worklist). Isn't it possible that this reduction of the domain of y implies a reduction of the domain of x ?

If so, you just need to change

worklist := worklist + { (z, x) | z != y and there exists a relation R2(x, z) or a relation R2(z, x) }

to

worklist := worklist + { (z, x) | there exists a relation R2(z, x) or a relation R2(z, x) }

If you're not sure either, that version works anyway.

Also, I'm wondering if directed constraints exist (a constraint R2(x,y) such that you need to check the domain of x if the domain of y has been reduced but not the opposite). If so, it would be better to change

worklist := { (x, y) | there exists a relation R2(x, y) or a relation R2(y, x) }

to

worklist := { (x, y) | there exists a relation R2(x, y) }

Thanks for your time.

Baha2490 (talk) 00:58, 6 March 2013 (UTC)


 * The pseudo code is right. The main benefit of AC3 over other weaker propagation algorithms is that, once you finish arc-reduce(x,y), you don't need to check anything of y nor add (y, x) to the worklist - everything that could be pruned in x because of y will have been checked and taken care of. Also pruning a value in x won't affect y, because a value is pruned from x only when no values in y are connected to it.
 * This works because constraints are 'not' directed - if there's a value Y in D(y) that supports a value X in D(x), then the the inverse is also true - the X value also supports the Y value.
 * I'd say that the paragraph which describes the CSP as directed graphs is misleading - the consistency between arcs is directed (when x->y is arc-consistent, y->x may not be; this depends on the current state of the variable domains), but at a different level the definition of the constraints must be symmetric ( R(x,y)=R(y,x), and this depends only on the mathematical definition of the constraints, not on the algorithm current state ). Diego (talk) 10:15, 6 March 2013 (UTC)


 * "Also pruning a value in x won't affect y, because a value is pruned from x only when no values in y are connected to it. This works because constraints are 'not' directed" Ok, that part wasn't clear in my mind. Thanks again. One last detail : "all the arcs of constraints including that pruned variable (except the current arc) are added to the collection" should become "all the arcs of constraints pointing to that pruned variable (except the arc of the current constraint) are added to the collection" if I'm not mistaken again. And shall we leave this discussion on the talk page or erase it ? Baha2490 (talk) 02:18, 7 March 2013 (UTC)
 * You're right, arcs starting at the pruned variable x and pointing to a different variable z are not added when pruning according to the algorithm; all arcs are included just once at the initialization, or later when a variable may lose support because a neighbor variable is pruned. I recommend that you read the original paper here (algorithms AC2 and AC3 are on page 106).
 * Talk pages are for improving the article. If there's an error in the article, this conversation can uncover it, so there's no reason to delete it. Diego (talk) 07:13, 7 March 2013 (UTC)

Early version too inefficient, later versions difficult to implement => often taught algorithm!?
The text says that because of inefficiencies of early implementations and difficulties of modern implementations: "... and so AC-3 is the one most often taught ...". I don't understand this conclusion. I suspect this needs to be reworded? 91.2.85.9 (talk) 18:22, 3 March 2016 (UTC)