Wednesday, April 25, 2012
Recall that Martingale systems aim to never lose money. Instead of accepting losses and moving on, a Martingale betting strategy doubles the previous bet. Whenever a win finally does happen, all losses up until that point are regained. The trade also gains the same amount of profit that the original trade hoped to capture.
Trading forex with a Martingale money management system will almost inevitably lead to blowing up an account. I've written about this inevitable outcome repeatedly over the past six months. At the risk of beating a dead horse, I figured that visual proof would relieve any lingering hopes once and for all.
The goal of the exercise is to focus on the risk of ruin rather than the profits acquired. As time goes on, the likelihood of ruin goes up with the number of trades placed. A trade is each time a new transaction enters. It does not matter whether or not the last trade was a winner or a loser.
Fifty trades on most Martingale systems corresponds to anything from several days to several weeks. The level of aggression used in the trade level (i.e., the pip distance used to open a new trade) is what most strongly affects the amount of time required to reach fifty trades.
Placing 50 trades shows what most traders know. The returns look fairly nice at that point. A return of 20% on the account shows a 40% probability of occurring. The risk of wiping out the account looks meek at 8.5%.
Increasing the number of trades to 200, which corresponds to several weeks or months, the odds of outright failure skyrocket to 35%. The lucky traders that have not yet blown up show returns ranging from 20% all the way to 300%. The total risk is more apparent, although many traders fall victim to the lure of quick, large returns. If it all looks too easy at this point in time, that's because it is.
Going out to 1,000 trades, which I roughly ballpark as the amount of trades an average expert advisor might complete in 9 months to a year, is where the inevitable result is obvious. The odds of reaching a zero balance reach 95%. A tiny handful of traders are floating huge returns. As the number of trades increases from 1,000 to 2,000 to 10,000, the tiny fraction of accounts left eventually dwindles down to zero.
The test assumes that the trader uses fixed fractional money management set at 1% of the account value. Recall from earlier experiments that a 1% risk value will almost never ruin an account after 200 trades. The percent accuracy for the trades remains at 50%, which is perfectly random. The random number file has been upgraded to include 10 million random numbers instead of the previous half a million.
Monday, April 23, 2012
Fiber projects compete for transatlantic speed
A few weeks ago I wrote about Project Express, a new fiber-optic cable being built across the Atlantic that will give a select number of high-frequency traders a tiny speed advantage in trading times between New York and London. Currently, data take 64 milliseconds (give or take a few fractions of an eye blink) to travel round-trip between New York and London along a cable built in 1998 called the AC-1.
http://www.businessweek.com/articles/2012-04-23/high-speed-trading-my-laser-is-faster-than-your-laser
http://www.businessweek.com/articles/2012-03-29/trading-at-the-speed-of-light
http://www.bloomberg.com/news/2012-03-29/cable-across-atlantic-aims-to-save-traders-milliseconds.html
http://www.businessweek.com/articles/2012-04-23/high-speed-trading-my-laser-is-faster-than-your-laser
http://www.businessweek.com/articles/2012-03-29/trading-at-the-speed-of-light
In April, the Canadian research ship Coriolis II will set out from Halifax to survey parts of the continental shelf stretching 1,000 miles off the east coast of Nova Scotia.
The ship has been hired by Hibernia Atlantic, a Summit, New Jersey-based company that operates undersea telecom cables, to map out a new $300 million trans-Atlantic fiber-optic line called Project Express. The cable will stretch 3,000 miles beneath the North Atlantic, connecting financial markets in London and New York at record transmission speeds. A small group of U.S. and European high-speed trading firms will pay steep fees to use the cable.
http://www.bloomberg.com/news/2012-03-29/cable-across-atlantic-aims-to-save-traders-milliseconds.html
Thursday, April 12, 2012
Fixed Fractional Money Management
Trading totally at random with a 50% winning percentage and an R multiple of 1 yields no advantage, as I discussed last week in modeling money management. Remember that an R multiple is the average win to the average loss. Such a system poses neither an advantage or disadvantage. The average outcome should come out extremely close to the starting balance.
Most traders focus on risking a set dollar amount such as $1,000 on a given trade. Fixed fractional money management updates that dollar figure after every single trade. It changes the overall outcome after you add up all the winners and all of the losers. Remember that trading is the net outcome of several hundred trades or even thousands of trades. The power of money management comes into play as the number of trades increases.
Fixed fractional money management stretches some portions of the bell curve and compresses other regions. Before we get into that, it's important to remember what fixed fractional money management means. It stands for the idea of risking a set percentage of the current account equity rather than the starting equity.
Consider an example where the account balance starts at $100,000 risking 1%. Both methods risk the same amount on the first trade, $1,000. The next trade, however, will yield a different risk amount. A win on the previous trade would increase the account equity to $101,000. One percent of a 101 grand is $1,010 of risk on the next trade. A whopping ten dollar change.
That may seem trivial. It is most certainly not over the long run.
Examples
Consider a trader that plays the coin toss game and has a system with the following characteristics:
He starts with a $100, 000 account balance
His R multiple is 1.0
He wins 50% of the time with no trading costs
He risks 1%
The absolute worst outcome of playing the coin toss with a fixed dollar risk of $1,000 is a loss of $46,000. Adding fixed fractional money management during that difficult drawdown improves the drawdown to a less substantial loss of $37,500. The worst drawdown goes from -46% to -37.5%. The method drags the absolute worst case scenario and pulls it closer to the average. When an unlucky, devastating drawdown kicks in, the technique reduces the losses that the trader experiences.
The best case scenario for fixed dollar risk is a $58,000 (58%) return. Adding money management to the system dramatically stretches the best case scenario further to the right. It improves to a $76,000 return (76%). The good times get a lot better without changing anything at all about the trading system. The method stretches positive returns away from the average. The trader walks away with more money in his pocket.
The natural instinct is to conclude that fixed fractional money management is the way to go. I agree. It improves the risk reward profile of a totally random strategy. Adding it to a real trading system should help control parameters that most traders consider critical like drawdowns and maximizing the return.
An important consequence of using fixed fractional money management, however, is that the odds of receiving a below average return increase somewhat. The coin toss game suffered a below average return 47% of the time. Applying fixed fractional money management increased the likelihood of a below average return to 53%. The effect is not all that much. Losing is more likely. But when it happens, the "loss" is so negligible that it can be thought of as breaking even.
Random numbers occasionally follow a seemingly non-random pattern such as loss-win-loss-win. When this occurs, the size of the trade on the losses is bigger than the trade size of the winners. Even if the winning percentage comes out at precisely 50%, those wins get slightly overshadowed by the losers. That micro effect of slightly larger losses than gains shows up as a slightly increased risk of not making as much money as expected.
Graphing all outcomes
Red areas represent the losing outcomes while green areas represent the winners. Money management is really about maximizing the ratio of green area to red area. Random trades with no expectation of profit yield a bell curve, which appears on the left.
Fixed fractional moves the highest density of returns slightly to the left. Doing so creates the trivial disadvantage of a slightly increased risk of negligible loss. Importantly, the far left side (the worst case loser) gets dragged much closer to the average. The far right side (the best case winner), gets stretched much further from the average. The goal is to make the green area larger than the red area to where we actually expect a profit.
Wednesday, April 11, 2012
JPM accidentally moves markets
Market-moving trades by JPMorgan Chase & Co. (JPM) (JPM)’s chief investment office probably will force regulators to seek more detail on banks’ derivatives positions to help them distinguish risk management from speculation.
Bruno Iksil, a London-based trader in the unit, has built derivatives positions linked to corporate credit that are so big he’s moved markets, according to hedge fund managers and dealers. While Joe Evangelisti, a bank spokesman, said yesterday that the trades are part of the firm’s hedging strategy, four market participants said they resemble proprietary bets, or wagers with the lender’s own money.
http://www.businessweek.com/news/2012-04-09/jpmorgan-s-iksil-seen-spurring-regulators-to-dissect-trading
Monday, April 2, 2012
Money Management Modeling
We recently developed software to model the affects of random chance on money management. Although computers are capable of producing pseudo-random numbers, the pseudo-random procedure introduces bias into the random distribution.
We determined to source our random numbers from random.org. The web site obtains purely random streams of bits taken from atmospheric noise. We then use binary mathematics to change those bits into numbers ranging from 1-10,000. Say, for example, that we want to model a trading system with a winning percentage of 50%. Whenever a number comes out between 1-5,000, we consider that a winner. Anything above 5,000 marks a loser.
Modifying the winning percentage to 65% works the same way. Any number less than 6,500 represents a winning trade. Numbers above 6,500 signal a loss. The modeling quality is accurate to the thousandth decimal place. That type of accuracy is way more accurate than the "known" accuracy of your trading system, which can only be known within a few whole percentage points.
Most traders fall into the trap of thinking about their trades as individual outcomes. The more necessary way to view returns is as the sum of all individual outcomes. Losing on any given trade does not matter. It only matters whether the sum of all your winners is greater than all of the losers.
It gets more complicated, unfortunately. A system with 50% wins and a 1:1 payout will almost never come out at exactly breakeven. The mathematical expectation is that we expect to see a degree of drift in the returns solely due to random chance. I suggest reading more in the random trade outcomes and dollar profits section to get a better understanding of drift.
Lastly, we must delimit a sampling period for evaluating the final result. I arbitrarily set the default value to 200. That means that the software tells us the range of outcomes after 200 total trades. That may take more than a year for some traders. Daytraders may reach that benchmark in several weeks of trading. The question that we are answering is "what is my account balance likely to be after placing 200 trades?"
Coin Toss Trading Experiment
The first experiment is to analyze how dollar returns vary with a coin toss game and the most basic money management method. A starting balance of $100,000 is used with a risk of 1%. The risk will not change as in the fixed fractional method. Instead, we will leave the lots fixed in order to strictly understand random chance. Wins always earn $1,000. Losses always lose $1,000. The odds of a coin toss are 50% wins with 50% losses and a 1:1 reward risk ratio.
The average trade comes out to $99,868.36, almost exactly $100,000. It's what we expect for a 50-50 game with a 1:1 reward risk ratio. What I find interesting is the standard deviation of $14,377 and how it changes. I don't want to cover scary math topics. The layman's explanation is that the standard deviation is the "normal" range from the average that you might expect. The $100,000 balance, in most cases, would either lose $14,000 or make $14,000.
Everything beyond those standard deviation boundaries represent the less likely wild scenarios. The minimum outcome comes out to $58,o00, a massive 42% loss. This had a 0.54% chance of occuring. The maximum outcome shows as $158,000, a monster 58% return. This had an even smaller chance of occurring, only 0.1% (1 in every 1,000 trials).
Changing the account risk dramatically affects the standard deviation. 1% strikes most traders as sane and reasonable. Yet, there is a small chance of losing half the account to drawdown strictly because of terrible luck. Decreasing the overall risk by a fourth to 0.25% drops the standard deviation by exactly one fourth. The worst case scenario shrinks to a highly tolerable $11,500 drawdown (11.5%). Most traders would find a number between 10%-20% reasonable. The consequence of the reduced risk is that the best case scenario drops correspondingly down to a 14.5% gain.
Stretching the risk out to 2%, a normal industry practice, turns out to be risking accounting suicide with the coin toss game. The worst case scenario drops the final account balance down to $8,000, a staggering 92% loss.
The goal is to help you define risk from a gut feeling matter into something more tangible and calculated. Too many traders enter the market day dreaming about profits. Risk enters the picture, but too few traders actually understand the relationship between risk and reward. Hopefully, the picture of best, worst and average scenarios is starting to become more clear for you.
Sunday, April 1, 2012
Forticlient Lite Internet Security
FortiClient Lite is a free endpoint protection suite that includes malware/virus detection, parental web control, and VPN. Malware is detected using updated threat intelligence and definitions from Fortinet's FortiGuard Labs. Parental control offers a simple and effective way to block malicious and explicit web sites. Single VPN configuration allows quick and easy secure, remote access via IPSec or SSL protocols. FortiClient Lite leverages FortiClient's Antivirus technology, developed in-house by Fortinet. FortiClient Antivirus has achieved more than twenty VB100 awards and is capable of detecting threats on both a reactive and proactive basis. Proactive detection is based on detecting zero-day malware that has never been seen before in the wild.
http://www.forticlient.com/lite.html
Contact EES for Forticlient Premium or other Fortinet products such as firewalls.
http://www.forticlient.com/lite.html
Contact EES for Forticlient Premium or other Fortinet products such as firewalls.
Tuesday, March 27, 2012
Gas rising, homes at 10 year lows
The housing market started off the new year with a thud. Home prices dropped for the fifth consecutive month in January, reaching their lowest point since the end of 2002.
The average home sold in that month lost 0.8% of its value, compared with a month earlier, and prices were down 3.8% from 12 months earlier, according to the S&P/Case-Shiller home price index of 20 major markets.
Home prices have fallen a whopping 34.4% from the peak set in July, 2006.
"Despite some positive economic signs, home prices continued to drop," said David Blitzer, spokesman for S&P. "Eight cities -- Atlanta, Chicago, Cleveland, Las Vegas, New York, Portland, Seattle and Tampa -- made new lows."
Gas prices to rise all summer
Friday, March 23, 2012
SEC goes after high frequency trading firms
The Securities and Exchange Commission has reportedly set its sights on the often-mysterious world of high-frequency trading, questioning whether these sophisticated traders' cozy relationship with exchanges gives them an unfair advantage.
According to The Wall Street Journal, the SEC probe is zeroing in on the computer-driven trading platforms of exchanges, including BATS Global Markets, which ironically is debuting as a public company on Friday just as the news breaks.
High-frequency trading firms, which tend to avoid the limelight, have come into focus in the wake of the May 2010 “flash crash,” which featured a brief 1,000-point plunge on the Dow after glitches in computer-trading systems. These traders use advanced and powerful computer systems to rapidly execute trades, often ahead of most other investors.
Read more: http://www.foxbusiness.com/industries/2012/03/23/report-sec-probing-high-frequency-trading-firms/#ixzz1pwwFt3cL
Tuesday, March 20, 2012
Sweden moving towards cashless economy
Sweden moving towards cashless economy
Vicar Johan Tyrberg in the Carl Gustaf Church in Karlshamn, southern Sweden, on Sept 7, 2011, stands next to a credit card machine enabling worshippers to donate money to the church collection without carrying money in their pockets. (AP Photo/Camilla Lindskog)
(AP) STOCKHOLM - Sweden was the first European country to introduce bank notes in 1661. Now it's come farther than most on the path toward getting rid of them.
"I can't see why we should be printing bank notes at all anymore," says Bjoern Ulvaeus, former member of 1970's pop group ABBA, and a vocal proponent for a world without cash.
The contours of such a society are starting to take shape in this high-tech nation, frustrating those who prefer coins and bills over digital money.
Sound Dollar Act of 2012
http://www.opencongress.org/bill/112-h4180/show
H.R.4180 - Sound Dollar Act of 2012
To amend the Federal Reserve Act to improve the functioning and transparency of the Board of Governors of the Federal Reserve System and the Federal Open Market Committee, and for other purposes.
Greeks turn to barter during crisis
http://www.guardian.co.uk/world/2012/mar/16/greece-on-breadline-cashless-currency
There's some dispute about where and when it all started, but Christos Kamenides, genial professor of agricultural marketing at the University of Thessaloniki, is pretty confident he and his students have made sure it's not about to stop any time soon.
What's sure is that the so-called potato movement, through which thousands of tonnes of potatoes and other agricultural produce – including, hopefully, next month, Easter lamb – are being sold directly to consumers by their producers, is taking off across Greece.
"It's because everyone benefits," said Kamenides, standing in a clearing in the woods above Thessaloniki in front of one 25-tonne truck of potatoes, another of onions, and smaller vans of rice and olives. "Consumers gets good-quality food for a third of the price they would normally pay, and the producers get their money straight away."
Wednesday, March 14, 2012
Random Trailing Limit
I got the idea for a trailing limit from Van Tharpe's market classic Trade Your Way to Financial Freedom. I had Jon Rackley read through the book as part of his training when I first hired him. He brought my attention to an abnormal claim made in the middle of the book. Van Tharpe says that it's repeatedly possible to make money even with random numbers.
The book states that trading with totally random entries and a 3 ATR trailing stop regularly leads to making profits. Flip a coin. You buy if it lands on heads. Go short if it lands on tails. One important note is that we elected to incorporate pure random numbers in our programming instead of the pseudo-random numbers that coding languages generate. Doing this allows us to avoid time biases in the seeding process that repeatedly pop up when the seeds applied are close together in time.
Random numbers are a hobby of mine. I've continuously put effort into figuring out whether I could develop a strategy that trades totally at random and still makes profits. As the owner of a programming company for traders, and as part of Jon's early training for NinjaTrader in December, I assigned him the task of programming the blueprint into code.
The first functioning version that I inspected exhibited everything contrary to Van Tharpe's assertions. Using a trailing stop, regardless of the instrument and period tested, inevitably led to devastating losses. The profit factors usually came in near 0.7, a truly terrible number.
We did what most of our clients do when they find abysmal strategies. We flipped the strategy on its head. The new strategy uses only a 3 ATR (50 period) trailing limit.
Trailing Limit Analysis
The early conclusion is that trailing limits appear to offer a great deal of potential. Although Jon sent me the code several months ago, it's only this evening that I had a chance to properly review and test everything.
The profit factors are very encouraging. It depends on the chart that I tested. The worst that I found was a 1.0 profit factor. Everything else came out with profit factors greater than 1. The small table below contains the initial test results. Before you go off salivating that this is the next hot winner, there are a few considerations to keep in mind:
- The results depend entirely on the sequence of random numbers used. Using different sets of random numbers will cause different outcomes.
- The better results on the higher time frames likely result from sampling error. The number of trades involved was only ~160, which is not enough to make definitive conclusions on the nature of the performance. I prefer to see 400 or more trades before drawing definitive conclusions.
- These results do not include spread costs or commissions.
Currency | Period | Profit Factor | Dates Tested |
EURUSD | M1 | 1.12 | 9/12/2011-3/12/2012 |
GBPUSD | M1 | 1.16 | 9/12/2011-3/12/2012 |
USDJPY | M1 | 1.25 | 9/12/2011-3/12/2012 |
EURUSD | M5 | 1.11 | 2011 |
GBPUSD | M5 | 1.0 | 2011 |
USDJPY | M5 | 1.06 | 2011 |
EURUSD | H1 | 1.26 | 2011 |
GBPUSD | H1 | 1.25 | 2011 |
USDJPY | H1 | 1.48 | 2011 |
What made me feel better about the results was reviewing the entry and exit efficiencies of each strategy. The number of trades involved really cluttered the graphic. I ran a backtest on a much shorter time period so that the horizontal, blue line would appear clearly on each graph.
The entry efficiency tells us exactly what we would expect to find. Trades which enter at random do not produce better than random (obviously). What's fascinating is how the trailing limit exit strategy actually skews the entry efficiencies to read slightly worse than random. This is a good example of why it's hazardous to rely purely on statistics. Keeping the big picture in mind minimizes the likelihood of making an erroneous conclusion, in this case that there might be something "wrong" with our absolutely random entries.
Adding Money Management
The percentage of winners for the tested charts ranges from 60-67% accuracy. High percentages of winners generally lead to winning streaks. My cursory glance through the chart led to my easily finding a suitable example to cherry pick. Here, 5 trades consecutively reach their near maximum limit orders.Testing that I've done in the past tells me that it's frequently advantageous to increase the position size based on consecutive winners when a strategy is more than 50% accurate. My first idea after studying the initial results was to modify the forex money management strategy to pursue the consecutive winners.
While increasing the risk after consecutive winners works out statistically in your favor, it does add to the risk. It's entirely likely for a "winning" set of trades to start losing based solely on the money management strategy. There's no way to know whether your set of trades will be the lucky beneficiary of the extra risk or whether it will be the unlikely loser.
Sunday, March 11, 2012
Forex Trading officially surpasses $5 Trillion per day mark
Forex Trading officially surpasses $5 Trillion per day mark
http://www.bloomberg.com/news/2012-03-11/currency-trading-at-5-trillion-a-day-surpassed-pre-lehman-high-bis-says.html
Currency trading may have risen to a record $5 trillion a day in September, surpassing the peak reached before Lehman Brothers (LEHMQ) Holdings Inc.’s collapse in 2008, according to theBank for International Settlements.
http://www.bloomberg.com/news/2012-03-11/currency-trading-at-5-trillion-a-day-surpassed-pre-lehman-high-bis-says.html
Currency trading may have risen to a record $5 trillion a day in September, surpassing the peak reached before Lehman Brothers (LEHMQ) Holdings Inc.’s collapse in 2008, according to theBank for International Settlements.
Password Manager
A secure, single click password manager. Roboform is also great for filling out forms, with it's built in form-filler with multiple identities. Roboform online backup, browser embedding, and other features make it far more useful than it's free alternatives.
Download EES Password Manager Roboform
Download EES Password Manager Roboform
Tuesday, March 6, 2012
Fixing bugs in MQL4
MQL is a really simple scripting language. Debugging MQL, unfortunately, is not simple at all. The MetaEditor compiler that MetaQuotes provides simply does not incorporate the advanced tools that most coders are familiar with using.
MQL bug fixing problems
Visual Studio and other sophisticated IDEs (integrated development environments) incorporate a number of offerings that make it simple to fix code while the http://www.blogger.com/img/blank.gifprogrammer writes it. The best example of this are break points. A break point is a site in the code where the compiler informs the computer to stop executing the code when it arrives at that stipulated line.
Take the example where a trailing stop implements a new stop inaccurately. The normal instinct for most programmers would be to run the expert advisor on the visual backtester, then introduce break points on the sections of code immediately after the trailing stop calculations. Break points block the code, allowing the coder to scan inside the brains of the software to see what it thought at the time it made a decision. The key advantage in Visual Studio is that the values of all of the variables are clearly visible. It is possible to walk through the program step by step. Whenever one of the steps does not follow the desired rules, the necessary modification is usually obvious. MetaQuotes thankfully included break points in MQL5. They are not available in MQL4.
The lack of full intellisense support affects my programming speed more than anything. Intellisense observes the use of reserved words like OrderSelect() or ObjectGet(). The MetaEditor includes a basic intellisense, but it lacks the fine details that make it so convenient in Visual Studio.
I am used to programming in C# where I can type the first few letters of a variable or class, then the IDE fills out the rest. When I type "Mes" in C# and push the space bar, I know that the MessageBox option will show up (assuming that I declared the required namespace). The MetaEditor includes a list of options for reserved words. The programmer must then either pick the option with the mouse or push enter.
I know it seems trivial to require pushing enter in lieu of the space bar, but think about how many times code resuses the same reserved words or variables. The extra presses of keys really do add up to a lot of unnecessary typing motions. That's doubly true for a thirty year old that already wears a wrist brace for carpal tunnel pain.
The MetaEditor's biggest weakness is that it does not see variable names. We often write EAs that incorporate several thousand lines of code. Tracking the names of tens of variables poses its own challenges. When the coder types in the same set of variable names repeatedly, it would be nice to simply type the first three letters and move on. Copy and paste might provide a decent alternative. The problem is that variables usually group together. You cannot keep 5 different copy and paste items readily available.
The MetaEditor allows functions to return invalid types. Functions declared as double can return strings, integers or nothing at all. The MQL4 compiler does not track whether or not these are valid. It leaves it up to the coder to discover the invalid type during real time testing. This oversight is a nightmare for the unwitting programmer that mistakenly returns the wrong type.
This is even more true when a double function is erroneously returned to an integer variable. MQL4 does not prevent illegal double to int casts. Even worse, the expert advisor continues running with a 0 value for the interger instead of throwing an exception or error message. I cannot count how many hours that I've wasted tracking down variables that look accurate, only to realize that I declared the wrong data type. This usually happens when I'm on autopilot, pounding out code. What seems efficient at the time commonly costs several hours of hair pulling frustration.
MQL troubleshooting techniques
The MQL programmers on staff here usually resort to any of the following techniques. You may find that testing them in groups helps with improving the bug fixing process even more.
Debug compiler error
This one can be the most frustrating. The MetaEditor attempts to hint at which line of code causes the compiling error. I say attempts because it gets it wrong more often than it gets it right. There's nothing more irritating than looking at a perfectly legitimate line of code that the compiler flags as problematic.
I almost always resort to commenting out more and more large blocks of the expert advisor until the issue disappears. I begin with commenting out a single line of code. If that doesn't work, then I comment out ten lines. If that doesn't work, I might comment out whole functions or sections of code. When the compiler finally runs properly, you know that the last section of commented out code comprises the bug.
Next, you work backwards. Start with making the offending commented-out section smaller and smaller until the error comes back. Now, you have finally zeroed in on the actual source of the problem.
Debug in real time or on the backtester
My favored manner of bug fixing is to comment most of the relevant decision information onto the screen, which is done using the Comment() function. I then run the visual backtester, watching how the data behaves in relation to the visual information.
On screen comments are essentially jury-rigged break points. Controlling how and when they appear allows the coder to step through the code to uncover the issue. The only difference is that comments do not forcefully prevent the code from running. The text which appears is very small. Aside from that, I really like that fact that it's so robust. The comment function always works without a hitch, making it the best friend of a coder that's troubleshooting code.
Taking screenshots takes this to the next level. Whenever consumers ask questions about why an expert advisor behaved a certain way, the easiest answers come with screenshots. Commenting the imitation break points usually provide bullet proof answers - the coder and client can actually see what the Ea thought at the time it made a decision. MQL4 offers the WindowScreenShot() function to do this.
The Expert advisors that we program always take screenshots during pivotal actions, such as entering a trade or modifying an exit condition. The goal is to provide a visual account of every decision with an eye to answering future inquiries about the action.
Our default template includes a true/false variable called WriteScreenshots. Traders control whether they want to bother with this bug fixing feature or not. The only downside to it is that every recorded action eats up about 50kb of hard drive space.
Log files offer the last bug fixing option. The major drawback is that they are so ugly and burdensome to read. I almost always prefer screenshots for this reason.
Nonetheless, log files do have their place. The main way to use them is as error catchers. Whenever a course of action goes awry due to a problem with either MetaTrader itself or with a broker transaction, the log file is the easiest place to catch it.
Bug fixing MQL files is a skill that takes awhile to learn. The methods at the programmer's disposal are very different from those available to higher level languages. Once you get accustomed to working with the much more basic tools in the MetaEditor and MetaTrader, the bug fixing process goes a lot quicker.
Labels:
comment,
debug,
debugging,
log,
metaeditor,
mql,
screen shot
Subscribe to:
Posts (Atom)