java configur kit

7/30/2019 java configur kit

1/12

JACK: A Java Auction Configuration Kit

Thomas Goff1, Amy Greenwald1, Elizabeth Hilliard1, Wolfgang Ketter2, Eric Sodomka1

1 Department of Computer Science, Brown University2 Rotterdam School of Management, Erasmus University

Abstract. A key step in the evaluation of an agent (either autonomous or human) is determining theagents success as compared to other agents designed to participate in the same environment. Suchcomparisons are the basis for the Trading Agent Competition (TAC), in which autonomous tradingagents compete in simulated market scenarios. TAC servers and agents alike are highly specialized andtypically require teams of developers, as TAC simulations tend to be rather complex. In this work wepresent a client-server infrastructure that is capable of simulating not just one complex market and itscorresponding set of agents, but a wider space of markets and potentially more robust agents. Supportedmarket mechanisms include both user-designed auctions and a configurable set of auctions whose basicbuilding blocks are commonly-studied (e.g., first-price, second-price, simultaneous, sequential auctions).Our so-called Java Auction Configuration Kit (JACK) is intended to facilitate research on the interplaybetween a variety of auction mechanisms and a variety of agent strategies (both autonomous and

human) by simplifying the orchestration of auction simulation.

1 Introduction

In many real-world economic markets, goods and services are sold through simultaneous and sequentialauctions to bidders with complex valuation functions and incomplete information about competing bidders.Such domains include online ad auctions, spectrum auctions, eBay, the Dutch flower auctions, and the NewYork Stock Exchange. While auction theory can sometimes provide equilibrium solutions, this theory doesnot always map directly into practice. First, in most complex auctions, computing equilibria is intractable,making it difficult to predict agent strategies. Second, even if an equilibrium can be computed, bidders maynot conform to that or any other equilibrium strategy. In such auctions, it is often best to support theoreticalanalyses (to the extent they are even possible) by experimental and empirical methods.

Experimental economists often perform user studies in simulated auction games to determine whether bid-ders play equilibrium strategies [10, 7, 3]. Researchers in autonomous agents often develop bidding strategiesfor simulated auction games [17, 6] and then search for equilibria in the space of those strategies [9]. In thispaper, we introduce the Java Auction Configuration Kit (JACK), an auction simulator that allows researchersto customize auctions and collect empirical data from participating bidders, human or autonomous.

We envision the uses of JACK to include:

1. In trading agent design and analysis, JACK can facilitate the simulation of autonomous agents in aspecific auction domain by providing auction simulation infrastructure and not restricting the developerslanguage choice. Furthermore, JACK can facilitate the development of robust agents by enabling thesimulation of the same agents in a variety of different auction domains.

2. In experimental economics, JACK can facilitate user studies (either in the lab or online via MechanicalTurk [13]) by allowing researchers to test human behavior in a variety of different auction domains,including environments with some autonomous and some human agents.

3. In artificial intelligence, JACK can be used to develop mixed-initiative bidding agents, in which humanbidders receive recommended bids from an underlying autonomous bidding agent and are free to acceptor reject those recommendations as they see fit.

4. In mechanism design, JACK can be employed in empirical game-theoretic analysis [9] to ascertain theequilibrium strategies of the auction mechanisms it supports. Then, employing empirical mechanismdesign [16], researchers can evaluate the quality of those mechanisms.


2/12

5. JACK can also be used for educational purposes. For example, we have used it in the classroom to runcompetitions among autonomous agents developed by students to bid in auctions whose equilibria areanalytically intractable.

The rest of this paper proceeds as follows. Section 2 explores related work. Section 3 describes JACKsclient-server architecture, including communication between the server and its clients. Sections 4 and 5discuss the auction types and valuation structures that are built in to JACK. Sections 6 and 7 demonstratethe usefulness of JACK through a classroom case study and an implementation of the Dutch Flower Auctions,a complex, real-world auction domain. Section 8 concludes and discusses directions for future work.

2 Related Work

There exist a multitude of frameworks in the experimental economics literature and trading agent designcommunity for running auctions and other games. Most work in experimental economics has been focusedon whether equilibrium strategies are borne out by humans in practice, so naturally the types of auctionsstudied in that field are typically simpler auctions that are amenable to theoretical analysis [10]. One ofthe most prominently used frameworks in the experimental economics literature is z-Tree [5], a client-serverprogramming environment that is used for a variety of economic experiments including, but not limited to,auctions. z-Tree, because it can express many games, not just auctions, is programming intensive except for

a set of built-in experiments. With our focus being only on auctions, we may be able to express games moresuccinctly, thereby making it easier for the researcher to initiate his experiments.

At the other end of the spectrum, VeconLab Pre-Programmed Experiments [12] and EconPort [2] areless programming intensive but can express fewer games. VeconLab allows for numerous pre-programmedeconomic games to be played, such as simple auctions, bargaining games, and public goods games, butthey are limited because the agents valuations for bundles of goods are often decomposable into values forindividual goods; that is, even simple complements and substitutes are not immediately expressible. Thedegree of expressivity achieved by VeconLab does align well with much of the literature on economic theory,but to model more complex, real-world settings, richer game representation is likely to be required.

Arguably more complex auctions have been studied in the autonomous trading agent community. Wurmanet. al. [18] created the Michigan Internet AuctionBot, a server for hosting various types of online auctions,where bidders can be either agents or humans. The Swedish Institute of Computer Science developed aclient-server architecture that several complex trading agent games have used as a base [4]. Indeed, theannual trading agent competitions (TAC) have been run using these two servers. TAC Classic [4], whereagents act as travel agents assembling travel packages for their individual sets of clients, involves threedifferent auction mechanisms (continuous one-sided, continuous double, and ascending multi-unit auctions)and goods that exhibit complementarity and substitutability. In TAC Supply Chain Management [1], agentsact as manufacturers in a supply chain and must bid in reverse auctions to sell their finished goods tocustomers. TAC Ad Auctions [8] is a game in which agents act as online advertisers on a search engine.Agents bid for items exhibiting imperfect substitutability and uncertain payoffs in a parameterized model ofthe generalized second price auction used in real-world sponsored search.

As seen in these examples from experimental economics and the trading agent research community, thereare auctions spanning a wide range of complexity under investigation. Wurman et. al. [19] decomposed thevast auction design space into several key features such as bidding rules, closing conditions, and informationrevelation and proposed a parameterization of each of these features. JACK represents only a subset of

Wurmans auction design space by defining a simpler (albeit more restrictive) set of auction parameters butadditionally parameterizes part of the valuation space.

3 Client-Server Framework

We now describe the architecture of our auction framework. JACK is set in the client-server model and consistsof four packages: server, client, auction, and valuation. The server package contains functionality for

2


3/12

Server

Super Auction

Auction

Client Bidder

Client Bidder

Auction

Com Threads

Com Threads

Client Side(Java, Python, C++)

Server Side(Java)

Valuation Generator

Fig. 1. Client-server architecture of JACK.

creating socket connections and sending and receiving messages from clients. It can be configured in a filethat gives users control over such parameters as the number of clients and various network specifications.The client package includes several examples of bidders that can connect to and communicate with

the server. Each client contains functionality for handling messages received from the server and sendingmessages containing bids and other pertinent information to the server.

The auction package, using a set of configuration files, specifies auction rules (i.e., payment and allo-cation), creates the auction schedule, and provides a method for writing log files. The valuation packagespecifies parameters that determine priors over bidder valuations and draws valuations from those priors. Aschematic diagram of JACK, decomposed into these packages, is shown in Figure 1.

The server handles all multi-threading necessary for simultaneous communication with multiple clients.Messages sent from the server are strings, where the start of message is a substring stating what type ofmessage is being passed (e.g. Place bid).

Clients may be implemented in any language that supports socket communication. Currently, client

interfaces are provided in Java, Python, and C++. These interfaces can be easily extended with moreintelligent bidding. Also included is an interface by which a human can enter bids manually by respondingto server messages.

A screenshot of the client-server communication for a simlutaneous, sealed-bid auction is shown in Fig-ure 2. Before the auction begins, the server reads auction and valuation information from various configu-ration files and sends this information to the clients. Throughout the auction, the server sends bid requestsand other pertinent information (e.g., winning price, winning bid, winning bidder) to the clients. The clientshown is bidding using the human interface, which prompts the user to enter bids for each auction.

The auction and valuation packages are discussed in detail in the following two sections, respectively.

4 Auctions Overview

When designing a multi-purpose auction simulator, one must consider the trade-off between expressivenessthe ability to model a large set of auctionsand the compactness and simplicity that can be achieved bymodeling any one particular auction. When considering this trade-off, one should consider the goals ofpotential users and what types of auctions they might be interested in simulating. We assume our primaryusers will be autonomous agents researchers, experimental economists, and educators.

