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
The bottom up enumerator maintains a bank of subprograms to insert into a new larger program. Infeasible subprograms may become feasible when inserted in a larger program. Therefore, the program bank should also contain infeasible programs.
However, sometimes the inconsistency of a subprogram is within the subprogram itself. In that case, it will never yield a feasible program, even when inserted in a larger program. I would be great if states can be marked as 'always infeasible' in this case.
The following example demonstrates the three levels of (in)feasibility:
Feasible. The subprogram itself satisfies the constraints.
Infeasible The subprogram does not satisfy the constraints but could become feasible when part of a larger program.
Always infeasible The subprogram will never satisfy the constraints, even when it is a part of an arbitrary larger program.
grammar =@csgrammarbegin
Number =1
Number =2
Number = x
Number = Number + Number
endaddconstraint!(grammar, Forbidden(RuleNode(2))) #prevents rule 2 from ever occurring in the programaddconstraint!(grammar, Contains(3)) #enforces that rule 3 must be used in the program#This subprogram is already a feasible program by itself
feasible_subprogram =RuleNode(4, [RuleNode(3), RuleNode(3)])
#This subprogram does not satisfy the Contains(3) constraint, so it is infeasible#However, when inserted in a larger program that already contains rule 3, it might be feasible
infeasible_subprogram =RuleNode(4, [RuleNode(1), RuleNode(1)])
#This subprogram holds the forbidden subtree RuleNode(2), so it is infeasible#Even when inserted in a larger program, it will still hold RuleNode(2)
always_infeasible_subprogram =RuleNode(4, [RuleNode(2), RuleNode(2)])
Why is this not here yet?
This is an optimization for different iterator types and won't affect the TopDownIterator at all.
Since my thesis does not concern bottom-up enumeration, I will focus on other issues instead.
The text was updated successfully, but these errors were encountered:
The bottom up enumerator maintains a bank of subprograms to insert into a new larger program. Infeasible subprograms may become feasible when inserted in a larger program. Therefore, the program bank should also contain infeasible programs.
However, sometimes the inconsistency of a subprogram is within the subprogram itself. In that case, it will never yield a feasible program, even when inserted in a larger program. I would be great if states can be marked as 'always infeasible' in this case.
The following example demonstrates the three levels of (in)feasibility:
Why is this not here yet?
This is an optimization for different iterator types and won't affect the
TopDownIterator
at all.Since my thesis does not concern bottom-up enumeration, I will focus on other issues instead.
The text was updated successfully, but these errors were encountered: