change in docs texttt

docs/source/block_definitions.rst

@@ -2,7 +2,7 @@ Block Definitions
 -----------------
 
 In order to implement an instance of the abstract GBOML problem, the model must be encoded in an input file written in the GBOML grammar.
-This input file is structured into blocks, which are introduced by one of the following keywords, namely :math:`\texttt{\#TIMEHORIZON}`, :math:`\texttt{\#GLOBAL}`, :math:`\texttt{\#NODE}`, and :math:`\texttt{\#HYPEREDGE}`. The time horizon information is given in the :math:`\texttt{\#TIMEHORIZON}` block, which must be the first one defined in the input file. Global parameters must be defined in the :math:`\texttt{\#GLOBAL}` block, which must come in second position. Then, each node can be defined in a :math:`\texttt{\#NODE}` block, while each hyperedge can be defined in a :math:`\texttt{\#HYPEREDGE}` block. Note that the order in which :math:`\texttt{\#NODE}` and :math:`\texttt{\#HYPEREDGE}` blocks appear in the input file does not matter (i.e., hyperedge definitions may precede node definitions and vice-versa). Thus, an input file is typically structured as follows:
+This input file is structured into blocks, which are introduced by one of the following keywords, namely ``#TIMEHORIZON``, ``#GLOBAL``, ``#NODE``, and ``#HYPEREDGE``. The time horizon information is given in the ``#TIMEHORIZON`` block, which must be the first one defined in the input file. Global parameters must be defined in the ``#GLOBAL`` block, which must come in second position. Then, each node can be defined in a ``#NODE`` block, while each hyperedge can be defined in a ``#HYPEREDGE`` block. Note that the order in which ``#NODE`` and ``#HYPEREDGE`` blocks appear in the input file does not matter (i.e., hyperedge definitions may precede node definitions and vice-versa). Thus, an input file is typically structured as follows:
 
 .. code-block:: c
 

docs/source/commandline_interface.rst

@@ -7,7 +7,7 @@ The GBOML parser can be called from the command line by typing the following com
 
    gboml <file> <options>
 
-where :math:`\texttt{<file>}` is the name of the file to be considered and :math:`\texttt{<options>}` corresponds to one or several optional flags that can be activated.
+where ``<file>`` is the name of the file to be considered and ``<options>`` corresponds to one or several optional flags that can be activated.
 
 The options are the following :
 
@@ -110,7 +110,7 @@ where ``<opt_file>`` is the name of the file containing the solver parameters. I
 
    --solver_lib <path_to_library>
 
-where :math:`\texttt{<path\_to\_library>}` is the library path to read. If :math:`\texttt{solver\_lib}` is not set, the default solver on the library PATH is used.
+where ``<path_to_library>`` is the library path to read. If ``solver_lib`` is not set, the default solver on the library PATH is used.
 
 
 * *CSV*: the solution can be printed to a CSV file on a row basis (e.g., one variable per row):
@@ -143,7 +143,7 @@ where :math:`\texttt{<path\_to\_library>}` is the library path to read. If :math
 
 	--nb_processes <number>
 
-where :math:`\texttt{<number>}` is an integer, whose default value is 1.
+where ``<number>`` is an integer, whose default value is 1.
 
 * *Output*: the name of the output file can be defined with:
 
@@ -151,4 +151,4 @@ where :math:`\texttt{<number>}` is an integer, whose default value is 1.
 
 	--output <output_filename>
 
-where :math:`\texttt{<output\_filename>}` is the output filename without the extension (CSV or JSON). The default output name is the name of the GBOML file with the date and chosen extension.
+where ``<output_filename>`` is the output filename without the extension (CSV or JSON). The default output name is the name of the GBOML file with the date and chosen extension.

docs/source/comments.rst

 Comments
 ========
 
-Comments are initiated by a double forward slash :math:`\texttt{//}` and terminated by a line feed. The content that follows is ignored by the compiler.
+Comments are initiated by a double forward slash ``//`` and terminated by a line feed. The content that follows is ignored by the compiler.

docs/source/global_parameters.rst

 Global Parameters
 =================
 
-The non-mandatory :math:`\texttt{\#GLOBAL}` block contains the definitions of parameters that can be accessed anywhere in the model. This block is structured as follows:
+The non-mandatory ``#GLOBAL`` block contains the definitions of parameters that can be accessed anywhere in the model. This block is structured as follows:
 
 .. code-block:: c
 
@@ -9,7 +9,7 @@ The non-mandatory :math:`\texttt{\#GLOBAL}` block contains the definitions of pa
    // global parameter definitions
 
 
-A parameter definition maps an identifier to a fixed value, which may be either a scalar or a vector. The identifier must be unique within a given :math:`\texttt{\#GLOBAL}` block and a value can be assigned to a parameter through one of the following three syntax rules:
+A parameter definition maps an identifier to a fixed value, which may be either a scalar or a vector. The identifier must be unique within a given ``#GLOBAL`` block and a value can be assigned to a parameter through one of the following three syntax rules:
 
 .. code-block:: c
 
