Rule Solver – Decision Tables

Rule Solver allows creators of business decision models to define unknown decision variables, define and post constraints to express their relationships, and rely on predefined search strategies to find with the proper decisions. To do this, Rule Solver introduces new types of decision table columns allowing a user to mix and match business rules with technical constraints within the same decision tables. Rule Solver provides several predefined templates for definition and resolution of constraint satisfaction and optimization problems:

• Defining Constrained Variables
• Posting Constraints
• Constraints with Probabilities
• Defining Optimization Objective
• Search Methods

PROBLEM DEFINITION and PROBLEM RESOLUTION

Decision models that utilize Rule Solver usually use as the main “model.goal=DefineAndSolve” in their Environment table. This goal is predefined as follows:

Thus, your custom decision model only needs to define two sub-decisions:

• “Define” for Problem Definition and
• “Solve” for Problem Resolution.

Here are typical “Define” and “Solve” tables:

DEFINING CONSTRAINED VARIABLES

There are two ways to create Solver decision variables that represent problem unknowns:

• Using “Glossary”
• Using the column “SolverDefineVariables”.

In this example, we define three Solver variables X, Y, and Z, with possible values from 1 to 10 specified in the column “Domain” of the following Glossary:

In the example “FamilyRiddle“, we define two arrays with unknown ages for every child in arrays ReneChildren and LeoChildren:

Solver will create decision variables with possible values from 0 to 9 representing children’s ages.

In the example “Zoo“, we define an array of Solver variables (unknowns) that correspond to the array “BusTypes”:

Their domain is defined as VarDomain, which is another decision variable calculated using the formula “0-” + ${MaxNumberOfBuses} inside the glossary.

When we cannot use a glossary to define Solver decision variables, we may use the predefined column “SolverDefineVariables“. within regular decision tables. In the more complex example “InsideOutSideProduction,” the names of Solver variables are defined dynamically in the loop:

Here, for each product P in the array of Products, we create three Solver variables with names Inside{{ProductId of P}}, Outside{{ProductId of P}}, and Demand{{ProductId of P}}. where {{ProductId of P}} represents the actual product name, so the variable could have names InsideP1. OutsideP2, DemandP2, etc. The first two variables have the same domains Demand{{ProductId of P}}, and the third variable Demand{{ProductId of P}} is defined as a sum of the previous two variables using the formula Inside{{ProductId of P}} + Outside{{ProductId of P}}.

The second column “SolverAddVariableToArray” in this table adds all variables Inside{{ProductId of P}} and Outside{{ProductId of P}} to the Solver array “InsideVariables” and “OutsideVariables” to be used later to express the problem constraints.

The column “” can be used to create new Solver variables using expressions that mix known and unknown decision variables. For instance, this table defines the variable Cost using a regular arithmetic expression:

The following table from the sample “VacationDays” demonstrates the use of the scalar product of the array of Solver variables “Vacation Benefit Types” and the regular integer array “Vacation Benefit Days”:

The names of the arrays are taken into backticks because they contain spaces.

You may find more examples of how to define new Solver variables here.

POSTING CONSTRAINTS

We may post constraints within regular decision tables using the predefined column “SolverPostConstraints“. Here is a simple constraint posting table from “VacationDays“:

Here are simple “Map Coloring” constraints:

Here are examples of more complex constraints from the sample “Where is Zebra?“:

Pay attention to the last three constraints that use a logical operator “or” stating the aa constraint on the left (Kools = Horse +1) or constraint on the right (Kools = Horse -1) should be satisfied.

This table from “Miss Manners” uses the implication operator “->” that supports “if-then” logic:

For instance, the first constraint states that if a guest G1 occupies the first seat, then the guest G2 cannot occupy the second seat.

You may find more constraint posting examples here.

DEFINING OPTIMIZATION OBJECTIVE

If your problem is an optimization problem and needs to define an optimization objective as an expression using other decision variables. For example, in the decision model “Zoo” the optimization objective is “Total Cost” defined as a scalar product of solver variables “Bus Variables” and integer constants “Bus Costs”. To inform Rule Solver that this variable will be used as an optimization objective, we use the following table with the predefined column “SolverSetObjective“:

You may use expressions when defining the objective. Here is an example from “StableMarriages“:

PREDEFINED SEARCH METHODS

With Rule Solver you mainly concentrate on the problem definition, defining decision variables and posting constraints on them. The problem resolution relies on the predefined decision tables with search methods and/or column templates. The most popular predefined search methods are:

• SolverFindSolution – finds a feasible solution
• SolverMinimize – finds a solution that minimizes an already-defined objective
• SolverMaximize – finds a solution that maximizes an already-defined objective

The column “SolverOptimize” defines an objective and calls the proper method to minimize or maximize it:

The method “SolverLogSolution” prints the found solution.

The method “SolverFindAllSolutions” can find ALL solutions and then you can print them using the method “SolverLogSolutions“. If there are too many solutions, you may limit the maximal number of considered solutions using the following table:

Actually, you may define other Solver settings in this table, for instance:

Optimization Strategy can have two values:

• Basic (default), which, after finding one solution, tries to find a next one with a smaller objective.
• Dichotomize, which, after finding one solution, tries to find a next one by dividing the remaining domain of the objective variable into two parts.

All search methods automatically save the found solutions by assigning the found values of Solver variables to the business variables with the same name. However, the names can be different, and you can add your own decision table “SaveSolution” that will be automatically called after a solution (an optimal or feasible) is found. For example, the project “InsideOutsideProduction” includes this table:

Here, the predefined column “SolverAddSolutionToArray” saves all found values of Solver variables Inside{{Product of P}} into the business array “InsideProducedProducts“

You may use the predefined column “SolverAssignSolution” to explicitly assign found values of Solver’s decision variables to business decision variables like in the sample decision model “Invest“:

Here is a more complex example from the sample “Oven“:

You may use a special condition “SolverSolutionCondition” to analyze the found solution and assign problem-specific results like in this table from the sample “StableMarriage“

Analyze the provided example in the folder “openrules.solver” to see more complex use of problem definitions and problem resolutions.