It is not uncommon in financial decision making for the user to deal with hundreds or even thousands of financial assets, in a variety of currencies and markets, extending over long time horizons that may run several decades into the future. Furthermore, uncertainty is prevalent and may need hundreds or thousands of scenarios to be dealt with. The user most likely will require that very large sets of data be manipulated and input to a mathematical model in order to instantiate (i.e., create a single instance of) the model that reflects the specifics of his or her problem. Hence, data handling is a critical step in all modeling applications and financial decision making is no exception.

One very important principle concerning the use of data when building models is that:

In this way we avoid two potential pitfalls. First, entering data in its most basic form allows us to change them easily and safely, and all derived data are updated automatically. For instance, it is better to input spot rates and then use GAMS to calculate forward rates, than to input both spot and forward rates. It is better, too, to input a time series of prices and then calculate returns, than to input both prices and returns. If a price changes the GAMS code will recalculate returns, thus avoiding potential errors of data inconsistency. Second, we can isolate the input data from the algebraic representation of the model, which makes the model easier to read by other users and to be adapted to new data sets. It is good practice to keep all data separately at the beginning of a model, usually as an external input file, rather than to intersperse data with the model, and input them just before they are needed.

GAMS statements offer several formats for data as one-dimensional lists, two-dimensional tables and even multi-dimensional data structures. GAMS also offers several features to input external files so that data are kept separate from the model. Furthermore, data can be read in different formats, thus making GAMS compatible with the files generated by database management systems, spreadsheets, or other software for generating financial data. Similarly, GAMS offers features for data output and report preparation. All these features are explained next.

An example of the declaration and initialization of a three-dimensional parameter follows:

To declare parameters with three or more indices in a tabular format, use the “dot”-notation:

Large tables can be split using a plus sign:

In addition to specifying data directly in the source file, GAMS also interacts with databases and spreadsheets; see the GAMS User’s Guide for further information.

When GAMS solves an optimization model, the solver finds appropriate values for the variables that satisfy the model’s constraints. In economic literature such variables are sometimes called endogenous variables, in contrast to exogenous variables, or parameters. GAMS parameters may be assigned and modified as part of the model setup, and therefore act somewhat like ordinary programming language variables, but once the model is being solved they are fixed for the duration of the SOLVE statement. In summary, GAMS VARIABLES are endogenous variables; SCALARs, PARAMETERs, and TABLEs are exogenous variables.

Assuming that all data are gathered together in file ModelData.inc, then the code segment

We use the .inc extension when the file contains GAMS data structures, i.e., it includes scalars, parameters, and tables that have been properly defined in GAMS. However, it is also possible to communicate with files created with Excel or with plain text files.

GAMS communicates with Excel via GDX (GAMS Data Exchange) files. A GDX file is a file that stores the values of one or more GAMS symbols such as sets, parameters, variables, and equations. GDX files can be used to prepare data for a GAMS model, present results of a GAMS model, store results of the same model using different parameters, etc. A GDX file does not store a model formulation or executable statements. GDX files are portable between different platforms. In order to write data from GAMS to Excel, the user writes a GDX file and then reads the Excel file from the GDX file: GAMS → GDX → Excel. This is practically seamless for the user and requires few commands as discussed in the GAMS Users’s Guide. The process for importing data from an Excel file to GAMS is similar: Excel → GDX → GAMS.

Plain text files can be imported with the CSV format; CSV stands for comma-separated values, sometimes also called comma delimited. A CSV file is a specially formatted plain text file that stores spreadsheet or basic database-style information in a very simple format, with one record on each line, and each field within that record separated by a comma. It is of course important that the individual “records” within a CSV file do not contain commas, as this may break the simple formatting when using the file in another application.

CSV files are often used as a simple way to transfer a large volume of spreadsheet or database information between programs, without worrying about special file types. For example, scenario generators could be written in C, C++, Matlab, or other simulator software. It is convenient to print the results in an ASCII file and separate the records by commas. Then, using the GAMS dollar statements ONDELIM and OFFDELIM, the data can be read in the GAMS model file.

The OPTION statement provides some control over the output format. OPTION DECIMALS = 8 causes data to be displayed with 8 decimals, and OPTION X:8 does the same for data related to the symbol x.

Multidimensional data are displayed in a tabular format. The option Matrix:d:r:c causes GAMS to display using d decimals, listing the last c indices across the top, the next r indices in the left-most column, and any remaining indices in separate tables. For instance, a simple DISPLAY VarCov results in: whereas a DISPLAY VarCov:1:1:1 results in: using a separate table for each value of the first index.

