Outline
The Cream project is an economic simulation of firms under different emissions schemes using zero intelligence strategies. The two schemes are Cap and Trade and Baseline and Credit.
The Experiment
The motivation for this experiment came from two economic papers; Allocative Efficiency of Markets with Zero-Intelligence Traders: Market as a Partial Substitute for Individual Rationality, by Dhananjay K. Gode and Shyam Sunder and Baseline-and-Credit- Emissions Permit Trading: Experimental Evidence Under Variable Output Capacity, by Neil J. Buckley, Stuart Mestelman and R. Andrew Muller. Gode and Sunder's paper deals with market efficiency and idea of zero-intelligence traders. A trader of this type will not incorporate any information about the market environment in their decision to buy or sell a good, but rather make a random decision on what price they should bid or ask for a particular good. They showed that if zero-intelligence traders were constrained to make any decision such that it did not put them at a loss, it was possible to have efficient markets. Buckley, Mestelman and Muller's paper looks at the implications of the cap and trade and baseline and credit emissions schemes under variable output capacity. Theoretically, if the both schemes are implemented properly, then the outcome should be the same. However, there are considerations that the long-run equilbria of the two may be different if baselines are proportional to output. To test this they used human agents under a number of different sessions. This experiment will attempt to combine the zero-intelligence traders in Gode and Sunder's paper with the experiment described in Buckley, Mestelman and Muller's paper.
The Zero Intelligence Agents and Market Efficiency
To ensure the zero-intelligence players, or ZIPlayers , behave properly and to test the results of Gode and Sunder's paper, an experiment was set up under the same parameters described in their paper. Two sessions were set up under the same supply and demand conditions. 
In one session, the agents were unconstrained and allowed to make any decision desired. This caused the price for Blat Machines ( a mythical good ) to vary greatly and have an unlimited range. An explicit price cap was imposed to make the graph readable. 
However, when the players were constrained, the market's efficiency rose dramatically and the price at which Blat Machines were traded stay between 100 and 40 (and did not require a price cap). It should be noted to look at the scale of the price axis of both sessions.
The Emissions Schemes
In general the cap and trade scheme assumes a regulatory body sets an aggregate cap on emissions and then divides up tradable permits, or "allowances", to the firms producing these emissions. Firms usually trade these permits and thus establishes a market price for them. The baseline and credit scheme has no explicitly aggregate emissions cap, but rather gives each firm the right to emit a certain baseline level of emissions. This baseline is usually derived from historical data or a specific performance standard that specifies the permitted ratio of output. One method for calculating the baseline is to multiply a firm's scale by a performance standard.
Baseline and credit scheme has no explicitly aggregate emissions cap, but rather gives each firm the right to emit a certain baseline level of emissions. This baseline is usually derived from historical data or a specific performance standard that specifies the permitted ratio of output. One method for calculating the baseline is to multiply a firm's scale by a performance standard. Cap and Trade
Cap and Trade
To view the state chart of the cap and trade algorithm click on the image to the left. The cap and trade session starts by setting up the markets for output and emissions permits as well as the players who will participant in them. The agents used for this session are of type ZIFirm. There are 8 firms overall and 2 of each type (A,B,C and D). ZIFirms are the only producers in the output market and are the only buyers and sellers of emissions permits. To simulate demand in the output market a number of Echo Players were created and all together they form a demand curve. At the start of each step, the ZIFirms are each endowed with 20 units of Emissions Permits. Using these permits they each produce output at their target capacity and attempt to sell these units of output at the first DoubleAuction held for output. Firms with permits remaining and have no output left to sell are then registered as sellers of emissions permits, otherwise they are considered buyers in the emissions permit market. From here a double auction is held and the permits are traded. Another double auction is then held to allow firms to try and sell the rest of their output with their newly gotten permits. Before the end of the session, each firm will adjust their capacity by randomly deciding to increase, decrease their capacity by 1 unit or leave it untouched. Subsequent steps follow the same procedure until the game terminates.
Baseline and Credit
The baseline and credit session runs very much like the cap and trade session described above, except for a few key differences. Firstly, there are no endowments of permits at the beginning of each round, with the exception of a single endowment to firms of type A and B (12 going to A and 4 going to B) at the start of the session. This initial endowment follows from the experiment done in Baseline-and-Credit- Emissions Permit Trading: Experimental Evidence Under Variable Output Capacity. From here, the session follows from above: auctions are held of output before and after a permit auction. The key difference is how the permits are distributed. In an actual baseline and credit scheme, if a firm is below the baseline then credits are generated equal to the amount below the baseline. In this experiment, due to architecture of the software, producing output explicitly required permits because there was no system of penalties or fines. This meant that firms needed permits to produce anything, let alone produce at a baseline. Thus, at the end of each step, firms were given enough permits to produce at the baseline, which was calculated by multiplying the firm's capacity by a performance standard. This meant that there was no way firms could produce over the baseline and if they produced under the baseline, these permits could be banked for the next round. Although this is not an exact replication of a baseline scheme, it should not alter the results.
The Code
Cream is written completely in java. Most of the classes within this project represent an economic entity of some sort (i.e. market, double auction, firm etc) and through object oriented programming (OOP) these classes interact with one another quite eloquently. In the following documentation when a word is capitalized, such as Bid or Market, I am referring to the Bid and Market classes or objects. Conversely, when a word is not capitalized, such as bid or market, I am referring to the economic understanding of the word. Keep in mind that each of the packages and classes described below are very interdependent in the way they operate and the bigger picture may not be clear the first time around.
For more information on specific classes and their methods it is highly recommended to investigate the Cream JavaDoc API, which can be found here:->Cream JavaDoc API
If you want more information regarding a package or class described below, click on the yellow heading for its' corresponding JavaDoc page. Click on the image below to view a basic UML diagram, which outlines the classes and the dependencies:
The Packages
Action Package
The action package contains the classes that define the objects agents will create and interact with one another within games and markets. These actions are Bids, Asks, and Transactions.
Asks and Bids
Bid and Ask objects generally have the same structure. They both require the participant who's making the bid or ask, the good in question, the quantity desired, and the price (expressed in terms of a currency and the amount of that currency). Bid and Ask objects are designed to stand on their own independent of the participant so that they can be referenced later. This idea was taken from actual double auctions where buyers and sellers must fill out a certificate and submit it to the auctioneer.
Transactions
Much like the Ask and Bid objects, Transaction objects serve as a certificate to signify a transaction between two participants. The information required to instantiate a Transaction object is the buyer and seller in question, the commodity, the desired quantity and the agreed price (once again expressed as a currency and the amount of this currency). One particular method called upon instantiation is the finalizeDeal() method. This method makes the actual exchange of the good and the currency between the buyer and seller. Transaction objects are not concerned with the agreed price or whether the buyer has enough of the currency or the seller has enough of the good. These restrictions and checks are left up to the rules governing Game and Market objection, as well as the process in which Player objects make decisions.
Commodity Package
The commodity package contains the classes that define the basic objects being traded. These objects have no specific function as they are merely just artifacts. The classes included in this package are the abstract class Commodity, the Good class and the Currency class.
Game Package
The game package contains classes that define the economic games which market participants interact in. Game objects act as engines for Market objects and register transactions made between participants in the Game in the given Market object.
DiscreteGame
This abstract class defines how games with a finite time limit and distinct periods should behave. The methods in class are mainly specified with the time horizon of the game (i.e. incrementing the period and returning the current period). The two most important methods in this class are the step() and run() methods. The former is an abstract method intended for developers to specify what happens in a given period. The latter is an abstract method for developers to specify how the periods are cycled through for a given time period.
DoubleAuction
Double Auction objects allow buyers and sellers to trade Goods for a particular currency. Using "New York" rules, each additional bid must have a price greater than or equal to the last bid made and conversely additional asks must be less than or equal to the last ask made. For a DoubleAuction object to be instantiated it must be passed a Market object so that information about the market good and participants can be extracted.
Click on the image to the right to view a state chart which outlines what occurs in a single step. Firstly, a random participant (Buyer or Seller) is chosen from the list of participants with equal probability. This participant is given a finite amount of tries to make a valid decision (Bid or Ask). If the decision is valid, it is registered, otherwise it's not. Reasons for a Participant not making a valid decision could be because the participant does not have enough of the Good being traded or enough Currency to pay for it or simply the participant has made an invalid decision for each try given. Regardless, just before the end of a step the market is cleared. This process involves checking if the Bid with the highest price is greater than or equal to the Ask with the smallest price. If this occurs, a Transaction is created between the Buyer who made the Bid and the Seller who made the Ask for the price and quantity of the traded Good . The agreed price is decided by randomly taking either the Buyer's or the Seller's price with equal probability. Finally the transaction is relayed to the market and all outstanding Asks and Bids are cleared. If the prices do not cross, nothing happens and the turn ends. Steps are repeated for the allotted amount and then the game terminates.
Market Package
The market package contains classes that define Market objects and the Participant objects that will be interacting within these Markets.
Market
Market objects are in a way a device for recording the interactions between market participants for the trading of a single good. When a transaction is made in a Game it is relayed to the corresponding Market for that Good and is recorded. At any point, the supply and demand for the market good could be calculated and graphed as well as a history of all the transactions that occurred. In simple terms, Market objects keep the books for what happens within Game objects.
Participant
There are two types of market participants; Buyers and Sellers. Both require a Player object to be instantiated and both have a single method declared in them and this method is the makeBid method for Buyers and the makeAsk method for Sellers. It is easier to think of Buyer and Seller objects as badges that tell the "world", and the Players themselves, whether they are buying or selling a particular good. For instance, suppose a Player is registered as a Buyer in a Market and this Market is passed to a DoubleAuction. When the player is called upon to make a decision in the DoubleAuction, since they are registered as a Buyer in that market, the Player will "know" to make a Bid rather than an Ask.
Player Package
The Player package contains all the classes that define Player objects. Right now, this package deals exclusively with computer agents, rather than human Players, but human functionality can easily be integrated into the system. The types of computer agents that are included are ZIPlayers, ZIFirms and EchoPlayers.
Player
All Player classes declared in the Player package inherit a number of methods and fields from the abstract player class. These fields and methods are abstractions to all the necessary functions economic agents would need in the experiment. Each player object has an inventory to store the Goods and Commodities they own and a value function, which maps the Player's values for single units of a particular Commodity, that may or may not be in their inventory. The inventory and value function are in the form of a HashMap. More importantly, Player objects have two methods for interacting in Games: the makeBid() method and the makeAsk method. Although they are not explicitly defined in this class, they both require that a Market object be passed to them when they are called so that the player has access to the Market's information when making a decision.
ZIPlayer
ZIPlayer stands for Zero-Intelligence Player and is based on the Zero Intelligence players described in Allocative Efficiency of Markets with Zero-Intelligence Traders: Market as a Partial Substitute for Individual Rationality , by Dhananjay K. Gode and Shyam Sunder. Basically this Player has two states when making a decision; unconstrained and constrained. If a Player is in the former state, when asked to make either a Bid or Ask they will randomly choose a price between 0 and their budget constraint, even if this would put them at a loss. Hence, the Player makes a decision with Zero-Intelligence needed. The latter, constrains the Player to make a random decision that would not put them at a loss. For instance, a Seller of a particular Good would choose a price between the cost of the Good and the Market's price cap. A Player's state could change from unconstrained to constrained without having to create a new Player.
ZIFirm
The ZIFirm class inherits most of its' methods from the ZIPlayer class and thus, will make decisions in a similar fashion. The difference between the two is that a ZIFirm has the option of "producing" a particular Good, pending there are enough emissions permits to allow it. There are four types of ZIFirms, A,B,C and D, which all have difference costs per unit of output and different emissions rates, which reflect these costs. For example, a ZIFirm that has a cheaper cost per unit of output probably has a high emissions rate and would require more permits to produce this output. These parameters are based on those of Baseline-and-Credit- Emissions Permit Trading: Experimental Evidence Under Variable Output Capacity, by Neil J. Buckley, Stuart Mestelman and R. Andrew Muller. The parameters are as follows:
| Firm Type | Unit Fixed Cost | Fixed Emission Rate |
| A | 128 | 2 |
| B | 96 | 4 |
| C | 64 | 6 |
| D | 32 | 8 |
In the two sessions with ZIFirms, there comes a time when they would be trading amongst themselves for emissions permits and therefore, must derive a price for these permits if they were to make a constrained decision. To accommodate this ZIFirms were given memory to remember the last trade on output that they made so that they could derive the value of a permit per unit of output. Although this addition moves away from the ZIPlayer's described in Gode and Sunder's paper it did not take away from the experiment itself.
Echo Player
Echo Players are very simple in nature. Upon instantiation you must specify a universal value for them. From then on, when asked for the value of a commodity they will always return this universal value. Hence they are called echo players because when given an initial value, they will always echo it back. The main purpose for these agents is to simulate a supply or demand curve.