Java Based Trading Agent

1. Java Based Trading Agent Avinash Shenoi Sohel Merchant Zhikun Meng

2. Outline • Introduction • Motivation • Michigan AuctionBot • Trading Agent Competition • Strategies • Our strategy • Implementation • Taclib (java library to interface with the Michigan AuctionBot) • Design • Code

3. Introduction • Travel Agent to do online trading. • Interact with the Michigan AuctionBot • Aim is to acquire the most feasible travel package for its clients. • Each agent is allotted a set of eight clients. • The individual auctions competed for are: • Flights to and from Tampa • Hotels in Tampa • Entertainment tickets for stay in Tampa

4. Motivation • Why? • Radical change in the why business is done • E- commerce a new revolution • Predictions • Revenue from e-business in 1997 - $ 8 Billion • Predicted revenue in 2002 - $ 327 Billion • Future of auctions – Online and automated • Proven by success of sites like e-bay and u-bid • Agents fit in well in this scenario • Gather domain knowledge and exploit the boom in this market segment.

5. Motivation • How ? • Use the Michigan AuctionBot. • Free test bed for agents. • Platform that supports different types of auctions. • Operates in the business segment of Travel Market. • provides competitive environment for agents. • Build an agent that operates in this environment. • Study different strategies used in market auctions. • Use a new java library to interface with the AuctionBot. • Allows developers to focus on strategy. • Isolates developer from idiosyncrasies of interfacing.

6. Trading Agent Competition • Market game in the Travel Market Segment. • Runs on the Michigan AuctionBot. • Provides TCP based API’s to Developers • Goal of agents is to assemble a feasible travel package • Round trip flight • Hotel reservation • Entertainment Tickets • Alligator Wrestling • Amusement Park • Museum

7. The Game • Each agent is allotted eight clients. • Feasible travel package: • Round trip flight (at least 1 night in tampa). • Hotel reservation for duration of stay. • One type of entertainment for a day. • Separate auction for each of the components

8. The Game • Flight auctions • One-sided auctions • Unlimited supply • Prices follow a random walk • Tickets acquired if bid price > ask price • Clients specify the days of travel

9. The Game • Hotel Auctions • Two hotels: • Premium: Tampa towers • Mediocre: Shoreline Shanties • Traded in ascending auctons. • Close at random intervals • Clients specify which hotel they prefer. • The price paid for a room is the 16th highest price quoted

10. The Game • Entertainment Auctions • Initially a set allocated to agents • Continuous double auctions • Agents can both buy and sell tickets. • Clients specify what entertainment they prefer and a weight is allocated for this.

11. The Game • Client Preferences • Preferred arrival day. (PA) • Preferred departure day. (PD) • Premium value for better hotel. (HP) • Premium value for type of entertainment. • Alligator wrestling = AW. • Amusement Park = AP. • Museum = MU.

12. The Game • Actual Travel Package: • Actual arrival date. (AA) • Actual Departure. (AD) • Premium hotel indicator. (TT?) {0,1} • Entertainment type indicator. • Alligator Wrestling. (AW?) {0,1} • Amusement Park. (AP?) {0,1} • Museum. (MU?) {0,1}

13. The Game • Client Utility • U = 1000 – travel penalty + hotel bonus + fun bonus • Travel Penalty = 100 * | AA – PA | + | AD – PD| • Hotel bonus = TT? * HP • Fun Bonus = AW? * AW + AP? * AP + MU? * MU • Zero for infeasible package

14. Strategies • Bidding • What to bid for • How much to bid for • How many to bid for • When to bid • Observation • Hotels were the most highly contested commodity. • Flights were contested towards the end • Allocation • NP domain problem • Optimal allocation • Greedy allocation

15. Our Bidding Strategy • Flights Auction • Bidding is done in regular intervals • Two phases • Decided by a tunable parameter • First Phase (approx 8 min) • Bid below the ask price. • Decided by another tunable parameter • Second Phase ( near end of game ) • Bid higher than ask price • Get tickets at maximum cost feasible to us

16. Our Bidding Strategy • Hotel Auction • Initially Bidding is done for both Tampa Towers and the Shoreline Shanties. • Two phases • In the first phase the agent bids at moderate prices for the hotels. Towards the end the agent puts forward aggressive bids to acquire the Hotels for the valid clarets.

17. Our Bidding strategy • First Phase (approx 8 min) • If the bid goes below the current ask price then depending on whether flight tickets are bought the decision is made to carry out the bidding for a particular hotel or the client is totally abandoned. • Second Phase (near end of game) • The bids are continuously incremented by constant bid increment if the current bid is below the ask price for all valid clients.

18. Our Bidding Strategy • Entertainment Auction • Bidding is started at a time specified by a parameter • The currently held entertainment tickets are examined to calculate which ones can be used for clients that currently are expected to get hotel accommodation and Flights • For tickets that can be used the increased utility of holding these tickets is calculated

19. Our Bidding Strategy • Entertainment Auction • If there are clients without entertainment on a particular night they are expected to stay, the agent compiles a list of desired entertainment tickets and the extra utility they would generate. • The agent places sell bids for all unused tickets • Desired tickets are bid for at a discount to their expected utility.

20. Allocation • For allocation of the acquired flights, hotels and entertainment we use the standard allocator provided by the Michigan AuctionBot.

21. Design and Implementation • Java used for development. • Focus on strategy. • Don’t have to worry about interfacing. • TACLib API’s used for interfacing. • No stable build exists yet. • Nightly builds. • Not all API’s provided are supported completely.

22. Implementation details • Classes for each of the auctions • Flights • Hotels • Entertainment • Driving class for co-coordinating above classes • Class to maintain status of Clients during auction

23. Questions?