[gecode-users] Branching allowing values back in the domain

[Mikael Zayenz Lagerkvist]

2010/8/25 Zaremby, David <david.zaremby at lmco.com>

> This is the node before the failed node in question. Notice that task 1
> does not have 105256 in its domain.
>
>
>
> Run using custom propagators:
>
>
>
> task 1: res[ru: 34 ru: 2 s[{105262,105268,105292]]
>
> task 2: res[ru: 29 ru: 5 s[{105292,105298,105304,105508]]
>
> task 3: res[ru: 26 ru: 1 s[105256]]
>
> task 4: res[ru: 33 ru: 39 s[105256]]
>
> task 5: res[ru: 25 ru: 38 s[105256]]
>
> task 6: res[ru: 30 ru: 37 s[105256]]
>
> task 7: res[ru: 32 ru: 40 s[105245]]
>
> task 8: res[ru: 18 ru: 41 s[105245]]
>
> task 9: res[ru: 19 ru: 42 s[105256]]
>
>
>
> This is the failed node to the left side of the node above. Notice that
> somehow it found 105256 to choose for task 1 and this wasn’t in the domain.
> How did it get there?  Since this invalid value was chosen the constraint
> fails.
>
>
>
> task 1: res[ru: 34 ru: 2 s[105256]]
>
> task 2: res[ru: 29 ru: 5
> s[{105256,105262,105268,105292,105298,105304,105508]]
>
> task 3: res[ru: 26 ru: 1 s[105256]]
>
> task 4: res[ru: 33 ru: 39 s[105256]]
>
> task 5: res[ru: 25 ru: 38 s[105256]]
>
> task 6: res[ru: 30 ru: 37 s[105256]]
>
> task 7: res[ru: 32 ru: 40 s[105245]]
>
> task 8: res[ru: 18 ru: 41 s[105245]]
>
> task 9: res[ru: 19 ru: 42 s[105256]]
>

Inspecting a failed node might give odd results, a tell that fails might
have been in the process of modifying a variable. If you want to know what
has been changed by a branching, you can use the Gist feature "Inspect
before fixpoint".

Cheers,
Mikael

-- 
Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20100826/d42eea9e/attachment.htm>