@@ -21,7 +21,7 @@ First, a scalar parameter is defined according to the first rule. Therein, :math
 Second, a vector parameter can be defined directly by providing a comma-separated list of values according to the second rule. Therein, each :math:`\texttt{<term>}` may be a floating-point number, a previously-defined scalar parameter, or an entry of a previously-defined vector parameter. The resulting vector parameter can be indexed in order to retrieve its constituent entries.
 Third, a vector parameter can be defined by providing an input file according to the third rule. Therein, :math:`\texttt{<filename>}` refers to an input file in one of several delimiter-separated formats. The supported delimiter characters are comma, semicolon, space, and line feed. In contrast to the direct way of defining a vector parameter, the input file may only contain floating-point values and may not refer to other parameters.
 
-Given these syntax rules, the following is an example of a valid :math:`\texttt{\#GLOBAL}` block:
+Given these syntax rules, the following is an example of a valid ``#GLOBAL`` block:
 
 .. code-block:: c
 

docs/source/hierarchical_models.rst

@@ -3,7 +3,7 @@ Hierarchical Models
 
 In the hierarchical hypergraph abstraction underpinning the GBOML language, each node can itself be viewed as a hierarchical hypergraph. Nodes may therefore be constructed in a bottom-up fashion, from *sub-nodes* linked by *sub-hyperedges*.
 
-Sub-nodes and sub-hyperedges are defined between the :math:`\texttt{\#PARAMETERS}` and :math:`\texttt{\#VARIABLES}` blocks of a parent node. Thus, a typical hierarchical block :math:`\texttt{\#NODE}` is structured as follows:
+Sub-nodes and sub-hyperedges are defined between the ``#PARAMETERS`` and ``#VARIABLES`` blocks of a parent node. Thus, a typical hierarchical block ``#NODE`` is structured as follows:
 
 .. code-block:: c
 

docs/source/hyperedges.rst

 Hyperedges
 ----------
 
-A hyperedge typically couples variables belonging to different nodes via equality or inequality constraints (or both). Each hyperedge is defined using a dedicated code block. This code block must be started by either the :math:`\texttt{\#HYPEREDGE}` keyword or the :math:`\texttt{\#LINK}` keyword (the two can be used interchangeably). A hyperedge must have a unique :math:`\texttt{<identifier>}` and no two hyperedges or hyperedge and node may have the same identifier. In addition, a hyperedge may have its own parameters and constraints.
+A hyperedge typically couples variables belonging to different nodes via equality or inequality constraints (or both). Each hyperedge is defined using a dedicated code block. This code block must be started by either the ``#HYPEREDGE`` keyword or the :``#LINK`` keyword (the two can be used interchangeably). A hyperedge must have a unique :math:`\texttt{<identifier>}` and no two hyperedges or hyperedge and node may have the same identifier. In addition, a hyperedge may have its own parameters and constraints.
 Hence, valid hyperedge blocks have the following structure:
 
 .. code-block:: c
@@ -23,13 +23,13 @@ Parameters and constraints are further described below.
 Parameters
 ==========
 
-Parameters defined in a :math:`\texttt{\#HYPEREDGE}` block follow the exact same rules as the ones defined in :math:`\texttt{\#NODE}` blocks.
+Parameters defined in a ``#HYPEREDGE`` block follow the exact same rules as the ones defined in ``#NODE`` blocks.
 
 Constraints
 ===========
 
-While affine constraints involving all variables declared in a :math:`\texttt{\#NODE}` block can be defined in the same block, constraints defined in :math:`\texttt{\#HYPEREDGE}` blocks couple :math:`\texttt{external}` variables associated with any subset of nodes.
-The syntax for defining constraints is otherwise the same as the one used in :math:`\texttt{\#NODE}` blocks:
+While affine constraints involving all variables declared in a ``#NODE`` block can be defined in the same block, constraints defined in ``#HYPEREDGE`` blocks couple :math:`\texttt{external}` variables associated with any subset of nodes.
+The syntax for defining constraints is otherwise the same as the one used in ``#NODE`` blocks:
 
 .. code-block:: c
 
@@ -44,7 +44,7 @@ Similarly to the constraints defined in nodes, hyperedges can also be named by a
 
     \texttt{<constraint identifier>: <constraint>;}
 
