You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A LocalOrdered constraint with an order of n symbols is responsible for enforcing an "<=" operation on n-1 pairs of nodes. This could be split up into n-1 smaller constraints instead. For example:
Suppose LocalOrdered(path, tree, [:x, :y]) is already satisfied. Then we don't have to check it when propagating LocalOrdered(path, tree, [:y, :z]).
But in the current implementation, LocalOrdered(path, tree, [:x, :y, :z]) will always first check if VarNode(:x) <= VarNode(:y), which is known to be true after the first check, and then actually propagate VarNode(:y) <= VarNode(:z)
Why is this not helpful?
This doubles the amount of local constraints produced, which arguably causes more overhead than the potential upside
The text was updated successfully, but these errors were encountered:
A
LocalOrdered
constraint with an order ofn
symbols is responsible for enforcing an "<=" operation onn-1
pairs of nodes. This could be split up inton-1
smaller constraints instead. For example:Why is this helpful?
Suppose
LocalOrdered(path, tree, [:x, :y])
is already satisfied. Then we don't have to check it when propagatingLocalOrdered(path, tree, [:y, :z])
.But in the current implementation,
LocalOrdered(path, tree, [:x, :y, :z])
will always first check ifVarNode(:x) <= VarNode(:y)
, which is known to be true after the first check, and then actually propagateVarNode(:y) <= VarNode(:z)
Why is this not helpful?
This doubles the amount of local constraints produced, which arguably causes more overhead than the potential upside
The text was updated successfully, but these errors were encountered: