Users' Knowledge Base

DRAFT – SUBJECT TO SUBSTANTIAL REVISION

OBJECTIVE

The objective for this tutorial is to show how to copy a Word document into Windows Live Writer (WLW) for uploading to the Users’ Knowledge Base (UKB).

INTRODUCTION

Copying Word documents into WLW  provides Authors with an additional option, and a user friendly way, for contributing to the UKB. It is recommended for those who have an archive of articles already written in Word or who prefer the familiarity of Word. It is also suitable for those who want to use the superior editing features that Word offers over Blog Editors. It is also useful for those who work collaboratively and want to use features like comments and revision tracking. Another benefit is that it provides a stable, and familiar local back-up. It is a method that does not have a long learning curve.

PREPARATION

It is recommended that the Word document to be copied has been written according to the guidelines at: Quick Posting Example – Word Attachment . The document should consist only of text, with basic formatting, images, tables, hyperlinks and AFL formulas. Tables need to have been converted to an image.

CONVERT

Copy and paste the document into WLW

1) Open a New post in WLW.

2) Enter a Title for the post.

3) Open the Word document that is to be copied.

4)

AFL formulas – add markers (plain text in AB pref)

TO BE CONTINUED

Filed by brian_z at 1:46 am under Using Blog Editors
Comments Off on Converting Word Documents Into Posts

The design of real-time automated trading systems involves two major design phases: 1) Designing the trading system and 2) Developing the trade-automation code. While you may be able to re-use some previously developed AT functions, you can rarely transport the entire automation section from one trading system to the next. Adjusting your AT code to work with a new system can be very time consuming; it can involve weeks of real-time testing and debugging. Using the code below you can test your new system ideas, in a tick environment, before you have written a single line of automation code.

Note that when testing this code with the Bar-Replay tool, the log will display the bar’s closing price instead of the Lastprice (tick data). When testing this code with your own trading system, you may want to add extra output to the _TRACE() statements. The code below substitutes DebugView output for orders that would have normally gone to the TWS:

Filed by Herman at 7:17 pm under Debugging AFL
Comments Off on Order Simulation using DebugView

When you are designing a real-time trading system, many things can go wrong. This post is intended to alert you to some of the potential pitfalls. However, that is all it can do. Only experience can teach you how to prevent them. Be aware that even the most experienced designers will make some of these mistakes repeatedly.

Since documenting all potential pitfalls with coding examples would consume too much time and space, they are, for now, only briefly commented on. Most of them will trigger a user response of “Oh yeah, that happened to me!”. If you need a more detailed explanation you can post questions in a comment to this post

No rules exist to prove that a trading system is free from coding or logical errors. However, two indicators are fairly reliable in suggesting you may have a problem:

1) Your profits are simply too good to be true. In this case you have no choice but to work through the code line by line, trying to find lines of code that look into the future. If that doesn’t reveal any errors, then you would have to inspect the plotted signals and trade list trade by trade.
2) Your system is very profitable trading Long but not Short, or Short buy not Long. When this happens, you may have an error in either the Long or Short parts of your code, and comparing the two sections will often reveal the problem (this only works for reversal systems). However, it could also be that your code is correct but that your trading principle is overly trend sensitive. This would almost certainly get you in trouble when the trend reverses. In this case no other cure exists than to re-think the basic system.

When designing high-frequency trading systems, i.e., those whose trade durations are in minutes, everything changes, and many traditional procedures fall apart. Internet delays, data delays, bad data (spikes), temporary system freezes (Windows sometimes has a mind of its own!), lagging status reports, TWS problems, etc., all become critical issues that will prevent you from obtaining a close match with the Backtester.

Many of these problems will only surface when you start trading real money. Hence, the final stages of developing a trading system should always involve trading real money. Here is where the Interactive Brokers account simulator (paper-trading account) may be an indispensable tool since you can test your system in real time without committing real dollars. But, since the market does not see your trades, even paper-trading results will differ from trading real money. In general, the faster you trade, the greater your real-trading results will deviate from your backtest results. You should also be aware that commissions play a much greater role on performance of high-frequency trading systems because trade profits are smaller.

No matter how you go about it, troubleshooting a complex trading system will almost always be a tedious and boring job that could keep you busy for several days or weeks. If you find that certain problems continue to resurface, they are likely related to your personal development style, and you may be able to write some code that checks for these specific problems. See the Debugging category for some ideas.

