scalabm / agora Goto Github PK

Based on conversations with economists KAPSARC, there are a number of interesting benchmark cases for multiple market clearing. A similar functionality is also supported by old CRISIS code.

Reason that each order has unique id is so that orders can be removed from order books more easily when cancelled...

Need to implement come concrete Tradable objects...

Need to port over code for ask and bid order books.

Need to allow user to configure the amount of parallelism used by the parallel collection backing the classes in the orderbooks.parallel pacakge. See Scala docs explaining how to do this. Can this be done using implicits?

Need to make sure orders are removed from the MarketParticipantLike actor's collection of outstandingOrders .

Here is an example of the stack trace...

[ERROR] [12/15/2015 14:16:21.061] [model-market-dispatcher-6] [akka://model/user/$b/clearing-mechanism] next on empty iterator
java.util.NoSuchElementException: next on empty iterator
    at scala.collection.immutable.RedBlackTree$TreeIterator.next(RedBlackTree.scala:475)
    at scala.collection.IterableLike$class.head(IterableLike.scala:107)
    at scala.collection.mutable.TreeSet.head(TreeSet.scala:41)
    at scala.collection.TraversableLike$class.headOption(TraversableLike.scala:440)
    at scala.collection.mutable.TreeSet.headOption(TreeSet.scala:41)
    at markets.clearing.engines.CDAMatchingEngine.accumulateBidOrders(CDAMatchingEngine.scala:108)
    at markets.clearing.engines.CDAMatchingEngine.findMatch(CDAMatchingEngine.scala:66)
    at markets.clearing.ClearingMechanismLike$$anonfun$clearingMechanismBehavior$1.applyOrElse(ClearingMechanismLike.scala:39)
    at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:170)
    at akka.actor.Actor$class.aroundReceive(Actor.scala:480)
    at markets.clearing.ClearingMechanismActor.aroundReceive(ClearingMechanismActor.scala:39)
    at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
    at akka.actor.ActorCell.invoke(ActorCell.scala:495)
    at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
    at akka.dispatch.Mailbox.run(Mailbox.scala:224)
    at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
    at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
    at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
    at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
    at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Here is the application.conf file used to generate the bug. Bug appeared as soon as I started allowing market orders. This suggests that bug occurs when either askOrderBook or bidOrderBook is empty?

Possibly a bug with TreeSet? Seems unlikely...

Codacy detected an issue:

Message: Cyclomatic complexity of 15 exceeds max of 10

Occurred on:

