The Algo is built on SierraCharts Excel. The saying "How do you eat an elephant? Answer: "One bite at a time" applies here. It is something no one could do off the top of their head in a week. If I lost the formula I would have difficulty rebuilding it quickly. I don't use Sharpe ratio, Amibroker use it standard in their backtesting model, but I'm not too much a fan of ratios due to the fact market conditions change and what once was doesn't always transpire to the future. Another issue is I have only 9 months of intraday data to test on. I do have many years of EOD data on Amibroker however I can only eyeball this as it relates to my signals. I don't wish to advertise much about my system other than to say it is not HFT. Trading 1 x SPI contract (that's all I'm doing until bedded down) returns approx $100/ trading day over past 9 months (backtested). 1 x SPI contract at the moment is $114,000. Profit loss ratio and win rate is very high and I'm sure would return lots of negative comments about unsustainability etc were I to mention it, so I'll leave this bit out. I've actually erred on the side of caution in design. Many trades the algo won't take, I would rather not hit so many trades but get a higher win rate.
Progress report: The simulator engine is fundamentally done. It has been taking somewhat more than expected to finish because of a lot of details that need to be taken into account. For testing purposes I'm using a dummy Ghost which goes long/short on some given SMA/EMA crossovers. By now this is what I've got working: - Able to deal with any historical quote timeframe - Auto-detects pip unit for currency pair - Configurable start equity, default order size, maximum drawdown allowed per trade, estimated slippage - Calculates and accounts for all broker commissions for opening/closing orders - Its aware/reacts accordingly to minimum margin requirements for all open orders, minimum equity for opening new positions, maximum loss per trade and margin calls - Outputs detail for all trades and final report of end equity, max drawdown, total commissions - Only one trade allowed at a time. I considered allowing for adding to existing positions but couldn't find a good enough reason to do that as it increases exposure and non-linearities on the algo performance. - A short decision while carrying a long position will close the previous long and vice-versa. This means if we're long on the market, we can only enter the reverse direction after two signals to short. What's missing: - Sharpe ratio calculation (near completion) - Configurable max drawdown per day - Report total wins vs. losses - Graphical output? (not a priority) - (...) Current code size: SHELL: ~600 lines Dummy GHOST: 10 lines MBT Broker API constants/enums: ~400 lines (will not grow unless there are API changes)
@tiagor - do you use multithreading? Such as downloading quotes (Shell) in one thread and processing quotes (Ghost) in another thread.
No, not yet. Both quote event handlers and the ghosts run on different classes so the change to go multithreaded should be minimal. By now my main priority is having a minimum working setup. When everything is working I have to go threaded to be able to trade multiple instruments - 1 thread per ghost/per instrument.
since you're using python look into zeromq instead of python's builtin threads which aren't what you might think they are. Also, the reactor pattern is commonly used in these systems so as to avoid messy threading. python has a library called twisted its like c++'s ace
Thanks. Checking it out now and will try it as my previous experiences with threading (mostly with C) have not been happy because of locking and synchronization issues.
Why thread? It's expensive, and more importantly, bug prone (it's tricky to get the locking and syncing right). Locking and unlocking can take between 30-100 ns, in C. Assuming your code doesn't actually do much (and there's not much you can do in 600 lines), you're not actually saving that much, and you can save a lot more just by writing more efficient code and data structures. Most threaded code I've seen is written that way because the developers are lazy and start a new thread for every random task they have; they can't be bothered to write it correctly.
Threading IS expensive. But I'm not even attempting to compete in the HFT league so I'm not overly concerned with timing issues at the moment. I will need threading though for parallelizing trading on multiple instruments.