As described previously in Section 4.2.3, it is possible to translate portions of the ODML search space into a representation that may be interpreted by a general mathematical solver. It is recommended that the reader read that section before continuing. This appendix will provide additional details of that process, including tables which define equivalent mappings into Mathematica’s expression language.
A successful translation can take place on any ODML partially-instantiated model that does not have any unbound variables that can affect a has-a relationship and does not contain functions that lack an appropriate mapping. The floating point and list data types from Section 2.2.3 are supported, but discrete distributions currently are not and therefore should also not be present. Given such an instance, the translation process operates starting from the root node and continuing recursively to all nodes the initial node has a has-a relationship with.
The translation of a node N begins by listing its has-a relationships. Each rela- tionship H the node has is specified as a list with the form N[H] = {n1, . . ., nn}, where n is the unique name of another node in the organization. The parameters passed to N when it was created are listed next, followed by the node’s fields (con- stants, constraints, modifiers and variables). These are translated as shown in Table A.1 (cf. the elements list in Section 2.2.1). The expressions are differentiated in italics because they will undergo further translation, as outlined below.
Because symbolic references within nodes are considered local, ODML’s names- pace is broken into isolated parts. Mathematica’s namespace is flat, so to avoid
Type Contents Mathematica Equivalent Parameter N.P =s, e N[s] = e
Constant N.C =s, e N[s] = e
Constraint K =N[s], op, e AppendTo[constraints, N[s] op e]
Modifier N.M =s, op, e N[s] = N[s] op e Variable (bound) N.V =s, e N[s] = e
Variable (unbound) N.V =s, {e1, . . . , en}
AppendTo[variables, N[s]]
AppendTo[constraints,
(N[s] == e1 || . . . || N[s] == en)]
Table A.1. ODML model element to Mathematica translation table.
introducing collisions in translation, all symbols must be rewritten to take into ac- count their node of origin. This is done by prefixing them with the node’s name, which is guaranteed to be unique. For example, the constant c in N would become N.c. In addition, Mathematica does not natively support a notion of an “object”
(i.e., a structure with a set of named characteristics or methods), or the dot-notation syntax that ODML uses to reference nonlocal characteristics. To overcome this limi- tation, I abuse Mathematica’s function notion by creating a set of functions for each node, where each function defines a single characteristic (e.g., parameter, field, etc.) for that node. For example, the node:
<node name="A">
<constant name="x">1</constant>
<constant name="y">x + 1</constant>
</node>
. . . would be defined with the functions:
A[x] = 1
A[y] = A[x] + 1
From Mathematica’s perspective, A is actually the name of a function that has been overloaded to supply two different expressions depending on the parameter that
is passed in. When called, the parameter is the name of a characteristic in the original node A, which allows it to simulate the desired behavior despite the fact that there is no true object backing the definition. Because function names may be stored and referenced directly in Mathematica, chained object references can be simulated as well. For example, if A[x] = 10 and B[y] = A, then B[y][x] would produce the desired value of 10, just as if B[y]actually contained a reference to the node A.
This is an abuse of the function notation because it relies upon the fact that x and y are unbound symbols in the resulting set of equations. This has the side effect of causing Mathematica to maintain the intended definitions. If, however, x and y were subsequently set to some common value (say the numeric constant 5), then both definitions would resolve to A[5], and one of the two definitions would be lost.
Because all symbols are prefixed by node names during the translation and the global scope is cleared before beginning, this cannot occur during the maximization process outlined earlier.
The remainder of the translation revolves around the expressions themselves. Be- cause most of ODML’s expression syntax uses standard infix notation, the majority of a typical expression can be passed in unchanged. There are two important differences.
The first is that numeric constants, such as the literal “25.0”, are wrapped with the Rationalize function (e.g., Rationalize[25.0]). This causes Mathematica to treat them as exact rational value, rather than reals, which are only approximations. This allows the output of the maximization process to respect the intuitive meaning of certain inequalities when used in a discrete variable context. This is demonstrated in the following two variants of the same maximization process:
In := Maximize[u, (u == 9.0] || u == 10.0) && (u < 10.0), u]
Out := {10., {u -> 10.}}
In := Maximize[u, (u == Rationalize[9.0] || u == Rationalize[10.0])
ODML Function Mathematica Equivalent min(x1, . . . , xn) Min[x1,. . .,xn]
max(x1, . . . , xn) Max[x1,. . .,xn]
abs(x) Abs[x]
choose(x, y) ((x)!/((x-y)!y!))
sqrt(x) Sqrt[x]
round(x) Round[x]
map(x, y1v, ye1, y2v, y2e, . . . ,∗,∗e) Currently not supported.
list(x1, . . . , xn) Flatten[x1,. . .,xn] listitem(¯x, i) Part[x,¯ i]
size(¯x) Length[Flatten[¯x]]
unique(¯x) Union[x]¯ f orall(y,x, e)¯ Map[e’ &, x],¯
where e’ = (e =~ s/y/#/g) f orrange(y, xl, xh, e) Map[e’ &, Range[xl, xh - 1]],
where e’ = (e =~ s/y/#/g) f orallsum(¯x) Total[x]¯
f orallprod(¯x) Apply[Times, x]¯ f orallavg(¯x) Mean[x]¯
f orallstddev(¯x) StandardDeviation[x]¯ E(D) Currently not supported.
V(D) Currently not supported.
P r(D, op, x) Currently not supported.
mc(D, seed) Currently not supported.
Table A.2. ODML built-in function to Mathematica translation table.
&& (u < Rationalize[10.0]), u]
Out := {9, {u -> 9}}
Notice that in the first maximization the strict inequality was not respected, while in the second it was.
The second aspect of expression translation is the mapping of ODML’s built-in functions into something equivalent using Mathematica’s intrinsic functions. The currently implemented mappings are shown in Table A.2. Each ODML expression is scanned during translation, and when such a function is found it is converted as the table indicates. An example of this translation is shown in Figure 4.10.