January 30, 2016
Time for some analysis. It took 2 days to design the first productive version of the program MACDv01. Another 3 to add the improvements that generated Strategy Experiment II (MACDv02). Made some minor improvements overnight which resulted in MACDv03, the one used in Strategy Experiment III, where I ran the program once on the 10-stock portfolio, and then reported the results.
All of it was being done live and recorded as I went along.
Kind of letting others participate in the development process. Wanted to show, among other things, that it did not take much to design a profitable trading strategy that can last. With a little knowledge of programming, an understanding of what you want to do using a software package suitable for trade execution, and that is it. It should be sufficient to do exactly or better than what MACDv03 could do. No need for a Ph.D. to write what amounts to a few lines of code.
Most of the development time was spent "thinking" the how will I do this or that thing. I find programming relatively easy. My concern centers around the matter of having a concept in mind and then finding a way to translate it to code. But, even though the concept is simple – accumulate shares for the long term while trading over the process – it becomes more complicated when you want to put it to code. Because there, nothing is as vague. An equal sign will show no mercy. It has no grey areas either. It lives only on: is or not equal. It does not even have a was, a might, or a could. As Yoda would say: "Do, or, do not. There is no try." I would add: going forward there will be only one path taken. The past can only serve as a guide.
The code that came out of Strategy Experiment III is just that: code. Software routines with conditionals that do what they were told, nothing more. The important part is not the code, it is the trading philosophy behind it, the methodology you want it to convey. Once you have that pinned down, the code comes easy. The core of the program is a single do while loop. And since you were able to code all the trading rules, you can now extract them from the program and do the job manually if you so desire. At least, you know that those trading rules have shown to be profitable over the past.
What I originally wanted to show was that even if I used a technical indicator or two, the main trading philosophy would still hold. Another way of saying: using your own technical indicators, you should, in all probability, be able to do almost the same thing or better.
This program (MACDv03) came after this other program I like: DEVX8, which converted DEVX7 and its predecessors to total randomness: random-like entries, random exits, and random holds. It even has an exit procedure where a trade is considered simply lucky if eventually it finally finds an exit. A peculiar concept, a trade randomly seeking a better exit from where it profitably stood. A more elaborate description of delayed gratification can be found in the following two articles: Delayed Gratification, and Delayed Gratification II.
The primary intent of this "experiment" was to show that it could be done, meaning achieving high long-term returns using ordinary technical indicators. The basic code snippets used had for origin a simple copy and paste of some public code which was provided in Strategy Experiment I.
It is the trading rules I added that made the strategy distinctive.
I gave it directives to follow, the necessary code to translate my view of the game; the what it could do, and the how I intended it to react to price movement. Presetting its mode of operation as it tackled fluctuating price series.
There were 2 surprises in this for me.
First: how easy it all was. Some thinking, and a little programming. In all 7 days. The program has only 575 lines of code, that is not much for what it does. And most of the code was copy and paste from other routines in my code library.
Since the program is made to last. It might not require changes for years and years to come. All the work is already done. What comes next is just monitoring, waiting for the future to unfold. 20 years is about 5,000 trading days, excluding holidays, and about 7,300 calendar days. So, there will be a lot of waiting.
Second: the MACDv03 program is even better than DEVX8. An unintentional outcome. I was expecting something that would perform less than my preferred program. I now have to reconsider my preferences. Also, MACDv03 gave a few new ways to handle exits, extend holding functions, and shift average performance levels. I now have new avenues which should lead to improved portfolio performance. Those are the things I'm looking for. Software procedures that will apply most of the time to most of the stocks in the portfolio.
Overall it was an interesting and I must say worthwhile experiment. It might have given me one of my best efforts ever in the sense that I like how the program behaves, and for me that is important.
Why I'm not selling my programs.
. 1) They would be expensive. Try to put a price tag on MACDv03 with its bottom line as presented in Strategy Experiment III (see total net liquidating value in the first chart). And with the coming improvements, the strategy will do even better. Even in its present state, it could have turned a $2M stake into a portfolio valued at $272M over the 20-year period. And since it is totally scalable, it might turn $20M into $2.72B over the same time interval. MACDv03 maintained a 27.96% CAGR. Try extending the time interval to 30 or 40 years: you would get something like this: $2M*(1+0.2796)^30 = $3.26B, or $20M*(1+0.2796)^40 = $383B. Some people are afraid of big numbers, I'm not. But those, nonetheless, are the stakes.
For a smaller portfolio, since the strategy is scalable, it could theoretically turn $200k into something close to $27M. But it would turn out into a higher trading cost percentage, more stop losses executed, more opportunities lost, and reduced profitability due mostly to playing in small shares lots. A $1k trading unit will buy 20 shares of a $50 stock, and 5 shares of a $200 one. There is a minimum level at which this game should be played. And it is higher than at 5 shares at a time level.
All this to say that I don't know how to put a price on MACDv03, or DEVX8 for that matter. If you think you can help, give it a try. However, I think anyone could design something like MACDv03 within a week, just as I did. And that single concept is a mighty limiting pricing factor.
. 2) I don't want someone else mishandling my programs, misinterpreting its long-term intent, overriding its directives, trying to do things for which it was not designed, and then come back to me with: it's your &%*# program's fault. I designed it, and I know exactly what it does and will not do. But in somebody else's hands, I don't know, and I certainly would lose any control. I don't want other people to get hurt because of me, and I consider my only protection is to not give someone else the opportunity. It is the same reason I can not give it away either. The only alternative I've considered feasible was to go with the program and monitor it myself.
. 3) I write spaghetti code. I don't program clean and tidy. I don't even optimize for speed. My machines are more than fast enough. I don't indent properly as I was taught to do. I leave little in documentation or notes. I just make the code work, force it to do what I want it to do. I don't see the object of the game as having clean code or not. It is to answer the question: does it perform or not, and how long could it do this?
. 4) I just wanted to show it was possible. Presenting that it could, might entice you to investigate and find your own ways of doing it, the equivalent, or better. You now have an example that says it can be done that way. It might be a different method than yours, but then I figured you could learn new tricks given an incentive. The incentive is the end game, the bottom line.
. 5) MACDv03, for me, simply opened new doors, where more code could be added to increase performance even further, new tricks. MACDv03 is still a rough design, and now, merits more than ever to be improved upon, adding a little finesse, maybe even tidy up the code, who knows. It deserves more respect.
I would suggest anyone design their own long-term trading strategy. Keep the end game in mind. It is not a trade here and there that matters. It is your ending payoff matrix: Σ(H.*ΔP) and how big it is going to be. In math, all this is simple: A(t) = A(0)*(1+CAGR)t. And the CAGR = [(A(0)+Σ(H.*ΔP))/A(0)](1/t) -1. So your trading strategy H does matter. It is at the center of the problem.
It would take a book to describe the underlying principles involved in my methodology, the trading methods used, and expand on the reasoning behind it all. It is why I wrote: Stock Trading Strategy Mechanics. You can find it on Amazon.
All I can do here is give bits and pieces of it at a time, hoping those who follow my articles, papers, and book, will find a way to connect the dots. I don't think it is that complicated a trading strategy. I would say it is accessible to anyone wishing to build a long-term portfolio.
I find in it the making of a trading philosophy. From its long-term perspective makeup, it has the potential to rival the best long-term trading strategies out there. At least the strategy has shown it could last over a time span of 20 years, stay profitable, and not break down, even if it is a glorified Buy & Hold, although I would say with a weak hold.
Update: January 30th.
I made the observation earlier that if you raised the ante by a factor of ten, the expected outcome would also be raised by a factor of 10. In essence, the portfolio's payoff matrix, using the same trading strategy: MACDv03 would simply generate 10 more as a result of multiplying its available initial capital and trade unit by 10.
This is controlled by 2 constants in the program. All that is needed to raise the initial stake and trading unit is to add a zero to each.
For the MACDv03, as used in Strategy Experiment III, changing the two constants is easy, going from:
InitCap := 200000; // Initial Cap.
TradeUnit := 10000; // Trade Unit
InitCap := 2000000; // Initial Cap.
TradeUnit := 100000; // Trade Unit
Understandably, after having said that the outcome would be about 10 times higher, I had to do the test, just for my own satisfaction. At the same time, it would again show the strategy's scaling ability to even larger portfolios. This had been demonstrated before in other articles, but at times, there is nothing better than a more recent test. So here are the results.
#1 MACDv03 Summary Report. $20M. January 30 test.
(click chart to enlarge)
The prior test on January 25th did $272M, while this new test made $2.84B. An average 5% higher performance than the 10 times mark. About 44% of the portfolio ended in cash.
Here is the January 25th Summary Report for comparison:
#2 MACDv03 Summary Report. $200k. January 25 test.
(click chart to enlarge)
On top of having scaled better than expected. There were other interesting benefits of having increased the initial available capital and raising its corresponding trading unit. It even raised the portfolio's CAGR to 28.21%. It accumulated more shares, increased its cash reserves, and increased the average value of the inventory held.
So, I would say the strategy MACDv03 held its ground, showed its scalability. This test also demonstrates that it is superior to DEVX8. Σ(H(MACDv03).*ΔP) > Σ(H(DEVX8).*ΔP) when compared on the same basis: same stocks, same capital, and about the same duration.