While these users may all have a need for an auction framework, the complexity of their desired applicationdomains are quite different. Experimental economists interested in testing human behavior in auctions likely

3


4/12

Fig. 2. server (left) and clients (right) output for simultaneous, first and second-price sealed-bid auctions.

require simpler games and have a higher cost for lower-level programming. Those studying autonomousagents require, and are perhaps more willing to explicitly program, more complex domains. We attemptto meet the needs of both groups by including in JACK some commonly-studied auctions that are easilyconfigurable and by providing a basic auction infrastructure on top of which it is relatively easy to build any

auction game.JACK allows users to configure parameters across five dimensions of the auction space. The following list

outlines these dimensions and the options that JACK provides. Those that are configurable are in bold.

1. Bidding rules (sealed bid, ascending, descending)2. Pricing rules (1st price, 2nd price)3. Multiple auction scheduling (sequential and/or simultaneous)4. Information revelation policies (number of participants, past bids, individual bidder actions, upcoming

auction schedule)5. Bidding constraints (reserve prices)

Although JACK does not currently allow the auction designer to set any parameters to control whatinformation is revealed to agents, some basic information is sent from the server to the agents before, duringand after the auction. The reserve price for each good as well as the entire auction schedule is announcedbefore the auctions begin, for all auction types. Only the ascending auction setup allows for informationrevelation during an auction. In this case, we chose not to reveal all agents bids; instead JACK reveals onlythe agent ID and the current bid of the current highest bidder after each round. The minimum acceptablebid is also sent to the agents. For all auction types, after an auction closes, the winning agents ID and closingprice, not its bid, are announced to all agents. Note that this means that in second price auctions agents arenot told the winning bid, but instead only the second highest bid. In future releases of JACK, we intend toallow more user control over what information is revealed as well as when that information is revealed.

4


5/12

(a)

(b)

Fig. 3. (a)GUI for specifying the auction configuration. (b) GUI for specifying goods schedule.

Figure 3(a) and 3(b) depict a GUI that is used for auction configuration. After specifying the numberof simultaneous and sequential auctions on the Basic Setup tab, the JACK user can click on the AuctionSchedule tab to see a grid-based layout of these auctions. The JACK user can highlight any of these auctionboxes and click the add button to assign these auctions to one of several default auction types. Figure 3(b)shows the Good Schedule which allows for similar functionality when a JACK user is deciding what goodswill be sold in what auction slots. When the user is done, the GUI writes the users selections to a set ofconfiguration files which provide an auction game definition to the server.

5 Valuation Expression

We now turn to the problem of expressing valuations in general auction games. Let bundle B be a set of goodsthat could be obtained in a given auction game. Given a specific bundle B, a bidders valuation V(B) Ris a measure of that bidders worth for obtaining that bundle. A bidders valuation function is a mappingfrom bundles to valuations.

In principle, a JACK user could specify an agents valuation function directly; that is, the user could providea bidders valuation for winning each possible bundle of goods. While fully expressive, such a representation

5


6/12

{}

{1}

{2}

{3}

{4}{1,2}

{1,3}

{1,4}

{2,3}

{2,4}

{3,4}

{1,2,3}

{1,2,4}

{1,3,4}

{2,3,4}

{1,2,3,4}

Valuation

...

Valuation Prior

Fig. 4. Four-item visualization of the number of values that must be specified for a single agents valuation functionin the most general case, as well the number of entries needed to represent a fully general valuation prior (assumingIPV and a finite valuation space). Each row represents a possible bundle of goods, and each corresponding rectanglerepresents the value received for procuring that bundle of goods. Each column in the valuation prior represents apossible valuation function that an agent could be assigned.

is intractable when many different goods are up for auction, as for N goods, 2N values (one per bundle) mustbe specified. Furthermore, most auction theory relies on agents having some prior over the distribution ofother agents valuations [11]. A JACK user thus needs to express more than individual valuation functionshemust express a prior over these valuation functions.

Figure 4 shows the JACK users problem of specifying general priors over valuation functions. If there are ppossible valuation functions, p2N values must be specified to define valuation function priors (in addition toa probability distribution over these valuations functions). If, for example, each bundle could independently

take on V possible valuations, p = V2N

valuation functions could be realized and V2N

2N values would haveto be specified to define the prior.