The list below, which is not exhaustive, is presented to caution you that many areas can lead to problems. Some are obvious, while others may be expanded on as needed and time allows.

– High/Low precedence (contrary to EOD where the Backtester is unable to determine which came first, the entry/exit or the high/low, in realtime there can be no ambiguity in price precedence).
– Data Delays (real-time data may be delayed for various reasons and time periods (Internet delays, lack of quotes, packets vs. ticks, etc.).
– Low Liquidity (there may be no-volume trading periods).
– Data Holes (bars with no trades).
– Data Spikes (high spikes without volume may trigger trades).
– Data Padding (a bar without data may be padded).
– Premature Padding (the last bar may be a padded bar).
– Data Accuracy (prices you receive aren’t always accurate).
– Random Slippage (you will rarely get the expected price).
– Breakout slippage (you will rarely get the Breakout price of your system).
– Survivorship Bias (companies that didn’t do well and stopped trading won’t be in your database, i.e., you are working above average stocks).
– Lucky Trades (a series of lucky trades may look like good performance).
– Parameter Over-Optimizing (optimized parameters are rarely stable over time).
– Design Over-Optimizing (frequent testing is like running an optimization and may be leading to false conclusions).
– Out–of-Bound Prices (with PriceBoundChecking turned ON, AmiBroker forces the trade price within the High-Low range, this may hide pricing errors).
– Price Rounding (prices may be rounded or truncated by the broker).
– Wrong Use of >= and <= (when using both <= and >= in the same statement, only the first equal condition will ever be seen).
– Comparing Floating Point Numbers (calculated values can have many decimal places, either round values or use the AlmostEqual()).
– Chart Justification (make sure you are looking at the Last bar!).
– System Mortality (no system will work forever).
– Sharing Trading Systems (sharing systems with other traders may result in over-trading a system).
– Being Duped by a Trend (a rallying ticker may make your system look like the HG (holy grail).
– Tricking AmiBroker (AmiBroker has its limits; it is possible to write esoteric code that will produce wrong results).
– Order Visibility (placing your order for every trader to see may influence the orders they place).
– Making the Market (extreme example: if you place a MKT order during a no-trading period you will change the chart).
– Window/Pane Execution Order (when passing variables between panes or windows do not assume that they execute in a fixed order, more).
– Trading at the Open (order execution at the start/end of day is different from midday because of volatility and data delays).
– IB Data Snap Shots (snapshots are only representative of prices traded).
– Trade Delays (make sure you understand your trade delays when backtesting).
– EOD and Intraday Gaps (There is no time interval in RT gaps).
– Time Zones (make sure your computer and database timezones are properly set).
– Very Short Time-Frames (prices jump and are less contiguous).
– Setting LMT Prices (consider rounding for faster order executions).
– 24-Hour vs. RTH (Regular Trading Hour) Backtesting (extended hours can rarely be traded like RTH due to huge bid/ask spreads and low volume).
– Static Variables Naming (use unique names for your static variables).
– Incorrect Computer Time (computer time offset from market time can cause real problems).
– Look-Ahead Problems (not all look-ahead coding problems are obvious).
– Buy/Sell Precedence in a Loop (be aware that AB and custom AFL loops enforce a Buy/Sell priority).
– RT Candle Discrepancies (RT Candles may be different from later backfills, especially in the opening print).
– Bars Loaded (consider bars-loaded with respect to execution speed and loops).
– Signal lifetime (signal strength quickly decays over bars in high frequency trading).
– SameBarExits (Sell signals may act as a qualifier for Buy signals).
– Designing systems based on High and Low triggers (these may fill in the Backtester but not in real trading). more…
– Using the wrong CommissionMode and/or CommissionAmount can make any system look good, or bad…
– Using zero TradeDelays is OK if you code the delays in your system’s code, else you may be looking into the future.

Edited by Al Venosa

Filed by Herman at 6:25 pm under Real-Time System Design
Comments Off on System-Design Pitfalls

In real-time trading many situations arise when you want to delay action until a specific criterion is met. In AmiBroker you can base your delays in many different ways, the only requirement being that the delay variable increments or decrements. If the selected variable doesn’t revert towards your timeout value (target), your delay function would never time out. In this case you would have to add code to handle that condition. A few variables you might use are:

– RT TimeNumber (Now(4)).
– Elapsed Seconds (redrawaction).
– Real-time Data time-stamp (TimeNum()).
– Tick-count (New Data).
– Volume (Change in Volume).
– Price change (Change in Price).
– Chart Refresh (any AFL Execution).
– Indicator values.

Which of the above variables you would use for your delay depends on the requirements of your trading system. There may be times when you may need to combine several methods to get the required results. For example, if a delay were based on the data-timestamp, it might not time out during a data dropout or a no-trading period. In this case you need to back up your data-timestamp delay with a real-time (seconds) delay.

Delays play a critical role in real-time system design. For example, in real-time systems, signals may have a short lifetime. The signal is strongest when it triggers and than quickly decays until, perhaps after a few bars, it has lost all significance. Letting the order fill at the time when it has lost significance is pure gambling. To prevent this, you can cancel the order after a delay, or decrease the position size proportional to the perceived decay in signal strength (perhaps based on elapsed bars?)

Since in a real-time system the time-lapse between AFL executions can be significant, you should place your LMT price calculations ahead of the ordering code. Calculating the LMT price after the order has been placed postpones order placement until the next AFL execution occurs, i.e., when the next quote arrives; by then, the price has probably changed. Especially during periods of low volume, this could be significant. When these delays would be insignificant in EOD systems, they could make-or-break your system in fast-trading systems.

To ensure frequent AFL execution in the absence of quotes, you can place a RequestTimedRefresh(1) statement at the top of your code, where the variable ‘1’ refers to a 1-second refresh. This guarantees an AFL execution at least once per second.

If your code is lengthy and takes a significant amount of time to execute, you may have to check order status at several places in your code. If changed status demands immediate action, you can force an immediate AFL execution by calling the following function:

Filed by Herman at 5:12 pm under Real-Time AFL Programming
Comments Off on Real-Time Delays

Filed by brian_z at 1:14 am under Using Blog Editors
1 Comment

The AmiBroker Programming Language (AFL) is a very unique and powerful programming language but to use it effectively you have to understand how it works and how to properly use the AFL functions. For the newcomer to programming, this may represent a steep learning curve and it may take a little persistence to find the answers to all your questions. To write documentation on any topic that leaves no questions unanswered is an impossible task, all help documentation assumes a minimum level of familiarity with the topic studied. The problem is that this prerequisite minimum level of understanding is set by the subjective judgment of the author. The results is that, for the individual user, some topics are covered excessively while others are skimmed over because the author assumed that everybody is basically familiar with the topic. Users on the other hand often assume that their lack of knowledge is shared by all beginners and, if the Help file inadequately explains something, claim that the documentation is badly written. Of course their view is just as relative and subjective as those of the author.

This situation exist in various degrees in all documentation and cannot be prevented. The way for you to cope with this is to stay calm (there have been some heated posts on the lists) and do your own research research. If you still can’t understand something and/or can’t find the answer to your specific question you can email AmiBroker Technical Support for help or post your question on one of the AmiBroker forums:

Amibroker Users’ Group
AmiBroker Automated-Trading
AmiBroker Trading Systems
AmiBroker AFL

There are some other Yahoo forums you may want to look at, especially if you are multilingual. For a more general search targeting groups in any language click here.

If you believe your question is of general interest you can ask your question using the comment field below. But please be specific; questions like ‘How do I use AFL’ would require a book to answer and is way beyond the scope of what volunteers can contribute.

Of course we welcome your solutions to specific AFL problems, either as an author with a post (requires registration) in this category, or in the comment field below.

Filed by Herman at 1:49 pm under AFL - The Basics
Comments Off on Introduction to AFL

Over a period of years you may have designed and tested hundreds of trading ideas, some may have worked a little, some were traded for awhile, and some you chucked in the waste basket. While in the end you have one or two good systems to trade, you have spend thousands of hours in development time with very little to show for it: Hundreds of system ideas are either totally lost or are tucked deep into some database where they can’t be listed by trading idea or trading principle.

This topic discusses how you can manage your research, work, and ideas to create a valuable system development resource.

… under development …

You are invited to contribute to this topic as an author with a post (requires registration) or in the comment field below.

Filed by Herman at 11:16 am under System Management
Comments Off on Introduction to Trading Systems – Management

If at all possible ask your questions in a comment to a closely related post, that way it will be read by someone who knows the topic and who is most likely able to answer your question. Note that some categories have introductory posts that are especially created to provide you with an easy way to ask questions. If you cannot find a related topic you can ask your question in a comment to this post.

Please use the same method when suggesting new topics or categories. If no related topics can be found you can suggest your topic in a comment to this post.

Filed by Herman at 11:28 pm under Readers
5 Comments

To help you put my posts in perspective I will tell you a little about the systems I like to work on and how I prefer to trade.

Developing trading systems is just a hobby for me; I am neither a professional trader nor a professional programmer. I enjoy coding more than trading and don’t trade very much. If/when I trade, it is mostly to test some new system idea. For as long as I can remember, all the way back to my MetaStock days, I have worked with one or more partners; it motivates me to find solutions, offers stimulating discussions, and facilitates problem solving. There is a definite benefit to working as a team; diversified skills and views stimulate innovation and facilitate problem solving, I highly recommend it.

Over the years my approach to system design has changed many times; this year I worked on short-term systems with trades lasting 1-2 bars. I prefer systems that work in all timeframes, from daily bars down to about 3-minute bars.

I am a contrarian trader: I always design systems that trade against price movement. This allows me to use LMT orders exclusively, which are waiting at the market when the signal triggers. This eliminates slippage, an important factor to control in high-frequency trading. Another reason for trading LMT orders is that this is the best and perhaps the only way to obtain a close match between Backtested and Real-Trading results. I may exit on a Profit Target or Pattern Failure but never on Maximum Loss Stop. If maximum loss stops are needed, I feel that my trading system isn’t working right, requiring me to go back to the drawing board. I believe that, if you can design an entry rule, you should be able to design an exit rule.

I prefer trading portfolios or scanning the market. If you can develop a system that trades a pattern giving you nice performance but producing only 3% annual profits with 3% exposure, you may be able to increase performance 20-fold or more by scanning the market. This is where real-time trade automation gives you the edge.

In brief, here are some typical patterns that I have looked at:

1. Rare events that usually result in a correction. This would include sudden extreme price movements (for example, a spike with volume). In the daily chart capture shown below, I would aim to buy on the retrace from the low, and exit on a target or pattern failure.

2. Two- to three-bar patterns that are usually followed by a correction. This would be a slower version of the above; for example, a price move over 1 to 3 1-minute bars that retraces over a longer period. Here I would try to design the system to go Short when the pattern reverses after the long bar, and take a profit a few bars later. Long bars are worth a bit study…

3. Use one of the popular band indicators and trade at saturation levels, i.e., buy when the price touches the bottom band and sell when it touches the upper band. The chart pattern below is an example using Percent bands (Minutes). Here I would try to design the system to go Short where the High crosses the Upper Band and take a profit a few bars later.

I prefer very simple trading rules that can be coded with a few lines of code and that do not contain any optimizable parameters. Of course, even though the trading rules may be simple, this doesn’t mean the final code is simple. By the time that real-time and automation features have been added, the code can easily run into hundreds of lines of code.

Manually trading a real-time stock portfolio is serious work and can be stressful. I am retired, so I am averse to serious work, stress, or drawdowns. For me to trade a system, it must meet these criteria:

– Trade a portfolio of stocks.
– Run fully automated and unattended.
– Return at least 100%/year.
– Perform equally well Long or Short.
– Have drawdowns of less than 2%.
– Trade only Intraday without overnight positions.

I haven’t reached these goals yet, so I keep coding :-) Difficulties in meeting these criteria appear mostly due to automation problems and not so much to problems in system design. Trading fast trend-insensitive systems, eliminates or mitigates the need to follow the markets and gives me more time to develop systems, work on the UKB, or do other things.

The AmiBroker/IBc combo offers all the essential functions to implement a true trading machine, i.e., a fully automated trading system that runs unattended in the corner your office.

Happy Trading,
Herman van den Bergen (retired from trading January 31, 2012)

Edited by Al Venosa

Filed by Herman at 1:00 am under ~~ Author Profiles
Comments Off on Herman

This category is reserved for real working trading systems, i.e. that you have traded at some point in time or would consider trading. Since the criteria for tradability varies from person to person, and since systems may work or not depending on how they are traded, it will be difficult to screen contributions here. With respect to what is posted here, keep an open mind and consider that the poster considers the system tradable.

You can contribute by posting as an author (requires registration) or in a comment to this post.

Filed by Herman at 11:14 am under Practical (Profitable)
Comments Off on Introduction to Trading Systems – Practical