Grammar: Rule Sets

Grammar rules are organized into sets, simply called rule sets. These are stored in compact XML files that contain references to each of the grammar rules in the set. All of the details of the rule set can be configured through GraphSynth’s ruleSetDisplay—

there is no need to open a rule set’s XML in an editor (I have only ever done it out of curiosity!).

The top of the pane is a list of the rules added to set. Any number of rules may be added to a rule set by clicking the add rule button. Once rules are in the set their order can be rearranged or they can be subsequently deleted. Along the bottom are three buttons that indicates what to do with the checked rules listed above. The checked rules are deleted by the “del” button, or moved up or down (“dn”) in the list.

Following the list of rules is a list of important rule set properties. Similar to graphs and grammar rules the name will simply be inherited from the filename, and is not internally used within GraphSynth. The next is a property called “triggerRule #.” A trigger rule is one that when invoked during the generation process causes a particular action to occur. Currently, only one triggerRule can be set per rule set. If

there is no intention to use the trigger rule,  then the item should be set to –1. The triggerRule # corresponds to the rule # shown in the top pane.

The next seven properties deal with how the rule set behaves during Generation (It is recommended that this section is well understood before proceeding with this description). The “choiceMethod” is set to either Automatic or Design. An automatic rule set is one that will invoke the rule once it is recognized. This is the case in the example to the right (the example seedBurstRuleSet in the rules directory). When a rule set is set to Automatic, the random tests and user choose tests under the design drop down will not function. This is because the rules fire immediately, skipping the choose part of the generation cycle. Given the methodical approach followed by recognize, we will get the same resulting graph every time with an Automatic ruleset. It will first look for valid locations of the first rule and searching in the host from the first listed nodes on down. This continues for the remaining rules. The important thing to note in automatic rule sets is that latter rules will not be invoked unless all previous rules were unrecognized. This is illustrated well in the seedBurst example. Alternatively, if one knows that their rule set is confluent, then an automatic rule set will work as expected.

“Interim Candidates are” & “Final Candidates are” are properties developed to support latter automated searching of graphs. Often grammars rule sets are created so that only after all rules are invoked is a feasible solution achieved. For such rule sets, we would indicate that Interim Candidates are Developing and Final Candidates are Feasible—as is the case for the seedBurst example shown above. However, in other examples such as the fun swirlSeed example. We set both to Feasible. Users may want to create choosing methods that check these qualities to know if a candidate is complete and subsequent rules are simply modifying it, or if the candidate is Developing towards a Feasible candidate.

The next five properties correspond to the five ways that the Recognize→Choose→Apply generation cycle may end (see Generation). These each can be set to one of the five actions:
Stop : simply end the generation process,
Loop : restart Recognize→Choose→Apply,
GoToPrevious : go to the previous rule set stored in the array
                            Program.rulesets[]
GoToNext : go to the next rule set
GoToRuleSet#n : go to rule set #n
As a result of setting these five properties to any of these five actions, we can greatly control how the rule sets execute. Note that there may be any number of rule sets within a particular synthesis of a graph. We have noticed on several occasions that grammar rule are stored in sets that perform different actions within the overall synthesis. An example of multiple rule sets can be found in the Routes example (RouteGetToSpanningRuleSet.xml and RouteGetToCompleteRuleSet.xml in the rules directory). After the first rule set has run out of rules, then we know that we have created a spanning tree of the nodes in the seed graph (citiesDefaultSeedGraph.xml).  Since “NoRules” is set to GoToNext, the next rule set is invoked to add additional routes between the cities.

Finally, the rule set has properties that list the filenames for recognize or apply parametric functions. These need to be established prior to creating templates for functions in the grammar rule property window. As is shown in the examples, a “.cs” file has been created for each ruleset. Each of these files contains all the functions used by that ruleset. This is not enforced by GraphSynth though. One may have multiple “.cs” files for a ruleset or multiple rulesets referencing the same source file.

 

Note: Because rule sets are stored in a fixed array (Program.rulesets[]), please specify the number in advance in App.config (<numOfRuleSets>).