Providing full expressiveness over valuation function priors may be feasible for toy problems but canquickly become burdensome. We instead try to express valuation functions in such a way as to make themcompact and easily configurable. If the configurable priors provided are too restrictive, users can implementtheir own specialized valuation function priors on top of JACKs basic infrastructure.

Currently, JACK allows its users to define a prior over valuation functions in terms of five basic structures.These include constant, increasing, and decreasing marginal valuations; scheduling valuations; and contractvaluations. These valuations are by no means exhaustive, but they do represent a range of interesting,commonly studied, and potentially realistic possibilities.

Homogenous Additive The first three of these typesconstant, increasing, and decreasing marginal valuationsshare a base structure, which we refer to as homogenous additive. This structure is governed by two param-eters, and , that are used to express an agents precise valuation function. A valuation V for a givenbundle of goods g is given by:

V(g,,) = 1g11 + 2g

22 + . . . + ng

nn

6


7/12

where for each good type i, gi is the number of goods of type i in the bundle, and i and i are parametersspecifying the shape of the valuation function for good type i. Using this structure, we can express increasingmarginal valuations when > 1, decreasing marginal valuations when 0 < < 1, and constant marginalvaluations when = 1.

Figure 5 depicts several different homogeneous additive valuations, each over bundles of two good types.The axes indicate the number of each good type in the bundle, and the color at each point represents the

valuation associated with achieving that bundle (with lighter colors representing higher valuations). In 5(a),the goods both exhibit decreasing marginal valuations (1 [1, 2], 1 = 0.3, 2 [1, 2], 2 = 0.6). In 5(b)the goods both exhibit increasing marginal valuations (1 [1, 3], 1 = 1.3, 2 [1, 3], 2 = 1.3). Figure 5(c)shows constant marginal valuations (1 = 6, 1 = 1, 2 = 4, 2 = 1). The increasing, decreasing, andconstant marginal valuations are visualized by the increasing, decreasing, and constant rate of change inheatmap color as the number of goods increases.

To specify priors over valuations with homogenous additive structure, the user specifies ranges [mini , maxi ]

and [mini , maxi ] from which values for i and i are uniformly drawn. If there are N different types of goods,

the user only has to specify 4N parameters to fully define this prior over valuation functions.Homogeneous additive valuation functions cannot express a threshold, in which an agent ascribes a

valuation of 0 to a bundle unless a specific quantity of some good type is obtained. Valuation functions arealso restricted to being additive across good types.

Homogenous Contracts In contract valuations, each agents valuation function is expressed as a set of Mcontracts, each of which the agent may or may not fulfill. A contract j consists of a quantity gji of each goodtype i that must be obtained to fulfill the contract, as well as a valuation Vj for fulfilling that contract.

Let Gi be the agents quantity of goods of type i, and let G = (G1, G2, . . . , GN). To calculate anagents valuation V(G) one must solve a multi-dimensional knapsack problem. Let x be a vector of booleansindicating whether or not each contract j is fulfilled by the agent. The following integer linear programexpresses this optimization problem:

V(G) = maxx

jC

Vjxj

s.t.

jC

gji xj Gi (j C)

xj {0, 1}

To allow for a compact representation of priors over contract valuations, the space of possible contracts isparametrized as follows. First, for each agent, the user specifies a number of contracts M to generate. Then,for each good type i = 1, . . . , N , the user specifies a range [gmini , g

maxi ] of contract fulfillment quantities, as

well as a per-good range [vmini , vmaxi ] of values. For every contract j, g

ji and v

ji values are sampled uniformly

from these user-specified intervals, and the contracts fulfillment value Vj is:

Vj =

N

i=1

gji v

ji

As an example, suppose the user configured the contract valuation space for a single agent as follows:

[gmin1 , gmax1 ] = [2, 4], [g

min2 , g

max2 ] = [0, 1], [g

min3 , g

max3 ] = [0, 6].

[vmin1 , vmax1 ] = [2, 6] [v

min2 , v

max2 ] = [5, 9] [v

min3 , v

max3 ] = [3, 8]

A sample of contract fulfillment quantities gj = 3, 1, 4 and per-good values vj = 5, 8, 3 gives rise to atotal value of Vj = 3, 1, 4 5, 8, 3 = 35 if the contract is fulfilled. Like homogenous additive valuations,the user only has to specify N parameters to define a prior over homogenous contract valuations.

