Hi,
I've done a lot of reading, but have only been live trading for 2 years. There are far more experienced contributors to this forum than me.
That being said, my background is in computer science, and I've been a software developer for almost 20 years. That has allowed me a certain level of comfort with much of what AmiBroker has to offer. Though, my usage has been primarily coding in AFL. I do very little charting other than to show price and entry/exit points.
As far as trading goes; I run an exploration every night on end of day data. My strategy has had success identifying a generic scenario that averages a modest return per trade after a short holding period.
As such, I apply the exploration over all U.S. stocks in hopes of maximizing the actual number of signals. I generate anywhere from a handful to 200 signals on any given night. Fewer during down trends, more during sideways and up trends.
I use limit orders below the market, so only a fraction of my orders ever get filled. However, I still end up with several hundred trades per year. The holding period generally ranges from overnight to 10 days on the outside, usually closer to 3-5 days. I exit at market open the morning after a sell signal generated from the night before.
My exploration generates a format very close to what is required by Interactive Brokers basket orders. I export the exploration results as .csv file, load them into Excel, apply a custom macro to further refine the format, give it a quick looking over as a sanity check, then upload the basket order to Interactive Brokers and submit it. Eventually I hope to do all of this directly from AmiBroker using the Interactive Brokers plugin. I just haven't gotten around to it.
As far as analysis goes; The strategy uses a combination of indicators and liquidity filters to isolate the symbols of interest. In a nutshell, I'm looking for stocks that are upwardly trending in the long term, but have very recently been beaten down, in expectation that the price drop is an over reaction and will recover somewhat over the next few days. It is not necessary that the price fully recover, just a quick pop of a few percent.
I use custom backtesting code to apply money management and dynamic position sizing. The custom backtesting code also produces custom metrics, one of which is based on ulcer performance index multiplied by a number of weighted factors relating to drawdown, hold time and number of trades. This is used as the target for walk forward optimization.
I have done walk forward analysis (WFA) dating back from 1995 to the present. Along with a number of optimization parameters, I have also tested with different money management schemes and exit times (e.g. exit on close vs. next day).
I have experimented with in sample (IS) window periods ranging from 3 years to 3 months, and out of sample (OOS) window periods ranging from 1 month to 1 year. A 24 month IS and 6 month OOS were the most consistent for me in conjunction with a money management policy of taking as many trades as possible, not to exceed a fixed fraction of equity on any given trade, dipping into margin as necessary.
The ratio of OOS/IS turns out to be 0.25 which is consistent with Robert Pardo in "The Evaluation and Optimization of Trading Strategies", though that was not a specific goal in my analysis. I plan to perform further WFA using a wider variety of money management schemes, including more on the theories of Ralph Vince as per his "The Handbook of Portfolio Mathematics" as well as Van Tharp as per his "Definitive Guide to Position Sizing".
I have spent some time attempting to validate my results as more than blind chance via random entries and random exits as per Howard Bandy "Quantitative Trading Systems" as well as some limited analysis using Minitab. I've done a first pass at applying my signals to detrended data as per David Aronson in "Evidence Based Technical Analysis", but have more work to do there.
Prior to the introduction of non exhaustive optimizers such as CMA-ES, Tribes, etc. I spent some time experimenting with the Taguchi Method in an attempt to minimize variance in my returns and identify those parameters that most contributed to the desired results. By using fractional factorial arrays of parameter values, I was able to reduce the number of combinations that needed to be backtested (i.e. non exhaustive). The primary drawback being that fractional factorial arrays obscure interactions between parameters. I did not follow the approach through to a tidy conclusion. But, it was interesting.
Due to the nature of my strategy (thousands of symbols, foreign reference, several optimization variables, custom backtest code, etc.) individual backtests have proven very time consuming on an entry level laptop, leading to the purchase of far more powerful equipment. Still, the processing demands are currently the limiting factor to deeper analysis. That and my own limited free time.
My hope is that Tomasz will come out with a very low priced "server edition" of AmiBroker that consists only of the backtesting engine, without any GUI, such that dozens of licences can be purchased and deployed on a compute grid rented for pennies by the hour (think Amazon EC2 but running Windows, e.g. GoGrid). I've got my own incomplete application that could drive such a setup. Fred's IO is an example of the concept running on a limited number of servers on a LAN.
Grid Computing has already arrived. All that remains is to leverage it! If I ever finish my application, I'll pass it on to Tomasz to see if he's interested in the grid approach :)
Sorry if this post is longer than you expected. I've had a number of personal email exchanges with members of the forum, regarding their approaches and coding experiences, and have found them to be interesting and educational. For that reason, I figured I'd offer you a complete answer, since you asked ;)
For those lurking in the background, feel free to hit delete! Or, better yet, add a description of your own usage pattern to the thread.
Mike
--- In
amibroker@xxxxxxxxxxxxxxx, Brian Smith <besmith70@xxx> wrote:
>
> Hey Mike,
>
> Care to mention how you use Amibroker for analysis and trading?
> Have been really impressed by your level of knowledge in general...
>
> Regards.
>
>
>
> > --- In
amibroker@xxxxxxxxxxxxxxx <amibroker%
40yahoogroups.com>,
> > "brian_z111" <brian_z111@> wrote:
> > >
> > > You are doing a very good job Mike.
> > >
> > > --- In
amibroker@xxxxxxxxxxxxxxx <amibroker%
40yahoogroups.com>, "Mike"
> > <sfclimbers@> wrote:
> > > >
> > > > 1. It's a program to allow you to manage a "batch" of "jobs" where a
> > job is defined as an AmiBroker operation such as a backtest, exploration or
> > scan, and a batch is a collection of jobs to be run.
> > > >
> > > > 2. It is not that running batch files is particularly important. But,
> > it may be useful if you find yourself repeatedly wanting to run a series of
> > jobs and you don't want to hang around waiting for each to finish before
> > firing off the next one.
> > > >
> > > > You can download the program from the Files section of this site. It
> > includes a user guide that may help clarify its usage. I haven't personally
> > made use of it, so cannot offer much more than that by way of description.
> > > >
> > > > Relating to your earlier thread, Batman does highlight yet another
> > advantage of AmiBroker over other backtesters; AmiBroker is exposed as an
> > OLE object and thus can be driven externally using COM from any other
> > language (e.g. C++, Java, JScript, etc).
> > > >
> > > > Mike
> > > >
> > > > --- In
amibroker@xxxxxxxxxxxxxxx <amibroker%
40yahoogroups.com>,
> > "caternore" <caternore@> wrote:
> > > > >
> > > > > Mike,
> > > > >
> > > > > This may sound stupid, but I have 2 questions
> > > > >
> > > > > 1)what is a batch manager?
> > > > >
> > > > > 2)why is running batch files important?
> > > > >
> > > > > Thank you
> > > > > ACE
> > > > >
> > > > >
> > > > > --- In
amibroker@xxxxxxxxxxxxxxx <amibroker%
40yahoogroups.com>,
> > "Mike" <sfclimbers@> wrote:
> > > > > >
> > > > > > 1. Batman is a batch manager for running batch files. It is
> > available in the files section of this group.
> > > > > >
> > > > > > 2. I believe that it is still an issue. I believe that it means
> > that the categorization of symbols is limited to a tree of depth 2 rather
> > than the 4 actually available from ICB (
> >
http://www.icbenchmark.com/icb_structure.html). Unless you're trying to
> > run a strategy against the less refined granularity, it should not be an
> > issue. Even so, you could probably create a watchlist and add all the
> > symbols from the more refined categorizations into it, thereby creating, in
> > effect, the less granular categorization.
> > > > > >
> > > > > > 3. I believe that this is still an issue. Easy workaround as
> > described by Norgate in the blurb provided.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > --- In
amibroker@xxxxxxxxxxxxxxx <amibroker%
40yahoogroups.com>,
> > "caternore" <caternore@> wrote:
> > > > > > >
> > > > > > > Hello all again, I have some more question after doing some
> > research.
> > > > > > >
> > > > > > > 1) What is Batman
> > > > > > >
> > > > > > > 2 )I was looking at the Norgate data site when I came across
> > this.
> > > > > > > (Unfortunately as AmiBroker only supports two levels of
> > classifications we've decided (after a quick user poll) to provide ICB
> > levels 3 & 4 only.)
> > > > > > >
> > > > > > > What does this mean and have this issue been resolved?
> > > > > > >
> > > > > > > 3) Another question from the Norgate Data site.
> > > > > > >
> > > > > > > (Why does the volume on the S&P 500, S&P 1500, NASDAQ Composite,
> > NYSE Composite, and weekly charts of ASX Indices sometimes show as a
> > negative number?
> > > > > > >
> > > > > > > By design, AmiBroker stores volume data internally in a data
> > structure known as a 32 bit signed integer. This data structure can store
> > whole numbers in the range of -2,147,483,648 through 2,147,483,647. If the
> > volume figure exceeds the maximum figure, an "overflow" condition occurs and
> > the volume wraps around to a negative number. For example, the NYSE
> > Composite index had a volume of 3,745,144,031 on Friday 3 May 2008 which
> > significantly exceeds the amount. This is why negative volume is shown on
> > days of very high volume in those few high-volume indexes.
> > > > > > > A workaround is available inside AmiBroker, allowing you to
> > divide the volume by a factor. To implement this click File -> Database
> > Settings then click the Configure button. In the "Divide Volume By" field
> > enter a number (eg. 10 or 100 or 1000 - right now 10 seems to be effective
> > across all the US markets for the time being).
> > > > > > > A better solution would be for AmiBroker to use a bigger or
> > better data structure (eg. 64 bit unsigned integer) or a floating point
> > field to accommodate such high volumes. If you would like this to be
> > implemented within AmiBroker please login to the AmiBroker Feedback Center.
> > After logging in then click here to show issues #636 and add a comment
> > requesting a permanent solution to the issue.)
> > > > > > >
> > > > > > > Has this been resolved?
> > > > > > >
> > > > > > > Thank you.
> > > > > > > ACE
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>