Thanks my Mike for posting the links. Btw I also contacted support for this issue because if this one proves to be feasible, there will be sort of a lot of money at risk AFTER DEMO-ING the system. I need to be sure. Many thanks also to Marcin from the Amibroker support team that offers sophisticated and fast support. From a theoretical point of view, I came to a conclusion, but please do not ask me about the practical deatils yet, I am not even sure if this is a reliable concept. (Reliable is the keyword in that sentence, I doubt that this concept would be reliable when applied to 3 or even 10 systems)
I do NOT require anyone to work out a custom tailored solution for this problem, and I am aware of the AT forum and I read up on autotrading in the user knowledge base. Yes, I also did study one post referring to static variables. As matter of fact, this is what I figured out so far: Mike's post does not work in AT/RT environment. You need to write one MASTER AFL that references/includes all the individual system logics. To avoid overlapping or referencing buy1 to sell2, or sell3, etc. one needs to use STATIC VARIABLES. ==> REAL TIME TRADING multiple systems is vastly different from BACKTESTING multiple systems. STATIC VARABLES is the concept that I did not understand initially but I read up on it again in greater detail. Another problem with my thought process was that I mixed up "BACKTESTING MULTIPLE SYSTEMS" and "REAL TIME TRADING SYSTEMS". ==> Mike's Custom Backtest Procedure works on BACKTESTS: NOT AT ==> Keith's post theoretically suggests the right way for REAL TIME TRADING, NOT BACKTESTING: this approach has been offered from Amibroker support, too (I'll explain later on) What to do: REMEMBER: MULTIPLE SYSTEMS ON THE VERY SAME UNDERLYING You process orders internally to an, let me call it "position pool": bar1: SYSTEM A: +2 contracts (2 contracts long) SYSTEMB: -1 contract (1 contract short) total: +1 contract. place order (LONG) for 1 contract. Bar2: SYSTEM A: no signal SYSTEM B: -2 contract place order (SELL) -2 contract overall = -1contract ==> Amibroker is capable of handling this problem, so to say transmits only the "netted/ summed up positions to IB" with the restriction of being net flat: [-1 contract ] + [+1 contract] ==> to Amibroker it means flat. ==> To me it means what's written there: +1 and -1 I am gonna stop at this point. Thank you all for your kind suggestions and help. Always good to get multiple inputs. This piece of code is gonna be very very very long. Have a nice weekend! Greets from Germany, Farewell for me. Matthias --- In [email protected], "Mike" <sfclimb...@...> wrote: > > What I described was aimed at backtesting multiple systems to emulate how you > trade in real life (i.e. generate statistics for how you would have traded, > as opposed to what you should trade next). > > I suspect that the approach that I outlined would not help generate trades > for you in real time since by definition the backtest acts on bars that have > already closed. > > I don't auto trade, so I'll leave that advice for others to offer. However, I > can point you to some links that can get you started. > > Your first point of research should probably be the User's Knowledge Base. > Herman and Al have written extensively there: > > http://www.amibroker.org/userkb/ > > Next, there is a dedicated Yahoo group for AmiBroker auto trading: > > http://finance.groups.yahoo.com/group/AmiBroker-at/?yguid=83897329 > > A member of that group, Barry, has posted a skeleton auto trading system to > the AFL Library which may be useful: > > http://www.amibroker.com/members/library/detail.php?id=1225 > > > Mike > > --- In [email protected], "Matthias" <meridian202@> wrote: > > > > Keith and Mike, > > > > thank you very much for your helpful postings. Looks like I'll have a long > > weekend :). > > > > Obviously I need to absorb and test what you've just said in great detail > > which will require time. I shall keep you posted. Just wondering if this is > > such an akward "out-of-the-world" problem. Things start to get complex here > > real quick (for me at least) and whatever approach I take, it seems to be > > error-prone if not done/checked ultra-carefully. Maybe this one could be > > implemented a little easier in future versions of Ami so that one could > > spend more time on system development or portfolio composition rather than > > spending hours n days to tailor simple AFL's into 1 complex > > "multi-AFL-combined-and-custom-backtest-proc-afl" > > > > Regarding Keith's post e): > > > > ////////////////////////////////////////////////////////////// > > I don't know if AB can properly handle long and short positions > > simultaneously in the same stock or contract. That will require a simple > > experiment on your part. If AB can't, then simply export your symbol of > > choice, import into a spread sheet or text editor, change the symbol to > > something unique like symbol_SO, and import back into your data base. Now > > you have two separate symbols, which we know AB can handle properly. > > > > /////////////////////////////////////////////////////////////// > > > > Just by reading it, I figured that one would require an external source, > > such as Excel. Problem here is that this is supposed to work in RT > > environment doing autotrading, anyways I'll look into it. > > > > > > > > Regarding Mike's post: > > > > /////////////////////////////////////////////////////////////////// > > I haven't actually tried any of the above, and do not know how well > > it would translate into auto trading > > /////////////////////////////////////////////////////////////////// > > > > Sounds like this is something extraordinary, but are there so little user > > asking about this multiple-system concept? Look, I don't have an account to > > autotrade yet, but if I figured out a way on how to do this, this would be > > run in AA window, "backtesting" the system, so to say - run that piece of > > code every xx minutes, is that correct? I remember somebody from Amibroker > > support told me to program it like a scan and think of autotrading like I > > would just scan for signals. Not sure if I understand the concept, but does > > scan include custom backtest proc? > > > > I'll see what goes, but out curiosity: just wondering if the execution > > speed of this code would be proefficient. > > > > > > Thanks again. > > >