Figure 5(d) shows a visualization of contract valuations when there are two different item types. Thevaluation parameters are M = 10 contracts, [gmin1 , g

max1 ] = [0, 10], [g

min2 , g

max2 ] = [0, 10], [v

min1 , v

max1 ] = [2, 7],

7


8/12

and [vmin2 , vmax2 ] = [10, 11]. This visualization shows complementarity between the two goods. In order for

an agent to increase the value it receives it is not enough to obtain more of a single good (i.e., increase alongthe vertical or horizontal axis only). The agent must, instead, obtain more of both goods (i.e., increase alongboth the horizontal and vertical axes).

Contract valuations allow for a large degree of complementarity among goods, but do not allow an auctiondesigner to create perfect substitutes. In certain instances, especially if the number of contracts an agent

receives is low, an agents valuation may exhibit substitute-like relationships between goods, but this wouldbe more by chance than by design. A user can, however, require that agents acquire a minimum number ofgoods before receiving any value, and can therefore force complementarities among goods.

Scheduling Valuations Our previous valuation functions were designed for homogenous goods settings. Reeveset. al. [14] motivate a valuation function with non-homogenous goods, complements, and substitutes bydefining an auction-based scheduling problem. In this problem, there are M time slots to be sold, indexedby 1, . . . , M . These time slots can be thought of as scheduled computing times that can be purchasedon a supercomputer. Each bidder has a single task that it wants to perform. To accomplish its task, thebidder must purchase time slots. The bidder receives some valuation based on how early its task will becompleted. If the bidders th time slot occurs at time t, it receives valuation vt. Bidders do not have topurchase contiguous time slots to complete their task; valuation is based only on the time in which thebidders task is completed. We define the valuation function using the notation of Yoon and Wellman [20].

Let G be a bidders bundle of goods, where Gi {0, 1} specifies whether or not the agent obtained the goodwith time slot i. Define the completion time T to be the earliest time by which time slots were obtained,computed as follows:

T(G, ) = min({t s.t. |{gj G | j t}| } {})

Given a vector of valuations v for completing the task by each time t, an agents valuation function is

V(G, v, ) = vT(G,i).

To express priors over these valuations, the user specifies a [min, max] range from which j is drawnuniformly, for each agent j. Additionally, the user specifies a range from which task completion values v aredrawn. For each agent j, task completion values vj(t) are drawn uniformly from [v

min, vmax] for each timeslot t, and then sorted so that vj(t) vj(t + 1). Thus, the JACK user only needs to specify four parameters

to define priors over the scheduling valuation function.

6 Alpha Test and Educational Use

As a proof of concept, we used an alpha version of JACK (JACK) to run several auction competitionsamongst students taking a course on agent and auction design (CSCI 2951-C Autonomous Agents andComputational Market Design). Teams of students spent the semester creating general auction simulatorsand designing agents to bid in simultaneous and sequential auctions with market scheduling valuations [14].After they designed agents for these settings, they were provided with sample code for dummy biddersin Java, C++, and Python that could interface with JACK. These dummy clients were not competitive;they merely demonstrated how to parse and format messages to communicate with the server. Followingthe example dummy agents, the students edited their own agents to interface with JACK, and competed insimultaneous 2nd-price sealed-bid, sequential 2nd-price sealed-bid, and simultaneous ascending auctions.

Running student competitions on JACK was a dry run of the system and highlighted its strengths andweaknesses. The inconvenience of running all the agents and the server on a single host machine highlightedthe need for remote connections. An important test of the JACK concept was whether or not existing agentscould be easily modified to communicate with JACK. As students had already designed and tested theiragents in independently coded auctions, the competition provided confidence that existing agents can indeedbe edited to interface with JACK. Given the large number of existing agents designed for TAC games andother specific environments, the ability to adapt agents to interface with JACK is an important quality.

8


9/12

10

20

30

40

0 10 20 30 40 50

0

10

20

30

40

50

Bundle Revenues

# Item 1

#

Item2

(a)

0

500

1000

1500

2000

0 10 20 30 40 50

0

10

20

30

40

50

Bundle Revenues

# Item 1

#

Item2

(b)

0

100

200

300

400

500

0 10 20 30 40 50

0

10

20

30

40

50

Bundle Revenues

# Item 1

#

Item2

(c)

0

200

400

600

800

0 10 20 30 40 50

0

10

20

30

40

Bundle Revenues

# Item 1

#Item

2

(d)

