Nick, I think you've expressed the idea pretty clearly. In concept, it seems that being able to take advantage of multiple "master loop architectures" would be a very cool ability for an optimizer to have.
This is something I have speculated on and done a small amount of private experimenting with myself (outside of AB). I don't think any one given loop architecture could ever be the "right choice" for all possible jobs. Of course, creating and maintaining the code for alternate loop architectures could be a tall order (lots of work!). If it could be done successfully though, the product would have a superb ability to be "matched" to different job types. I suppose only TJ can comment on how this might relate to current or future iterations of AB. - Progster Could this idea be used to advantage in AB? I suppo --- In [email protected], "nhall" <[EMAIL PROTECTED]> wrote: > > I think you misunderstood what I was trying to say. When I'm talking > about signals, I'm not talking about the signals that you actually see > in your Optimization/Backtester results pane, I am talking about the > RAW signals that AB generates during the first pass of backtesting. > These are just temporary signals that can be saved until the end of > processing. Let me try to be a little more clear. This is how I > understand the optimizer currently works for optimizing over a portfolio: > > - Loop through the parameter combinations > - For each parameter combination, loop through every symbol > - Calculate the signals from the AFL for this one symbol > - Once the raw signals have been generated for all the > symbols for this particular combination, generate the > final buy/sell signals and results of the portfolio > backtest for the given parameter combination. > > When I do a portfolio optimization I can see that this order of events > is being done because as soon as one combination of parameters has > been backtested, the results are immediately outputted in the results > pane of the Optimization/Backtest window. > > This method switches between symbols (# Symbols * # Optimization > combinations) times. > > > After reorganizing the order of events: > - Loop through every symbol > - For each symbol, loop through each parameter combination > - Calculate the signals from the AFL for this one symbol > - After the AFL has been run for this symbol for every > optimization combination, save these raw signals in > memory and move on to the next symbol > - Once the raw signals have been generated for all the > symbols, for all combinations, then the final buy/sell > signals and results are generated for all parameter > combinations. > > The downside of this is that the optimization results are not obtained > for any parameter combination until all the combinations have been > backtested (not a big deal in my opinion). > > The upside is that it switches between the symbols only (# Symbols) > times. Say you have a 5000 symbol database and are doing a 100 > combination optimization, that means 500,000 symbol switches with the > current method. By reorganizing the sequence of events that means only > 5000 symbol switches. You would have to save more raw signals to > memory, but this would probably be better than doing all those symbol > switches. The goal is to be processing over one section of memory for > a longer period of time, which will help the cache hit ratio and make > it less problematic to expand to a multi-core processor. > > Nick >
