| Both sides previous revision Previous revision Next revision | Previous revision |
| reference:rules [2016/03/14 13:42] – [Production rules] gawrilow | user_guide:extend:rules [2021/01/12 15:38] (current) – external edit 127.0.0.1 |
|---|
| === Labels === | === Labels === |
| |
| Labels allow to control the choice of rules by the scheduler via [[:general#preferences|preference lists]] manipulated by the user. Usually, rules with similar functionality are assigned labels with common tail part and different first limbs. For example, different rules solving LP with the simplex method are labeled with ''cdd.simplex'', ''lrs.simplex'', etc. After the user has issued a command ''%%prefer "cdd";%%'' the rule with ''lrs'' label is not considered by the scheduler until the ''cdd'' rule has failed on the object being processed. In the absence of active preference lists, labeled rules are treated the same way as unlabeled ones. | Labels allow to control the choice of rules by the scheduler via [[:user_guide:howto:shell_custom#preferences|preference lists]] manipulated by the user. Usually, rules with similar functionality are assigned labels with common tail part and different first limbs. For example, different rules solving LP with the simplex method are labeled with ''cdd.simplex'', ''lrs.simplex'', etc. After the user has issued a command ''%%prefer "cdd";%%'' the rule with ''lrs'' label is not considered by the scheduler until the ''cdd'' rule has failed on the object being processed. In the absence of active preference lists, labeled rules are treated the same way as unlabeled ones. |
| |
| Besides this, labels are involved in the overriding mechanism, and, finally, there are some special labels completely changing the semantics of the rule. Both are described further on this page. | Besides this, labels are involved in the overriding mechanism, and, finally, there are some special labels completely changing the semantics of the rule. Both are described further on this page. |
| === Permutations === | === Permutations === |
| |
| A production rule can [[permutations#Triggering the permutation|trigger a permutation]] if it produces some properties sensitive to this permutation without reading any other properties being as well sensitive to it. While the threat of triggering could in most cases be detected automatically by analyzing the rule header, we prefer to state this explicitly by putting the following adornment line: | A production rule can [[permutations#Creating permuted subobjects|incur a permutation]] if it produces some properties sensitive to this permutation without reading any other properties being as well sensitive to it. While the threat of triggering could in most cases be detected automatically by analyzing the rule header, we prefer to state this explicitly by putting the following adornment line: |
| permutation : PermutationName; | incurs PermutationName; |
| |
| As a little aid, there is a script ''list_suspicious_rules'' which performs the analysis of all production rules in an application and prints the headers of rules which could trigger a permutation but does not state it. | As a little aid, there is a script ''list_suspicious_rules'' which performs the analysis of all production rules in an application and prints the headers of rules which could incur a permutation but does not state it. |
| |
| Currently a production rule can't be declared to trigger more than one permutation. | Currently, a production rule can't be declared to incur more than one permutation. |
| |
| ==== Rules operating on multiple subobjects ==== | ==== Rules operating on multiple subobjects ==== |
| rule nonexistent : CYCLES : VertexPerm.CYCLES, VertexPerm.PERMUTATION; | rule nonexistent : CYCLES : VertexPerm.CYCLES, VertexPerm.PERMUTATION; |
| indicates that property CYCLES is dependent on the vertex order, and if some other rule (declared as possibly triggering VertexPerm) creates CYCLES while the object already contains other properties depending on the vertex order, it will be completely in vain, because there is no way to rearrange the CYCLES such that they fit the original vertex order. (Actually, the CYCLES could easily be rearranged, but for some political reasons this has not been implemented yet.) | indicates that property CYCLES is dependent on the vertex order, and if some other rule (declared as possibly triggering VertexPerm) creates CYCLES while the object already contains other properties depending on the vertex order, it will be completely in vain, because there is no way to rearrange the CYCLES such that they fit the original vertex order. (Actually, the CYCLES could easily be rearranged, but for some political reasons this has not been implemented yet.) |
| | |