Fig. 5. Heatmaps of valuations for finishing the auction with different item bundles, given the following valuationfunctions: (a) additive valuations with decreasing marginal valuations for both items; (b) additive valuations withincreasing marginal valuations for both items; (c) additive valuations with constant marginal valuations for bothitems; and (d) contract valuations.

7 Dutch Flower Auctions Example

We now turn to a more complex domain which cannot be created in JACK through simple configurationbut is nevertheless relatively easily to implement on top of the JACK infrastructure. We focus on the real-world domain of the Dutch Flower Auctions (DFA), which accounts for nearly two-thirds of the global flowertrade. The DFA are an information-rich, time-critical market in which it is not obvious how to bid effectively.Simulation could facilitate the development of effective bidding strategies.

The Dutch flower auction halls, an example of which can be seen in Figure 6 [15], run multiple auctionssimultaneously, sequentially, and asynchronously. Each one is a multi-unit auctionmeaning multiple goodsexchange hands with each auction clearingimplemented using a single-handed clock that initially points toa high price and rapidly decreases. As the price falls, each buyer can bid by pressing a button indicating theportion of the lot being auctioned he is willing to accept at the current price. The first buyer to bid wins.If the winning bidder does not select the entire remaining quantity, the process repeats. That is, the clockrestarts at a new high price and the auction reruns until the entire lot is sold, or until the price falls belowthe sellers reserve price, in which case any unsold goods remaining in that lot are destroyed.

Our DFA implementation consists of multiple auction schedules running simultaneously, sequentially, andasynchronously, with each schedule running descending price auctions for lots of flowers. An agent bids byentering a price and a quantity. When the price reaches an active bid, the agent that placed the bid gets the

9


10/12


11/12

8 Conclusion and Future Work

We introduced the Java Auction Configuration Framework (JACK), an in-the-box, user-friendly simulator ofgeneral auction games. JACK is easily configurable for numerous auction mechanisms and valuation priors,and enables development of more specific auction domains and valuation priors on top of its basic infrastruc-ture. We expect three groups will benefit from using JACK: (1) trading agent researchers studying bidding

strategies in complex domains, (2) experimental economists studying human behavior in auctions, and (3)educators looking for hands-on exercises for teaching auction theory or artificial intelligence. In this paper, wedescribed how JACK was used in our own course on trading agent design and analysis, and how JACK can bespecialized to simulate highly complex auctions such as the Dutch Flower Auctions, which are characterizedby simultaneous, sequential, multi-unit asynchronous auctions.

There are many future directions we could pursue to make JACK more useful to researchers. Our mainfocus will be on improving both the expressiveness and simplicity of designing auctions and valuations.We intend to add additional built-in auction types such as combinatorial auctions and continuous doubleauctions, as well as control over parameter settings like information revelation policies, number of unitssold per auction, and budget constraints. With time, these and other more obscure parameters such asall-pay settings will hopefully become part of JACKs configurable functionality. Additionally, we would liketo improve the expressiveness of JACKs valuation functions. While allowing a fully expressive prior overcombinatorial valuations is infeasible, previous literature on experimental economics and autonomous agents

(specifically, TAC games) provides some direction as to what types of valuations should be easily expressible.With a more expressible auction and valuation space, we could implement previous and/or future TAC games.

Our second focus will be on simplifying the process of client design. We plan to incorporate into JACKbaseline bidding strategies from the auction literature which users can compete against and use as startingpoints for developing their own agents. These additional bidding strategies, especially if written in severallanguages, will allow for more flexibility for educators using JACK in the classroom. We will also add a GUIon the clients side to allow humans to more easily compete in these auctions. A challenge is making thisGUI general enough to be useful as a default GUI in multiple types of auctions.

As the number of auctions increases or the allowed time between bids decreases, humans may find thetask of manually placing bids and assessing the outcomes of past auctions overwhelming. A mixed-initiativesystem could aggregate auction data, present summary statistics to humans to better inform about upcomingdecisions, provide bid recommendations, or to take control of low-level tasks. One useful addition to JACKwould be to create a set of mixed-initiative agents for some of standard auction domains. Such agents would

lower the startup costs for researchers studying mixed-initiative auction systems, much like dummy biddersprovide a low barrier-to-entry for researchers building autonomous bidding agents.

