Gambit: Software Tools for Game Theory | ||
---|---|---|
<<< Previous | The Gambit Command Language | Next >>> |
The built-in data types for the GCL are given in Table 1. The Table is divided into four sections. The data types in the first section are standard data types that are supported in many languages. The data types in the next two sections are more specialized data types that are used to represent elements of normal and extensive form games, respectively. The last section contains only one type, lists, which play an important role in the GCL.
The data types INTEGER and EFBASIS are subtypes of another, parent type. They are indicated in the table as the indented entries following their parent type. A subtype is a data type which has all of the properties of its parent type, plus some additional characteristics. For example, an integer is a rational number, with the additional restriction that its denominator is one.
Table 1. Data types in GCL
Type name | Description |
---|---|
BOOLEAN | a boolean value |
NUMBER | a floating-point or rational number |
INTEGER | an integer |
TEXT | a string of arbitrary length |
INPUT | input stream |
OUTPUT | output stream |
NFG | normal form game |
NFPLAYER | a player in a normal form game |
STRATEGY | a strategy in a normal form game |
NFOUTCOME | an outcome in a normal form game |
NFSUPPORT | a support of strategies in a normal form game |
MIXED | a mixed strategy profile for a normal form game |
EFG | an extensive form game |
EFPLAYER | a player in an extensive form game |
NODE | a node in an extensive form game |
INFOSET | an information set in an extensive form game |
ACTION | an action at an information set |
EFOUTCOME | an outcome in an extensive form game |
EFSUPPORT | a support of actions in an extensive form game |
EFBASIS | an EFSUPPORT that is a basis for an assessment |
BEHAV | a behavior strategy profile for an extensive form game |
LIST(T) | a list of objects of type T (T is any data type |
The remainder of this section details the rules concerning the standard types BOOLEAN, NUMBER, TEXT, INPUT and OUTPUT, as well as general rules for typing. The extensive form and normal form types, and their related types, are detailed later in special sections.
The BOOLEAN type is used to represent the boolean values. The BOOLEAN type is implemented in tri-state logic, and has the three values "true", "false" and "unknown". The command language predefines three constants to represent these: True, False, and Unknown.
The GCL supports one basic numeric data type, NUMBER, with a subtype of INTEGER.
Number: The NUMBER type may contain numbers whose internal representation is either floating point or rational. The internal representation of the number is referred to as the precision of the number. Whether the precision of the number is floating point or rational depends on how the number is initially input. It can be input either as a floating point constant, or a rational constant.
Floating point numbers are implemented as the machine's double-precision floating point type. Computation with these numbers is subject to rounding of least significant digits, and hence these numbers can be imprecise; for example, operations usually associated with being inverses of each other may not be with floating point numbers. However, since arithmetic operations on floating point numbers are implemented in hardware, use floating-point precision when speed is important.
Rational numbers are implemented as the ratios of two arbitrary-length integers. Rational numbers are capable of precisely representing any rational number, and arithmetic operations on rationals are exact. However, arithmetic operations on rational numbers are implemented in software. Hence, computations with rational numbers can be slow, and output from them may be unreadably large.
Floating point constants are represented in the GCL by any string of digits (where a digit is an element of {0,1,2,3,4,5,6,7,8,9}) containing exactly one decimal point (.). Rational constants are represented in the GCL by andy string of digits containing at most one division sign (/). Any NUMBER in the GCL is assumed to be in base ten representation.
Integer: The INTEGER type is a subtype of NUMBER consisting of numbers of rational precision, whose denominator is one.
Since the GCL uses implicit data typing, the data type of a numeric constant must be identifiable by the way it is written. Hence, when you write a numeric constant, keep the following in mind. Floating point constants must include exactly one \verb+.+ in them. Rational constants must have at most one \verb+/+ in them, and integer constants must have neither of the above. Thus, to represent the number 2 as a floating point NUMBER, you would write 2., and to represent it as a rational NUMBER, you would use 2 or 2/1, and to represent it as an integer NUMBER, you would use 2.
The TEXT type is used to store text strings, typically labels for parts of games. It is generally encouraged to label various elements of games in the command language for ease of identification; however it is not required. To specify a TEXT constant, surround the text with double-quote characters ("). Constants may span more than one input line. Also, line feeds can be explicitly included in text constants using the C-style notation of \verb+\n+.
The INPUT type is a reference to an input stream, generally a file on disk. Its principal use is to read in external data. The constant, \texttt{StdIn}, is used to refer to the standard input stream (generally the console). New INPUT streams are created with the function \texttt{Input}, documented in the Function Reference section.
The OUTPUT type is a reference to an output stream, generally a file on disk. Its principal use is as a logging file for writing formatted output from an extended command language job. The constants \texttt{StdOut} and \texttt{NullOut} refer to the standard output stream (generally the console) and the null output stream (the garbage can), respectively. New OUTPUT streams are created with the function \verb+Output+, documented in the Function Reference section.
The data type NFG is used to represent a normal form game. No other normal form data type can exist independently of the normal form game to which it belongs. The NFPLAYER and STRATEGY data types are used to represent players and strategies in a normal form game. A NFOUTCOME is an outcome for a normal form game, and an NFSUPPORT represents a support for a normal form game, which is a collection of sets of admissible strategies, one for each player. Finally a MIXED is a mixed strategy profile over an arbitrary support.
There are no constants of any normal form data type. Objects that are of any of the normal form data types must be built up using functions in the GCL. Hence, a more detailed discussion of them is deferred until later.
The data type EFG is used to represent an extensive form game. As with normal form games, no other extensive form data type can exist independently of the extensive form game to which it belongs. The EFPLAYER represents a player in an extensive form game. The types NODE, ACTION, INFOSET, EFOUTCOME represent the corresponding parts of the extensive form representation of the game. A BEHAV is a behavior strategy profile for an extensive form game. An EFSUPPORT represents a support for a behavior strategy in an extensive form game, which is a collection of sets of admissible actions (at least one for each information set of each player). An EFBASIS is a subtype of EFSUPPORT, representing a support for an assessment in an extensive form game. This is a collection of sets of admissible actions together with a collection of sets of admissible members of information sets (at least one member for each information set).
As with normal form games, there are no constants of any extensive form data type. Objects that are of any of extensive form data types must be built up using functions in the GCL. Hence, a more detailed discussion of them is deferred until later.
The LIST(T) data type can be used to represent lists of any data type T (including \verb+T=LIST(R)+, where \verb+R+ is any data type). Lists are represented in GCL statements by including objects of a given data type in curly braces and separated by commas. For example, the following is how to represent a list containing the first five integers: { 1, 2, 3, 4, 5 }. The data type T of a list is determined by the data type of its first element. All other elements of the list must be of the same type as the first element. The only exception to this rule is that subsequent elements can be listed to a different depth than the first element. For example if \verb+T+ is a basic data type, then then the second and subsequent elements of a LIST(T) can be of type LIST(T) or LIST(LIST(T)), etc. Similarly, the second and subsequent elements of a LIST(LIST(T)) can be of type T.
We refer to the elements at the bottom levels of a nested list as the basic elements of the list. Then lists can be of heterogeneous depth. However, lists must be of homogeneous type. In other words, all basic elements of the list must be of the same type. Hence, { 1, { 2, 3 }, 4 } is a legal list of type LIST(NUMBER), since all the basic elements are of type NUMBER, and { { 2.0, 3/2 }, 1, 4 } is a legal list of type LIST(LIST(NUMBER)). On the other hand, { 1, { 2, "3" }, 4 } is not a legal list, since the second element of the nested list is not a NUMBER.
Lists are distinct in type from each other and from their scalar equivalents. That is to say, LIST(BOOLEAN) is a distinct data type from LIST(NUMBER), and is also a distinct data type from BOOLEAN.
In some of the function prototypes in the Function Reference section, you will notice certain data types which are not listed as supported data types in the section on GCL data types. These are referred to as conglomerate data types. Conglomerate types are not actually data types, but are names used in GCL function prototypes to represent subsets of data types. Following is a list of the conglomerate data types along with the types they include:
<<< Previous | Home | Next >>> |
Basic concepts | Up | Expressions |