Because so much of an ODML model is grounded in ordinary mathematical expres- sions, a natural direction to explore is the applicability of existing, general-purpose numeric solving engines to the organizational search process. For example, a suitable translation can allow commercial tools such as Mathematica [209] or Maple to handle the symbolic information provided by an ODML. Because these tools generally incor- porate a range of analysis techniques and are optimized for processing mathematical expressions, they may be able to address aspects of the search space in a manner that is more direct and efficient than what has been presented thus far. Ideally, this would result in a savings in both computational time during the search and in the complexity of the ODML-specific search algorithm.
In addition to the efficiency and complexity benefits, by demonstrating how to map portions of an ODML model into such a tool I also hope to create a conceptual bridge between the two representations. To those that are familiar with the tool, such a mapping can then serve to illustrate the decision problems represented in the model and make the underlying concepts more accessible. The remainder of this section will explain how such a mapping was created and exploited by the search process.
The engine that was selected for this mapping was Mathematica, because of its ability to perform symbolic reasoning and the relative ease with which the Math- ematica kernel can be remotely accessed by a separate computational process [96].
The first part of this process is to identify what aspects of the search are suitable for translation, with respect to the capabilities provided by Mathematica. Particularly relevant in this context are Mathematica’s ability to symbolically represent and eval-
uate expressions, its high-level list and value manipulation functions, and its ability find a set of variable assignments that optimize (maximize) the value of a nonlinear expression.
As discussed at the beginning of Section 4.1, there are two types of decision points that must be confronted by the design process: has-a relationships and vari- able assignments. The choices made for the has-a decisions decide the structure of the organization, which in turn decide the arrangement of the underlying equations.
Rather than simply assigning values in expressions, this process manipulates the ex- pressions themselves through the incorporation or removal of equations as structural components are added or removed as a result of different has-a assignments. This decision process does not play to Mathematica’s strengths, which in its optimization mode exists primarily in its ability to manipulating values. Because of this, I do not see Mathematica assisting with this part of the design process. A more fundamental detail is that it is primarily this point that differentiates a pure mathematical model from that provided by ODML. Where a mathematical model is able to find a solution to a set of equations, and ODML model is able to capture problems where such a set of equations is just one alternative among many that must be considered.
Conversely, Mathematica is much better suited to the selection of values for vari- able fields. If we consider just a single variable and the set of expressions it influences, then making a choice for the associated decision point can be thought of as a standard numeric optimization problem. In this case, we wish to find the value for the variable that maximizes some characteristic (e.g., utility) subject to a set of constraints (e.g., the set of constraint fields present in the model). This process naturally extends to the case where there are multiple such variable fields that must be decided.
To successfully and correctly employ this type of optimization technique, the complete set of expressions relating the variables to the utility characteristic and constraints must be known. If we assume that the variables are linked through ex-
pressions to all parts of the organizational structure, the first step of the mapping process is to fix the set of expressions by deciding all known has-a relationships. Al- though I will not do so here, this condition may be relaxed if the technique is used on a subset of variables which are not so connected (see Section 4.2.5).
Recall the has-a relationship definition from Section 2.2.1. The requirement that all has-a relationships be decided implies that the specificmagnitudeof these relation- ships must also be known before the optimization mapping can be produced. These magnitudes can be defined either directly or indirectly in terms of variables, which means those variables must be decided before the optimization process and therefore cannot be addressed by this technique. The same is true of any variables that can affect parameters passed into nodes instantiated for the has-a relations. Choices for all other variables may be deferred during the organizational search process, and ad- dresseden masseby a final optimization phase to complete the search. Thus, the first step in the mapping is to determine which variables must be decided and which may be deferred. This may be accomplished by using the dependency graph described in Section 4.2.1. After the graph has been created, but prior to initiating the search, the magnitude and parameter definitions for all has-a relationships defined in the ODML template are analyzed. Any symbols those definitions reference are noted, and the dependency graph is used to recursively flag all constants, modifiers and variables they depend on. The decision for any variable that is not flagged by this process may be deferred.
After the partial organization has been instantiated so that only un-flagged vari- able decision points remain, the structure can be translated into a form that is ap- propriate for the optimization process. In this case, the following operations must be performed to create an input representation for Mathematica:
1. The expressions encapsulated by ODML’s hierarchy of nodes must be flattened into a single list of equations and relations. Symbol references, which are nor-
mally interpreted within the node’s namespace, must be rewritten to avoid conflicts in the new global namespace. Other syntactical changes to symbol names, numeric constants and lists must also be performed.
2. Where possible, the built-in functions provided by ODML (see Table 2.1), must be converted to an equivalent function in the new representation. For example:
f orallprod(¯x)≡
x∈¯x
x→Apply[Times[¯x]]
If an equivalent function cannot be found, the optimization process will not be possible. Equivalent mappings currently exist for all functions except map and those dealing with discrete distributions (E, V, P r, mc). A complete list is shown in Figure A.2.
3. The domain of deferred variables must be expressed. Currently this is accom- plished with a complete disjunction. For example:
V =1, x2, x+y →(V == (1) || V == (x^2) || V == (x + y))
4. The variables and constraints must each been aggregated into lists that may be provided to the optimization function.
Additional details of this process can be found in Appendix A.
After undergoing this translation, the organizational space captured by the de- ferred variables can be searched by optimizing over the utility function defined by the model. It is worth noting again that because it is operating only on this more restricted space, this process is not solving the entire organizational problem. In this way, the use of a solver such as Mathematica can be viewed as just another analysis technique that can be employed as part of a the larger search of the organizational
A
cpu = <10,20,30>
cost = 10 + cpu / 10
organization
numagents = <1,2,3>
cpu >= 60 utility = - cost
numagents
organization
numagents = 2 cpu >= 60 utility = -cost
A
cpu = <10,20,30>
cost = 10 + cpu / 10
A
cpu = <10,20,30>
cost = 10 + cpu / 10
organization
numagents = 2 cpu >= 60 utility = -cost
A
cpu = 30 cost = 13
A
cpu = 20 cost = 12
(a) (b) (c)
Figure 4.9. Three stages from the search process using an external optimization engine. The original template (a), the instance with deferred variables (b), and the final organizational instance (c).
space. In practice, there will generally be many such invocations of the optimizer, because there will be many different partial organizations created by the earlier search phases, each of which may contain variable choices that have been deferred.
This process is illustrated by a simple example shown in Figures 4.9 and 4.10.
Figure 4.9a shows the initial template. This organization consists of a simple group of agents, where each agent is represented by the node typeA. The variablenumagents indicates the different number of agents permitted in the group. The variable cpu in A indicates the choice of processing power that the agent will take on. This is also reflected in the agent’s cost, which is defined in terms of a fixed base value and a supplemental cost proportional to the cpu. The organizational cpu (defined as the total processing power over all agents) is constrained to have a minimum value of 60.
Utility is negative of the organizationalcost(defined as the totalcostover all agents).
Based on this, the optimal organization will meet some minimum level of processing power while minimizing its cost.
There are two variables present in this template, numagentsand the agent’s cpu.
The former is used as the magnitude of the organization’s has-a relationship with A, and therefore cannot be deferred. The latter has no such restriction, and can be deferred to the optimization process. The overall organizational search will progress
C l e a r [ " Global ‘* " ] v a r i a b l e s = {}
c o n s t r a i n t s = {}
o r g a n i z a t i o n [ a g e n t s ] = { A1 , A2 }
o r g a n i z a t i o n [ n u m a g e n t s ] = R a t i o n a l i z e [ 2 . 0 ]
o r g a n i z a t i o n [ c os t ] = ( Total [ Map [#[ cost ] & , o r g a n i z a t i o n [ a g e n t s ]]]) o r g a n i z a t i o n [ w o r k ] = ( T o t a l [ Map [#[ cpu ] & , o r g a n i z a t i o n [ a g e n t s ]]]) o r g a n i z a t i o n [ u t i l i t y ] = ( - o r g a n i z a t i o n [ cost ])
A p p e n d T o [ c o n s t r a i n t s , ( o r g a n i z a t i o n [ work ] >= ( R a t i o n a l i z e [ 6 0 . 0 ] ) ) ] A p p e n d T o [ v a r i a b l e s , A1 [ cpu ]]
A p p e n d T o [ c o n s t r a i n t s , ( A1 [ cpu ] == ( R a t i o n a l i z e [ 1 0 . 0 ] ) || A1 [ cpu ] ==
( R a t i o n a l i z e [ 2 0 . 0 ] ) || A1 [ cpu ] == ( R a t i o n a l i z e [ 3 0 . 0 ] ) ) ] A1 [ cost ] = ( R a t i o n a l i z e [ 1 0 . 0 ] )
A p p e n d T o [ v a r i a b l e s , A2 [ cpu ]]
A p p e n d T o [ c o n s t r a i n t s , ( A2 [ cpu ] == ( R a t i o n a l i z e [ 1 0 . 0 ] ) || A2 [ cpu ] ==
( R a t i o n a l i z e [ 2 0 . 0 ] ) || A2 [ cpu ] == ( R a t i o n a l i z e [ 3 0 . 0 ] ) ) ] A2 [ cost ] = ( R a t i o n a l i z e [ 1 0 . 0 ] )
M a x i m i z e [ o r g a n i z a t i o n [ u t i l i t y ] , c o n s t r a i n t s , v a r i a b l e s ]
Figure 4.10. The result of the ODML translation process. This code is passed into Mathematica to perform the optimization.
by producing a series of partial instances that can be passed to the optimization. An example of such an instance can be seen in Figure 4.9b. This was then translated into the set of Mathematica statements shown in Figure 4.10. In that code, the constraints and variables lists are used to contain their respective information.
These are eventually passed into theMaximizefunction at the bottom, which performs the optimization process. The result of this process is a pair of bindings for the two cpu variables, which are then used to produce the final instance in Figure 4.9c.
Agents were assigned cpu values of 30 and 20, which meets the high level constraint on organizational cpu while producing the minimum total cost of 25.
A depiction of the performance obtained when using Mathematica to maximize the value of deferred variables is shown in Figure 4.11. This graph was produced by comparing the performance using the numeric solver to the centralized search techniques described in previous sections across ten scenarios. Each scenario searched through the space defined by a variant of the template depicted in Figure 4.9a. The
1 10 100 1000 10000 100000
Time Elapsed (sec)
Maximum Number of Agents
1 2 3 4 5 6 7 8 9 10
Conventional Search Mathematica
Figure 4.11. Performance of the numeric solver versus conventional search across different problem complexities.
complexity of this search was increased in each subsequent scenario by changing the numagents variable, which increases the number of agents allowed. For example, in nth trial numagents = 1, . . . , n. The organizational performance constraint was cpu ≥ n×30. Each search sought to maximize the organization’s utility, although the prior constraint caused just a single alternative in the template’s space to be valid. All experiments were performed sequentially on the same processor.
As the graph shows, using the solver resulted in dramatically longer search times as the problem complexity grew (note the ordinate axis is logarithmic). At the most extreme point tested, the conventional search required 50 seconds to find a solution that took Mathematica 62 hours. My hypothesis for this behavior is that, because Mathematica’s maximization function naturally operates over a continuous space, it is ill-suited to search through the discrete space presented by ODML. This may cause it to explore impossible variable assignments that the conventional search would ignore simply because they are not in the variable’s domain, which would result in the longer running time. Other engines capable of attacking ODML’s optimization problem in different ways may be more effective than what is presented here.