November 29th, 2010, 4:43 am
QuoteOriginally posted by: HendersonVery interesting project! Cuchulainn, what models would you recommend for handling that task? I started a very similar project in the past but put it on the back burner after hitting those issues....This is no trivial system to design. Some challenges imo are;1. The (many) algos, create them and are they good?2. How to architect and design the system so that it is efficient, portable3. Is the resulting trading strategy OK i.e. does it produce a good CAGR?Regarding point 2 I have an execution plan based on my Domain Architecture models (it's on my web site where I have written a book in 2004 on this topic). The five domain architectures presented are:Manufacturing (MAN) Resource Allocation Tracking (RAT) Management and Information Systems (MIS) Process Control and Real-Time (PCS) Interactive and Access Control Systems (ACS) To make a long story short, all the systems I have developed, cooperated on and project managed the last 30 years are special cases or instances of the above categories (or their combinations). In the current case (for example a pairs trading app just to keep it concrete) I would see it as an example of a RAT category. Knowing this, I can then use the RAT context subsystems to help design/'cookie-cut' the current app. In the first place, we have about 10 subsystems which have to designed using the algos in step 1 above. The RAT system needs to work with a MAN system for historical data and also to some higher MIS reporting system.What problems does this resolve? All subsystems can be independently designed by mapping to black box dlls with standard interfaces. This is a major advance on traditional OO classes which tend to become unmaintainable as their number increases. The classic mantra 'object model the world' is true but we should think in terms of objects just yet. In the 'new' way we hide bunches of classes behind standardised interfaces.So, loose coupling between the different engines is something good.QuoteForgive me for not knowing the correct terminology, but there are 4 main sections.1. There's a series of static classes which I have written to hold several fomulae. 2. There's a series of classes written to take data from whereever it may be and put it through the mathematical models and collect the results.3. There's the GUI designed to present the findings of 2 and request a new series of tests to be done by 2.4. The Interactive Brokers API wrapper and the link to a database to store stock data etc.These entities have their equivalents in a RAT trading system. The subsystems contain these classes but coupling is reduced because of interfaces, again. Like little areas of expertise.Hope this helps, Henderson. Are there other issues not addressed here?
Last edited by
Cuchulainn on November 28th, 2010, 11:00 pm, edited 1 time in total.