|
"but why would I get "Not Responding" once I clicked on Cancel?"
The "Not responding" is added by Windows to the caption
bar and it is misleading to average person.
Every Windows application displays "not responding"
message when it is busy doing something else
than idle-waiting for UI input (in
the message loop). In that case it was busy running your loop
inside CBT code. The loop that you used is relatively slow
because it uses COM/OLE. COM calls are order(s) of magnitude
slower than plain AFL. All you needed to do is to wait
until it finishes (or press and hold SHIFT+BREAK if you want
to break the loop manually). UI action (clicking on button)
can only be handled when application
is back to idle-wait for Windows message.
The Windows architecture did not really change that much since
1990 and applications
still need to run message loops as back then, contrary to
other systems (even Amiga back in 1985 had
more modern UI processing system).
Best regards,
Tomasz Janeczko
amibroker.com
----- Original Message -----
Sent: Wednesday, July 09, 2008 6:22
PM
Subject: [amibroker] Revised Results from
a Previously Published Test on Ordinal Ranking
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
__._,_.___
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
![]()
__,_._,___
|