<a href="http://www.datatime.eu/public/gbot/Sun 15 Aug 2010_port4001_Cli3_2/GBotReport_2010-08-15_port4001_Cli3.htm"> Chart update </a> This was a wild week. (Yesterday the PNL spiked down crazily.) <img src="http://www.datatime.eu/public/gbot/Res_Sun_2010_08_15_3.png"> Next week i will (hopefully) test the "folio overlying" technique (I am adding some code to ease the task). Tom PS while was editing it closed all at 35K (probably due to a sudden price change of HG)
A few considerations while i refine the code to get ready for the next "folio overlaying" test. It has been anyway useful to test instruments far from expirations. It has made even more evident the variation of the spread during the day. In next revision I will split the computations of the running mean spread keeping separate the RTHs, where the spread turns relatively smaller. It has also made tangible how the concept of a "large" spread, is clearly relative to the instrument and varies with time. So I have also introduced a different way to compute the reference average spread. This new way could be defined "selfcensored", as the dynamic average spread is computed in such a way to "autoremove" the inevitable outliers. While in statistics the concept of "trimmed" mean is common, in this case we need to slightly adjust the concept, as data arrives sequentially (so the concept of "large value" must be defined dynamically (autoadaptive process) and cannot be based on a known set of values). Keeping track of spread is always useful. Note that for instance a quick move may cause the spread to appear larger, and this can help identify price surge ends for better order placement. As i have talked with several people interested in algorithmic trading, and watching this algorithm in particular, I have noticed how practically all of them somehow assumed that this specific algorithm is classifiable as (these are various terms i heard) "countertrending", or "mean reversion" or "measure exhaustion", and so on. I think i made some cursory remark on that at the beginning of the thread, but perhaps it's better to clarify. This algorithm is actually coded as a superimposition of "trending systems", although the way it works causes a sort of "optical illusion" of countertrending and avg up/down. The algo is actually coded in the form of 2 main <b> concurrent trending strategies</b> (they are overlaid) and the effect of "countertrending" is merely due to the fact that there is a <b>"masking"</b> effect of one of the trending system on the other one, so that, visually, an "illusion" of countertrending emerges. Tom
Hey Auto: good job there. Could I ask this question: could you give a quick overview on how to develop such robots? I know how to program in a number of languages. I want just to know the framework, things to read, tools to use, etc to develop an easy robot, and then program a more evolved one. Thanks! With regard to instrument to trade, I did not read all pages, but it seems to me that an instrument such as the Swiss frank would do well in your robot because it is generally not as correlated to the stock market as other instruments such AUD. There is another instrument which I think may do well as it moves around a lot. It is AUD/JPY. You may want to use it as a replacement of stocks. One final point: I use a notebook and you charts cause the display to appear strange. You may want to resize or post image as attachment. I am positive that a lot of poeple might leave because of this inconvenience.
Hi tradingjournals, thank you very much for your suggestions. Sorry for the size of pictures. I have actually reduced the windows size before capturing screenshots, but probably they are still a little too large: I was kind of assuming all people here works with large resolutions or multiple screens ;-) I have been using CHF. I used futures, although this platform can trade anything (including options). The reason i prefer futures to spot is that from my analysis using the otc forex tickdata I noticed that the performances obtained are systematically lesser than the corresponding futures (there are also other considerations which make me prefer futures anyway). As to development overview, this particular platform is created with Visual Studio, the well know development environment by Microsoft. Clearly, it would be possible to using any other fine technology, such as Java for instance. Visual Studio allows the coder to choose within several languages, such as c#, VB.NET, j#, c++, etc., which could also be used together inside the same project (language integration). I personally consider technology as a mere tool, and <b>i live with the compiler as a cook with his knife</b>. It becomes a <b>forgotten "extension" of your body and mind</b>, and allows you to focus solely on algorithm research. But just as the craftsmanship of making knifes has little to do with making a beautiful and healthy meal, being a good programmer may have little to do with being an excellent quant. So my advice regarding development is just make yourself at ease with one major OOP language (can be anything like vb.net, c#, c++, java, ...) and then forget about it, totally focusing on the development of algorithms. Let the ideas flow. Test carefully all of them and all implementation variants. The tool is not important (once you move in the realm of tools which allow an easy projection of ideas into running software). Another advice i would give (but may not work for everyone is): be original. Don't look too much around. Find first your own way, and maybe, later, compare with other sources and improve further. There is too much misleading information around. It's really mostly a journey in our mind: as often happens in science we discover and model the world looking inside ourselves. Hope i am not disappointing you, but really it's not about technology (which probably represents less than 1% in this quest), and I would probably be misleading by providing a list of tech resources. If you start creating a robot feel free to bring here ideas and implementation issues. Tom
If you install the 904 version of standalone TWS, you will see under the IB startmenu, an option to run IB gateway. The gateway defaults to socket port 4001, which can be changed to 7496 which is that of the regular TWS. Once the socket port is set properly, many IB front ends will run properly with the new IB gateway. Unfortunately, NT7 does not.
<b> FIGHTING RISK: Overlaying robots, Cloning instruments and overlaying folios</b> Once we have a strategy we like, next step is making a good <b>"trading architecture"</b> so that we can spread the risk as much as possible. So, instead of increasing to size of each single position, we prefer opening "new instances". We can open new robot instances, on the same account (same port, multiple clients) or on multiple accounts (multiple ports). And, for each robot instance, we can overlay multiple folios. Let's see how i have implemented that. Look at the following picture. For each instrument, one can add 1 (or more) "clone instrument(s)". <img src="http://www.datatime.eu/public/gbot/CloningFolios.png"> What is a <b>"clone instrument"</b> ? Assume I have AUD and I create the first "clone instrument". The robot creates the "clone" and calls is something like "AUD_C1". What is AUD_C1 ? The robot considers it as a brand new instrument, but the price curve * is the same as AUD * (same tick data). AUD_C1 orders, clearly, will actually use AUD. If we repeat that for all instruments (or some of them), we obtain a <b>"clone folio"</b>. Now it should be clear that this way we are "spreading the risk". For instance we could activate the clone of each instrument when such instrument shows a sign of reversal (no need to activate the clone folio all at one time). Clearly, when capital increases, we can overlay any number of folios. Thus reducing the overall risk. So, we can easily have an architecture with : M robots r1 ... rj ... rM (possibly working on different accounts), and each robot rj can work with a superimposition of F_rj folios (all out of sync). This way we create a sort of generalization of common long / short pair concept which certainly most of the time can help reduce drawdowns and minimize the overall risks dealing with <b>large capitals</b>. Clearly an external observer looking at the account activity will only "see" the "algebraic result" of the various superimpositions. Sharpe/Sortino ratio will improve significantly due to variance reduction (and note that, for instance, this example strategy, without any overlaying has shown in backtest Sharpe ratios up to 9 in the best simulations). In practice, more capital we have, and more the overall game can be "relatively"safer. [Besides the rollover facility, which, practically, "joins" price curves will allow us continuing trading even if we get when caught in an "investment phase", so that we do not have to take the losses.] Tom
Sorry if this question has been asked before. But how do you deal with slippage between theoretical fills and actual fills?
Hi walterjennings, thank you for your interesting question. First of all let me clarify that the robot places <b> only LMT orders</b> (unless the user deliberately overrides the default settings). So, "slippage" in this context could be "intended" (perhaps the usage of the term is actually incorrect in this situation, and you might suggest a better one) as failing to get filled, at the given LMT price * within a given timeout * (for instance a few seconds or minutes). In such a case (order not filled within prespecified term), the robot would behave as follows: 1) The LMT order (<b>or partial unfilled</b>) is cancelled 2a) If a "close condition" is still satisfied (like, for instance, a "scalp size" exceeded) a <b>new lmt order</b> is issued (possibly for the remaining part to be filled). 2b) If, instead, the price has moved away and the "close condition" is no more satisfied, it will wait next occurrence. When the condition holds again, a lmt order is issued (possibly for the remaining part to be filled). Tom
ok have been testing the clone instruments price curves. This is a reduced picture of the week to now. The clone folio has been started a few minutes later and has remained in "manual mode" (that is not trading), just for testing (an ivory background signifies "manual mode"). Min scalp size was 260$, closed all nicely at 5K (for scalp close factor 5.5) or 7.4K (for scalp close factor 3). (As anticipated, I have split the spread computations.) Next test I will "activate" the clone folio, so that it will trade "against" the original folio. The important question here is: <b>what are the activation conditions? When it's better to start trading the clone ? Should we be putting some constraints on entries ?</b> In the next post will be proposing a few ideas. In the meantime, please feel free to propose yours! So that we can test them all simultaneously on a parallel test and compare the behaviors. <img src="http://www.datatime.eu/public/gbot/Sun29small.png">
<b>FOLIO OVERLAY AUTOMATION</b> The purpose of overlaying folios is clearly that of possibly reducing the risk. For now i had the following ideas, but i hope you can add more: - 1a Start a folio. Wait a drawdown (so we are intuitively half way of a "price wave"). When there is a sign of reversal start a clone folio. - 1b Do something similar to above, but at instrument level. Starting the clone(s) of each instrument separately. The above, in the best and ideal scenario, should allow (after the first half price wave) suffering just <b>half drawdown for the same price excursion</b>. (Intuitively, risk ratios might double and profits slow down) The following could be a less discretionary method: 2. The clone folio has entry constraints as follows: When a first entry has to be made, say for CL or one of its clones, we look at all the instruments which are working with the same price curve ("clones of CL"). Then we compute the sum of positions of all the instruments using CL. If the sum > 0 we disable a (first) long entry, if the sum < 0 we disable a short (first) entry. This way we can overlay several clone folios, all out of sync, which will be hedging each other. With such constraints, waiting for an initial drawdown should be useless, as naturally the new entries for the clone should appear on reversals. (This might be (if it works) a first idea towards <b>folio overlay automation</b>.)