• Commit: c2f463e
• File: src/main/scala-2.11/markets/clearing/strategies/BestLimitPriceFormationStrategy.scala
• LineNum: 46
• Code: def formPrice(incoming: OrderLike, existing: OrderLike): Long = {

Currently on:

• Commit: 06e7f50
• File: src/main/scala-2.11/markets/clearing/strategies/BestLimitPriceFormationStrategy.scala
• LineNum: 41

If we define an ExchangeActor to be a collection of MarketActors that use the same type of matching engine and share a common settlement platform, then we can have the ExchangeActor create a new MarketActor on the fly...

...need to allow for the possibility that ask or bid orders might be rejected unless they improve upon the current best ask or bid limit prices. In the literature this property is typically referred to as a price improvement or spread reduction rule.

Currently there are a couple of methods for the base actor (i.e., timestamp and uuid) that should have parentheses!

Need some Actor thats serves as a pipeline to a Cassandra database. This actor could be inserted in place of a SettlementActor to capture filled orders more efficiently than logging them to a file.

Currently the MatchingEngineLike has an abstract crossing method that should return true if the incoming order crosses the best existing order. @danftang suggested that the crossing logic should be implemented for each order.

Need to have some notion of a "fuzzy" limit price to capture the idea that seller might want to sell for more than X, but would sell for Y < X. This happens in housing markets (for example).

A continuous matching engine attempts to match individual ask and bid orders immediately upon receipt. A discrete matching engine, on the other hand attempts to match collections of incoming ask and bid orders after discrete time intervals.

While the PostedOffer and BilateralNegotiation matching engines could possibly operate as either continuous or discrete matching engines, continuous double auction matching engine would always be continuous and the call auction matching engine would always be discrete.

In addition to limit orders, need to support market orders.

Should implement a StopOrderLike trait which defines a stop price for an Order. Investorpedia has a decent description of the difference between limit and stop orders.

All markets need to store orders in orderbooks. A collection for storing orders needs to be able to do the following...

1. Insert an order into the collection
2. Remove an order from the collection
3. Pop off the "best" item in the collection (where "best" is defined in terms of the ordering/priority over the orders in the collection)

Default implementation uses TreeSet.

...need to sort out how put individual performance testing results into individual directories.

Need to timestamp all messages. Not clear what the optimal way to timestamp messages is for now I am going to call System.currentTimeMillis() as suggested here.

When MarketBidOrder crosses MarketAskOrder looks like price of zero is generated (instead of reference price); also when MarketAskOrder crosses MarketBidOrder price of Long.MaxValue is generated.

Hide as much information as possible in the API by making all fields and methods as private as possible. Only expose those fields and methods that might be needed by users!

Need to have a concrete implementation of the CDAMatchingEngineLike trait.

Base actor implementation should include logging...

Need some actor to handle the actual exchange of resources between trading parties.

Need to be able to mix-in some type of ordering/priority for ask and bid orders.

...need to reduce message traffic. Obvious candidate is to eliminate the forwarding of orders between MarketActor and ClearingMechanismActor.

...instead the Quantity trait should be mixed in with LimitAskOrder and LimitBidOrder traits. This simple change requires larger surgery on the type structure for continuous auctions.

....currently all actor life-cycle hooks and supervision strategies are implicitly using the default values. I want to force developers to explicitly specify life-cycle hooks and supervision strategies.

Should alter build scripts for travis so that API docs and test coverage for the develop branch are hosted on GitHub.

I have noticed that the testing code is super redundant (i.e., lots of copy and paste)...need to refactor this.

Need to implement a sequential call auction matching engine.

Number of policy relevant research questions related to tick size for various assets. User should be able to specify the tick size for a Tradable.

Important decision in auction design is whether or not market participants can access information about the current state of the order book(s). Auctions mixing in the SealedBidding trait do not allow access to the state of order books; auctions mixing in a OpenBidding trait must implement a method to allow market participants to view the best ask/bid orders contained in the order books.

Logically, since AskOrder <: Order then it should follow that OrderBook[AskOrder] <: OrderBook[Order] however this is currently not the case in the code. Will need to refactor the add and reduce method signatures to make this possible.

...an Order implementing the Splitable trait will represented and order that can be split into separate orders. This feature would be used to capture the "execute and eliminate" orders that are widely used on real financial markets.

...need to figure out how to host performance testing results online.

Base class for all settlement mechanisms.

Need some actor that just receives filled orders and logs them to a file. This actor can then be inserted as a SettlementActor. This would be useful for testing purposes as well as for replicating many of the stylised financial market ABMs.

Need to timestamp all messages. Not sure how (or where) I should get the values for these timestamps.

Need to support deferred acceptance algorithm. Can it be supported via my map-reduce based framework? Here is an R implementation for reference.

@danftang also suggests that price formation not be done in the matching engine itself but rather as a part of the settlement process of as part of some intermediate process between matching and settlement.

Theoretical literature on market design suggests that the size of a market's memory (i.e., the depth of its order books) is a key parameter. Current default implementation of a continuous double auction matching engine uses a TreeSet to model order books. TreeSet collections do not have a fixed size.

Should our default implementation of a continuous double auction require order books to have a fixed (and configurable) size?

Want to automate the deployment of the library (including all dependencies).

I share all of my Python libraries via PyPI. What is the Scala/Java equivalent? Ivy? Maven? Both? Something else entirely?

It was a mistake to store the entire sequence of ticks in the ticker agent. There should be some fixed number of "recent ticks" stored in the ticker agent. Storage of entire tick history should be done outside the model.