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."
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.
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.
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.
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."
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.
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.
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.
One common aspect typifies almost all of the trading robots that we develop. The finished product does not exactly follow the initial design.
All programming projects proceed in one of two ways. You can either code a task from the peak to the bottom, or you can build from the bottom to the top. The former alternative represents the old way of thinking, especially within higher education. When lecturors assign a project, the conditions never change. The task remains static.
Real life hardly ever occurs like that. Instead, people change their minds. They view the product in progress and arrive at the conclusion that a small adjustment may substantially modify the outcome. The expert advisor programmer is forced to regularly habituate to the changing goal posts.
I always tell clients that they will recondition their minds about several of the rules during the project. Many stand firm that they will not. The customers do, after all, anticipate that the conditions will be correct.
Then, the rules unavoidably recondition for most of the clients. Theory falls apart in practice. The traders uncover the real problems that expert advisors face in the market.
Programmers developed a new method to harmonize with the steadily shifting rules. It's termed agile development. This pickle doesn't only occur with forex traders. It also happens to businesses constructing web sites, database coders saving information, and just about any project that involves human beings. Human beings are prone to changing their minds. It's our nature. Agile development is the programmer's acknowledgement that getting upset at customers for changing their minds is not reasonable.
The agile blueprint segments a project into time periods with an arranged list of goals. The team decides which objectives are most valuable and achievable within the established window. The period starts and everyone rushes to accomplish as much code as possible. Everyone regroups after 2-6 weeks to sort out the progress and to send the updated version to the customer.
Most expert advisor tasks only span a few weeks, so a precise carbon copy of the agile approach would not adapt very well with developing a trading robot. We chuck the strategy development method on its head by allocating graded goals with a cutoff of 1-2 business days. The goal is to aid communication, which is inevitably the most challenging obstacle in this field. We also make the method less rigid to speed things along.
The quick answers lead to a series of yes/no answers. The client either gets excited that it works correctly, or more likely, feels that we did not interpret him accurately. The authentic goal of this strategy is to get the user away from explaining the idea for the 1,000th time in the same, identical way. The last brief did not help the plan move along. Client feedback from functioning software guides the coder into comprehending the thought on his own without making the consumer believe that he's echoing himself.
I like to think of it as the client steering the driver's wheel while the programmer controls the gas pedal. The strategy development process only works when the steering and power move in synch.
Overcoming expert advisor programming challenges
When customers feel like an expert advisor has not made the desired progress, the first step is to assign goals one at a time. Too often, we receive reports with 20 different bugs. The emphasis on priority falls away as the desire to "fix everything and fix it now" drowns out the details of each request. I always like to take a step back and reaffirm our commitment to developing the strategy, but we can only handle so many issues at a time.
I have a very patient client in New Jersey (I never though I'd say "patient" and "New Jersey" in the same sentence") who ordered a lot of custom elements in a basic expert advisor. Most of the complications arose from the fact that I had to remotely access his computer with LogMeIn to do the programming. His indicator only has one license. Purchasing a second for the expert advisor programming was not economical.
The requirements to remotely access the computer and the amount of custom code turned a simple project into a complicated one. The way I addressed the issue was to remove almost all of the custom components and to replace them with code from our usual template. Now that the customer sees that the "strategy" stuff works, he found it much easier to write a checklist of bugs to fix. More importantly, seeing critical components of the code working reinforced his confidence in the company's programming ability.
Although he remained patient throughout the debugging process, I could hear the flagging confidence in his voice before we switched gears. Changing the direction of the plan showed him that the EA actually does work; it's the little pieces and how they fit together that are the problem. Of equal importance was the fact that he felt confident in my ability to deliver the results that he wants.
The consumer gets full credit for releasing control of the debugging process, even when he wasn't entirely comfortable doing so. The approach of papering over the custom steps with pre-programmed template code struck him as a step backwards. He nonetheless followed the programmer's lead, letting him drive the process with himself providing feedback where it was needed.
Both parties agree that we're once again heading in the right direction. The consumer sees obvious progress in his expert advisor. The programmer is able to manage the debugging process in a methodical, organized manner. Everyone is happy.
Realistic strategy development
The most realistic way to develop a strategy is to confess that you don't precisely know where you're going. You know it's likely to involve a certain indicator and that it either trends or ranges. The best way to get ready for the journey is to acknowledge in advance that it is indeed a journey. You more than likely will make changes, most of which you cannot expect.
It's 100% certain that something is going to go wrong when you program your first project. It's your strategy, but it's really a two-man team that builds it. Make sure to pick someone that knows what do when problems come up.
Before you select your programming partner, be sure it's someone that you genuinely trust to get the project done. You absolutely want to find someone that provides excellent communication skills and knows the importance of a timely answer. Organizing the project and overcoming unexpected challenges assists everyone get back to their true desire of trading.
The magic number is a Mt4 concept used to track the open positions of an EA. The http://www.blogger.com/img/blank.gifconcept allows the Expert advisor to distinguish the trades that it opened versus those that it did not.
Every car uses a license plate. When you see a car in a foreign state or even a foreign country, you notice that every plate that you see is unique. The police can utitlize the number to determine who owns the car.
Magic numbers act like the license plates for EA's. When an expert advisor sees an open trade, called a ticket, it frequently looks up its magic number. If the magic number of the ticket is identical to the number that the expert advisor expects, then the EA concludes that it needs to manage the position.
Magic numbers are valuable, especially when you want to trade multiple time frames of the identical currency pair. Traders repeatedly use settings that differ from those on M1 charts versus those that they would use on the day chart. If they used the Expert advisor with the identical magic number on all different time frames, the consequence would be chaos. The expert advisor would enter and exit positions with no rhyme or reason. Setting each Expert advisor to utilize an independent magic number prevents the robots from obstructing the others.
Magic number factoids
The magic number of a trade that you open yourself is 0. The value of a magic number must fall between 0 and 2147483647. The MQL programming language calls that last number EMPTY_VALUE and reserves the name as an integer value.
