Re: [amibroker] What is your Largest AFL file?, AmiBroker Email List Archive

Ken, I didn't read all posts in this thread, however it looks to me like you might be able to do some screening before you start scanning. Are you really interested in stocks that have volumes < 100K or that are priced below $5 (US markets)? While back testing such stocks may look good in real trading you would have a hard time getting fills and/or commissions would mess with your profits.

Also, many traditional indicators are based, derived from, the same price/chart characteristics. If one goes down so will the other. You might be able to trim the number of indicators.

Next, there are probably conditions which would result in stock rejection. Instead of scanning all stocks with all indicators you can first scan with indicators that carry more weight. Then, run more indicators with each subsequent scan.

I think that breaking up your procedure in steps, assigning weights, and reducing the number of stocks you want to process on their entire history, may make the difference between your project being feasible or infeasible.

Regarding length of code .. I have never heard anyone report a problem. Thousands of lines should not be a problem - it just loads a little slower.

A side question is this: what is the largest practical AFL file ever created that runs and is used regularly?

Obviously a hard question to answer (what is yours in terms of number of lines or number of symbols operated on). We talk about memory and multiple cores, and speed, etc, I will bet primarily in terms of optimization speed. But what about just a large number of symbols and a large number of calculations and variables? That is what my question is aimed at.

If you are wondering why this question, here is a brief background: all of my recent postings have been because I am trying to work my way towards implementation of what seems like a very large system. I want to calculate, for each and every symbol, a ranking indicator or value really. I want to use the "ordinal value" approach that I have recently been asking about. Creating these ordinal values consumes a LOT of processing time and calculations etc. I would like to do this on 1000s of symbols (maybe the entire database) but may have to settle for some subset, perhaps only in the hundreds. But that is only the first step.

After having these calculated values, I thought I would save them into the OI field of each symbol. Then, separately, I would create an elaborate rotational trading system, with a variety of parameters, and which would use the ordinal ranking parameter I had previously calculated and saved into the OI field. The rotational trading system, I am estimating, would take a lot of statements and need to keep track of a lot of information, and that would be before attempting any opimization of the trading parameters. I am guessing that the rawbacktester mode is required.

If separating the ranking calculation and saving it into the OI field is a problem (because of the interplay between local storage vs plugin access that I asked about in another message), then I could consider putting everything (I mean everything) into one humongous AFL file. Calculate ordinal rankings, keep them in their variables (by symbol) and then go right into a rotational trading routine, all in the same code file. I suspect it would either overload memory, or would take days of continual running to complete.

That is why I asked what is the largest code file you have ever made. Maybe my quest is a futile one, but I am still plowing along.

Thanks for listening.

Ken