this might be off topic but I used to engineer pacemakers.. the heart and the pacer each modify the behavior of the other.. the situation with a trader or ATS and the market is similar... I used to flow chart the whole process but color code the heart's actions and the pacer's actions separately, it really helped to describe the situation... Programmers seem to hate flow charts but for a situation like ATS vs Market I find that flow charting a script before coding it is absolutely essential to a nice project workflow from design to working/debugged code...
Dloyer, I'm beginning to implement state driven order handling mechanism... mind sharing some of your experience here... what to watch for? My idea is to look at the states such as fillRequested, filled, cancelRequested, canceled... do you define all possible/and impossible combinations and handle everything (lot's of if else statements) you you came up with some more elegant way? thanks
I think when Dloyer refers to 'state driven', he may be thinking of this http://sourcemaking.com/design_patterns/state, rather than a Forrest of if/then/else.
Not a big deal. If done right, there is very little if/then/else logic and very little code. Here is how the one I hacked together works: I use a object per symbol and per system. Each system is a sub class of a general system abstract class. There are virtual methods to handle things like ticks, order events, time. The main state logic you need is what is the current position, anything you need to calculate entry/exits, price. I use one thread to talk to IB and process messages on order status and account information. Another thread talks to IQ feed and parses tick messages. A normal morning processes > 2000 ticks/second with less than 5% CPU on a Intel i7. The main() function loads a xml file that defines system settings, symbol lists and systems to run and launches threads for IB and IQFeed and the web interface. The web interface is nothing more than a server socket that waits for a connection and spits out a simple html status page. Orders have their own object to track order state and the system that owns them. I currently only trade one account and trade long only. It keeps the position logic simple. There are position limits on each system. I make a lot of use of orders that specify a cancel time to make the system more robust in case of a crash. Every night the system downloads daily, fund and tick data for all nsdq symbols. The shared code is about 2,000 lines of code and each system is another 300-400 lines of code. If you are starting from scratch, consider the open source project tradelink. I dont use it, but I think that it has a similar design. If you dont write much code, it is easier to use a already built framework. I have been writing code since I was 12, so for me it is easier to build what I need. Hope that helps. Let me know if you have any questions...
Dloyer, few questions if you don't mind? 1. Why you use virtual methods to handle ticks? 2. What do you mean by "The main state logic you need is what is the current position, anything you need to calculate entry/exits, price." can you please add some details. Thanks
currently I work on a sub-system for execution.... The function of this component is to get rid of order handling complexities... here is what I intend doing.. 1. Trading system class 2. Each system can have more than one position 3. The function of position is to SPECIFY what the strategy wants to have example: My system S1 only specifies wanted holding... 1000 shares of coca-cola for example 4. Execution manager is a thread... all positions are registred with execution manager and they all know who owns them 5. Execution managet goes trough the position (looping infinitely) and does the order handling to make sure position is implemented... example: the system runs in separate thread... all it does it specifies how many shares it wants. In another thread, execution manager compares "wanted" with "actual" holding and places/cancels the orders to achieve this... if system wanted 1000 shares of coca-cola and it had 300 already, execution manager will place order to buy 700 more the idea here is that startegy is not pushing the orders into the market, but the execution sub-system is pulling the position state, applying the order handling logic, and then pusing the prders to the market? comments?
Hmmm. The role of the trading system is to react to market events, (trades, quotes, time) and respond with orders. Virtual methods can avoid a lot a if/then/else logic and make it easy to abstract a system from the events that drive it. For example, there might be a virtual methods for gotQuote() and gotClockTick() that are called by the market data interface in response to market events. The broker interface would call methods like orderUpdate(). What these functions do is dependent on the system logic. The system code''s main role is to call placeOrder() and cancelOrder() for example. I use a object per system, per symbol. Any given system can only have one position per symbol Further, I only have one entry and exit per position, per symbol, but more than system can trade the same symbol, each with different entry and exit rules. If the intent is to scale in and out, then this can be done by having many closely related systems with slightly different entry points. The can increase overall capacity and improve performance by being slightly de-correlated. From the your description, it is not clear if you have a thread that spins, but if so then that should be avoided. Wait for a event to occur, either a time tick or a market event, then trigger a entry or exit if needed.
@Chronos I am a newbie....just playing with Amibroker & TWS api and wondering what the optimum elegant solution should be...was just thinking that order execution should be forked over to a new thread which should report back.... You have given me a whole new perspective...my thanks! Sanjay.
agree also fully. Now running market data feed subscription on a TIBCO bus and the ability to publish data for storage purposes, to calculate stats, indicators, factors, and to feed event structures of a finite state machine that essentially represents the core trading logic.