A third area of focus will be on simplifying the process of experimentation. For trading agent researchers,this would include adding an agent repository and an experiment manager that can schedule games fortournaments or perform empirical game-theoretic analyses [9], and improving logging capabilities. For ex-perimental economists, a potentially useful direction would be to provide support code for integrating thesystem with Mechanical Turk, as well as providing further support for controlled testing in more traditionalhuman experiments.

We have released JACK as an open-source project at http://jack.cs.brown.edu. We expect the functionalityof JACK to grow as researchers use and extend the software to meet their own auction simulation needs. Wehope the availability of JACK will enable the TAC community, experimental economists, educators, and othersto more sharply focus on their core interests in agent and auction design.

9 Acknowledgments

This research was supported in part by Grant CCF-0905139 from the U.S. National Science Foundation.This research was also supported by a grant from the Dutch Organization for Scientific Research (NWO).

11


12/12

Bibliography

[1] J. Collins, R. Arunachalam, N. Sadeh, J. Eriksson, N. Finne, and S. Janson. The Supply Chain Man-agement Game for the 2007 Trading Agent Competition. Technical report, Carnegie Mellon University,

2006.[2] J. C. Cox and J. T. Swarthout. EconPort: Creating and maintaining a knowledge commons. Tech-

nical report, Experimental Economics Center, Andrew Young School of Policy Studies, Georgia StateUniversity, 2005.

[3] R. Dorsey and L. Razzolini. Explaining overbidding in first price auctions using controlled lotteries.Experimental Economics, 6(2):123140, 2003.

[4] J. Eriksson, N. Finne, and S. Janson. Evolution of a supply chain management game for the tradingagent competition. AI Communications, 2000.

[5] U. Fischbacher. z-Tree: Zurich toolbox for ready-made economic experiments. Experimental Economics,10(2):171178, Feb. 2007.

[6] A. Greenwald. The 2002 trading agent competition: An overview of agent strategies. AI Magazine,April 2003.

[7] R. M. Isaac. Just who are you calling risk averse? Jornal of Risk and Uncertainty, 20(2):177187, 2000.[8] P. Jordan and M. Wellman. Designing an ad auctions game for the trading agent competition. In

Workshop on Trading Agent Design and Analysis, July 2009.[9] P. R. Jordan, C. Kiekintveld, and M. P. Wellman. Empirical game-theoretic analysis of the tac supply

chain game. In AAMAS 07: Proceedings of the 6th international joint conference on Autonomous agentsand multiagent systems, pages 18, New York, NY, USA, 2007. ACM.

[10] J. H. Kagel, D. Levin, and A. Hall. Auctions: A survey of experimental research, 1995-2008. Handbookof Experimental Economics, 2, 2008.

[11] V. Krishna. Auction Theory. Academic Press, second edition, 2010.[12] N. Larson and W. Elmaghraby. Procurement auctions with avoidable fixed costs: An experimental

approach. 2011.[13] W. Mason and S. Suri. Conducting behavioral research on Amazons Mechanical Turk. Behavior research

methods, 44(1):123, 2011.

[14] D. M. Reeves, M. P. Wellman, J. K. MacKie-Mason, and A. Osepayshvili. Exploring bidding strategiesfor market-based scheduling. Decision Support Systems, 39(1):6785, Mar. 2005.[15] E. van Heck and W. Ketter. Software Agents Supporting Decision-Makers in Complex Flower Business

Networks. Liber Amicorum In Memoriam of Prof. dr ir Jo van Nunen, 2010.[16] Y. Vorobeychik, C. Kiekintveld, and M. P. Wellman. Empirical mechanism design: Methods, with

application to a supply-chain scenario. In Seventh ACM Conference on Electronic Commerce, pages306315, 2006.

[17] M. P. Wellman, A. Greenwald, and P. Stone. Autonomous Bidding Agents: Strategies and Lessons fromthe Trading Agent Competition. MIT Press, 2007.

[18] P. R. Wurman, M. P. Wellman, and W. E. Walsh. The Michigan Internet AuctionBot : A configurableauction server for human and software agents. In Second International Conference on AutonomousAgents, pages 301308, 1998.

[19] P. R. Wurman, M. P. Wellman, and W. E. Walsh. A parametrization of the auction design space. Games

and Economic Behavior, 35:304338, 2001.[20] D. Y. Yoon and M. P. Wellman. Self-confirming price prediction for bidding in simultaneous second-price

sealed-bid auctions. In IJCAI-11 Workshop on Trading Agent Design and Analysis,, 2011.

java configur kit

Documents