-Given these syntax rules, the following is an example including valid hyperedge blocks (and associated :math:`\texttt{\#NODE}` blocks):
+Given these syntax rules, the following is an example including valid hyperedge blocks (and associated ``#NODE`` blocks):
 
 .. code-block:: c
 

docs/source/identifiers.rst

@@ -8,7 +8,7 @@ Accordingly, the following identifiers are all valid,
     :nowrap:
 
     \begin{align*}
-        \texttt{mynode1}, \qquad \texttt{\_SolarPlant\_2}, \qquad \texttt{HydroStorage\_a}.
+        ``mynode1``, \qquad ``_SolarPlant_2``, \qquad ``HydroStorage_a``.
     \end{align*}
 
 Besides these lexical requirements, identifiers must also be unique in their respective scope. Hence, no two nodes may have the same identifier since this would prohibit the unambiguous identification of a particular node.

docs/source/logical_conditions.rst

@@ -9,4 +9,4 @@ Let :math:`\texttt{t}` denote an integer. Then, the following logical conditions
 
     \texttt{t > 0 and t <= 10}, \qquad \texttt{t < 2 or t > 4}, \qquad \texttt{not mod(t,5) == 0}.
 
-Note that conditions can be used to selectively enforce constraints over a subset of indices, which is discussed when introducing the :math:`\texttt{\#CONSTRAINTS}` block.
+Note that conditions can be used to selectively enforce constraints over a subset of indices, which is discussed when introducing the ``#CONSTRAINTS`` block.

docs/source/nodes.rst

@@ -3,9 +3,9 @@ Nodes
 
 In the hypergraph abstraction of optimization problems underpinning the GBOML language, nodes represent optimization subproblems. Hence, each node has its own set of parameters. It is also equipped with a set of variables, which are split into *internal* and *external* (or *coupling*) variables. In addition, a set of constraints can be defined for each node, along with a local objective function representing its contribution to a system-wide objective.
 
-A unique identifier must be assigned to each :math:`\texttt{\#NODE}` block, and such a block is further divided into code blocks where parameters, variables, constraints, and objectives can  be defined.
-Each of these blocks is introduced by one of the following keywords, namely :math:`\texttt{\#PARAMETERS}`, :math:`\texttt{\#VARIABLES}`, :math:`\texttt{\#CONSTRAINTS}`, and :math:`\texttt{\#OBJECTIVES}`.
-A typical :math:`\texttt{\#NODE}` block is therefore structured as follows:
+A unique identifier must be assigned to each ``#NODE`` block, and such a block is further divided into code blocks where parameters, variables, constraints, and objectives can  be defined.
+Each of these blocks is introduced by one of the following keywords, namely ``#PARAMETERS``, ``#VARIABLES``, ``#CONSTRAINTS``, and ``#OBJECTIVES``.
+A typical ``#NODE`` block is therefore structured as follows:
 
 .. code-block:: c
 
@@ -24,9 +24,9 @@ These different code blocks are discussed in further detail below.
 Parameters
 ==========
 
-The parameters defined within a given :math:`\texttt{\#NODE}` block respect the same rules as those defined in the :math:`\texttt{\#GLOBAL}` block. However, node parameters are local to the present node and parameters defined in different nodes cannot be accessed in this scope.
+The parameters defined within a given ``#NODE`` block respect the same rules as those defined in the ``#GLOBAL`` block. However, node parameters are local to the present node and parameters defined in different nodes cannot be accessed in this scope.
 
-For the sake of illustration, the following :math:`\texttt{\#PARAMETERS}` block is valid in GBOML:
+For the sake of illustration, the following ``#PARAMETERS`` block is valid in GBOML:
 
 .. code-block:: c
 
@@ -38,7 +38,7 @@ Variables
 =========
 
 Variables are declared with one of the two keywords :math:`\texttt{internal}` and :math:`\texttt{external}`. While :math:`\texttt{internal}` variables are meant to model the internal state of a node, :math:`\texttt{external}` variables are meant to model the interaction between different nodes.
-That is, the coupling between nodes is modeled by imposing constraints on their :math:`\texttt{external}` variables (which is further discussed when introducing :math:`\texttt{\#HYPEREDGE}` blocks). In addition, variables can represent either a scalar or a vector. The syntax for declaring variables in GBOML is as follows:
+That is, the coupling between nodes is modeled by imposing constraints on their :math:`\texttt{external}` variables (which is further discussed when introducing ``#HYPEREDGE`` blocks). In addition, variables can represent either a scalar or a vector. The syntax for declaring variables in GBOML is as follows:
 
 .. code-block:: c
 
@@ -51,7 +51,7 @@ Variables defined only by an identifier are scalar variables, with the identifie
 
 Furthermore, variables can be of different types, which can be specified by using one additional keyword when declaring a variable, namely :math:`\texttt{continuous}`, :math:`\texttt{integer}` or :math:`\texttt{binary}`. Note that if no keyword is specified, variables are assumed to be continuous by default.
 
-Given these syntax rules, the following :math:`\texttt{\#VARIABLES}` block is valid in GBOML:
+Given these syntax rules, the following ``#VARIABLES`` block is valid in GBOML:
 
 .. code-block:: c
 
@@ -73,7 +73,7 @@ The syntax rules for the definition of basic equality and inequality constraints
  <expression> >= <expression>;
 
 Therein, both the left-hand side and the right-hand side of the constraints are general expressions while the type of the constraint is indicated by the comparison operator used.
-Furthermore, in line with the fact that parameter and variable definitions are local to a given node, constraints defined in a :math:`\texttt{\#NODE}` block must not reference quantities that are defined in other nodes.
+Furthermore, in line with the fact that parameter and variable definitions are local to a given node, constraints defined in a ``#NODE`` block must not reference quantities that are defined in other nodes.
 
 An identifier can be also be assigned to constraints when defining them. The following syntax can be used to do so:
 
@@ -182,10 +182,10 @@ The syntax rules for the definition of objectives are as follows:
  min : <expression> <expansion range>;
  max : <expression> <expansion range>;
 
-At least one node in a given model must possess at least one objective but all nodes may have multiple objectives. In case multiple objectives are given in the same :math:`\texttt{\#NODE}` block, all objectives are aggregated into a single one by summing them (respecting the sign associated with the keywords :math:`\texttt{min}` and :math:`\texttt{max}`).
+At least one node in a given model must possess at least one objective but all nodes may have multiple objectives. In case multiple objectives are given in the same ``#NODE`` block, all objectives are aggregated into a single one by summing them (respecting the sign associated with the keywords :math:`\texttt{min}` and :math:`\texttt{max}`).
 Since the abstract GBOML problem is a minimization problem, the signs of objectives that should be maximized are inverted before summation.
 
-Objectives can also be expanded in two ways, namely via user-defined and automatic expansions. First, user-defined expansions make use of an :math:`\texttt{<identifier>}` that will be expanded over each value in the :math:`\texttt{<expansion range>}`. Second, automatic expansions can be constructed by using the :math:`\texttt{t}` identifier directly in the objective. Since all local objectives defined in the same :math:`\texttt{\#NODE}` block are eventually aggregated, the following objectives are in fact equivalent:
+Objectives can also be expanded in two ways, namely via user-defined and automatic expansions. First, user-defined expansions make use of an :math:`\texttt{<identifier>}` that will be expanded over each value in the :math:`\texttt{<expansion range>}`. Second, automatic expansions can be constructed by using the :math:`\texttt{t}` identifier directly in the objective. Since all local objectives defined in the same ``#NODE`` block are eventually aggregated, the following objectives are in fact equivalent:
 
 .. math::
 
@@ -200,7 +200,7 @@ Similarly to constraints, identifiers can be assigned to objectives when definin
    min <identifier>: <expression> <expansion range>;
    max <identifier>: <expression> <expansion range>;
 
-The previous example can be completed by defining an objective function, which yields a complete and valid :math:`\texttt{\#NODE}` block:
+The previous example can be completed by defining an objective function, which yields a complete and valid ``#NODE`` block:
 
 .. code-block:: c
 

docs/source/time_horizon.rst

 Time Horizon
 ============
 
-The time horizon :math:`\texttt{T}` defines the length of the optimization horizon (i.e., the number of time periods considered). This definition is contained in the :math:`\texttt{\#TIMEHORIZON}` block, which is the first one that should appear in a GBOML file. This block has the following structure:
+The time horizon :math:`\texttt{T}` defines the length of the optimization horizon (i.e., the number of time periods considered). This definition is contained in the ``#TIMEHORIZON`` block, which is the first one that should appear in a GBOML file. This block has the following structure:
 
 .. code-block:: c
 
    #TIMEHORIZON
    T = <expression>;
 
-Therein, :math:`\texttt{<expression>}` is an algebraic expression that should evaluate to a positive integer. If :math:`\texttt{<expression>}` evaluates to a positive but non-integral value, it will be rounded to the closest integer automatically and a warning will be raised. Expressions that cannot be evaluated and expressions that evaluate to a negative value are not permitted. In addition, since the :math:`\texttt{\#TIMEHORIZON}` block is the first block of any input file and no parameters can been defined before it, :math:`\texttt{<expression>}` may not depend on any parameters. An example of a valid :math:`\texttt{\#TIMEHORIZON}` block is given below:
+Therein, :math:`\texttt{<expression>}` is an algebraic expression that should evaluate to a positive integer. If :math:`\texttt{<expression>}` evaluates to a positive but non-integral value, it will be rounded to the closest integer automatically and a warning will be raised. Expressions that cannot be evaluated and expressions that evaluate to a negative value are not permitted. In addition, since the ``#TIMEHORIZON`` block is the first block of any input file and no parameters can been defined before it, :math:`\texttt{<expression>}` may not depend on any parameters. An example of a valid ``#TIMEHORIZON`` block is given below:
 
 .. code-block:: c