The large majority of the optimization models we implement are scenario-based, and methods for scenario generation are discussed in Chapter PFO-9. Specific examples are given in the various application sections both in PFO and later in this book.

The portfolio dedication model we use is a version of the PFO model. The differences in the model implemented here compared to the model given in PFO is that the bond price P_i is included explicitly at time 0 instead of being part of the cashflow parameter F_0i, and borrowing is not allowed= 0). The formal model is given as follows:

Recall that the problem is to purchase a bond portfolio whose proceeds (coupon and principal payments) are sufficient to cover liabilities in each of a series of future time periods. Surplus cash in each period can be reinvested to the next, v_t⁺. The optimal portfolio is the one that requires the smallest initial outlay v₀ to purchase; this outlay is equal to the portfolio price (given by Σ_i∈U P_i x_i) plus the initial reinvestment.

The actual values of the parameter tau are calculated in the assignment statement tau(t) = ORD (t) - 1; the ORD function maps the index t to its ordinal value in the set Time, so that ORD(“2001”) = 1, etc. Even when set elements appear as numbers, GAMS does not by itself associate numerical values to them (except through the ORD function). Hence, the tau parameter is needed to associate the year 2001 with the numerical value 0 (time, relative to the beginning of the model’s time periods), 2002 with 1, etc.

Next, we define the bond universe U as the set Bonds and the associated index, i. The bond data are given in the TABLE BondData that follows:

The table’s first index denotes the bonds. The asterisk as the second index indicates that this index position is not associated with any underlying set (such as Time), but can contain any identifier. In this case we need to specify each bond’s Price, Maturity year, and Coupon rate. Although we only need to know each bond’s cashflow for each year to specify the model, it is a good principle to specify only the most fundamental data in a model, and then explicitly calculate any derived data needed. Hence the calculation of the bond cashflows that follow is based on the fundamental BondData: This assignment is executed for each combination of the indices i and t. The right-hand side specifies that there is a cashflow of unity in the year where the bond matures, and a coupon payment in every year before the bond maturity, except the first. The statement illustrates the use of the conditional, or $-operator: The condition on its right is evaluated; if the result is true (non-zero), then the value of the operator is the expression on its left, otherwise it is 0. For readability we have extracted the bond data from the table into individual vectors Maturity, Coupon, etc.

We then declare the model’s constraints in the EQUATION CashFlowCon(t) declaration, and define it (one for each value of t) as follows: This constraint states that the incoming cashflow for each year should match the liabilities. The definition of an equation is indicated by the “..” sequence, and = E = specifies that this is an equality constraint (as opposed to = G = or = L = for ≥ and ≤). Note the use of the $-operator to implement conditions: the bonds’ prices and v0 only occur in the constraint corresponding to time 0; the term (1+rf(t-1)) * surplus(t-1) only occurs in subsequent time periods. In this way, the constraint here actually implements both of the cashflow constraints of the formal model, i.e., for all values of t. Note also the use of the SUM(i, . . . ) operator to implement the summation Σ_i F_ti x_i,

Then we define the complete optimization model Dedication, consisting of the constraints CashFlowCon (and implicitly the variables referenced in those constraints), and ask to have the model solved, minimizing v0 and using an LP (Linear Programming) solver. Finally, we ask that the results be displayed: The final values (“levels”) of the variables v0 and x_i , and the shadow prices (“marginals”) of x_i as well as the dual variables corresponding to the cashflow constraints.

Note that, although a formal mathematical model often uses one-letter names, one can use more descriptive names in the GAMS model.

The next major sections are the equation and variable listings.

The variable listing has the format: which shows that x(DS-8-06) has bounds 0 and infinity, level value 0, and that it occurs in six constraints: in CashFlowCon(2001) with coefficient -1.1235, in CashFlowCon(2002) with coefficient 0.08, etc. The number of variables in each block for which this information is shown can be specified by OPTION LIMCOL = n, and is three by default.

The model statistics show the final size of the model:

After solving the model, GAMS displays various status messages: The important things to note are that the solver terminated normally, and that the model status is “optimal.” Messages about solver problems, about infeasible or unbounded models, would also show up here. The final part of the standard output lists the model’s equations and variables (only a small part of it is shown):

There are various options to modify the standard output; see Table 1.6.