I am embarrassed to report that a previous message of mine, reporting times of execution of two methods of ranking ordinal values was incorrect. This message is to correct the key detail and explain why the conclusion reached was not right. As background, a series of previous messages referred to ranking symbols in a Watchlist by the ranked ordinal values of various indicators, and using the sum of the ranked ordinals at a combo rank. Paul Ho offered two code approaches, not detailed in this message but seen in past messages. Approach 1, I have been calling the n^2 approach because of the supposed inefficient sorting of the ordinals and the execution time penalties which would be experienced when processing Watchlists with larger numbers of symbols. Approach 2 we will call the custom backtest approach, in which the built-in ranking capability of the backtester is used to rank or sort the symbols by the appropriate indicator; Paul's code (extension he says of Tomasz code example) will then sum the indicator ordinals and write this sum to the OI field (or alternatively to an external file using command lines in the code which have been commented out.) In my message at http://finance.groups.yahoo.com/group/amibroker/message/126512 (which by the way contains the backtester code of Approach 2, but has one missing end bracket at the end), I reported on stupendous time of execution differences between Approach 1 and Approach 2. Specifically I said that running 426 symbols from 12/31/2002 to 7/5/2008 (I actually did not report the date range but this is a critical element), took 7 min 25 sec for Approach 1 and 1 min 42 sec for Approach 2---a stunning difference. Well, I did not test apples to apples and so the timing comparison is false. There is a statement in the Approach 2 code which is SetOption( "MaxOpenPositions", 50 ); //AB only keeps 2* maxpos top
This line of code controls (in a way I do not understand) how many symbols are ranked. Thus, it must be set to one half of the number of symbols in the Watchlist you are testing. Thus, my test of a 426 symbol Watchlist really only ranked 100 of those symbols. A clue was that when I examined the OI field using a simple explore to print the OI field to the AA results window, I found a number of them were zero, thus unranked. I ignored these because I thought (incorrectly) that the list was still sorted in the correct order. My bad--too major mistakes in the same message; how can you believe this one. This morning I have repeated the test but alas, it did not go to completion. I set the MaxOpenPositions to 216 to go with the 426 member watchlist and the optimization never completed. I stopwatched it but when times before the first optimization run box appeared exceeded 8 minutes, I clicked Cancel only to get the dreaded "Not Responding" message. I did this three times with the same result. I decreased the MaxOpenPositions to 100 (double the original 50), thus saying it would rank 200 symbols instead of the 426 in the list. This time the dialog box (signaling the end of the first pass of the optimization statement) appeared at 3 min 50 sec and the total run took 7 min 34 seconds, virtually identical to the Approach 1 timing, but with an incomplete ranking set. Finally, perhaps I did not wait long enough for the processing to complete (but why would I get "Not Responding" once I clicked on Cancel?) but I do not think so. Perhaps I did not have enough memory (I have 3052 Mb RAM), or some other factor is involved. Nonetheless, my apologies for publishing incorrect data. I hope this addendum has added to the pool of knowledge and has helped some of you out. I certainly would like to hear any comments, questions, or reactions. Ken
