During the past month I have been reflecting a lot about system development and what my focus – and our focus at Asirikuy – should be going forward. After doing a lot of research – although just the tip of the iceberg – in neural networks and walk forward analysis, it seems to me that there should be a simpler, more effective and more profitable approach to system development in trading that is not only more elegant but also more systematic. From my previous developments I also knew that systematic strategy searches using genetic programming are not very prone to success, primarily because the logic space quickly becomes too big and successful combinations become both exceedingly curve fitted and “black box” type (difficult to interpret). However the answer to the above question became a lot clearer once I read the books written by Michael Harris which – although not particularly useful in practical terms in my opinion – did give me the idea that I am going to explain within the rest of this post (so it was conceptually a gold mine for me). Today you are going to learn about Kantu, a new program I have been working on (which is now fully functional) that will mark an entire new milestone in system development for me and hopefully the whole Asirikuy community. You can read more about Michael Harris’ ideas by following this link to his own blog.
So what is the problem with system development ? There are many. The biggest issue for me is that manual system development is exceedingly tedious and demands a lot of time to yield results that are often not satisfactory. Algorithmic system development can – on the other hand – be very fast and efficient but it commonly leads to exceedingly curve fitted solutions and systems with very large parameter spaces (often systems that are also cryptic, very “black box” type). In the best case manual system development can generate sound strategies that are only in a few cases significantly profitable while algorithmic system development easily falls into pitfalls that generate unsound strategies (it depends tremendously on who codes the genetic programming or neural network implementations). Manual strategy development takes a lot of human time and effort to ultimately generate perhaps a few strategies per year while algorithmic trading has the potential to generate thousands of strategies every hour, if things are done properly. Automatic system development can have the potential to be an extremely useful or dangerous tool, depending on how the software is built.
–
–
The question becomes simple: how can we build systems algorithmically without falling into any pitfalls ? How can we forget about optimizations, walk forward analysis, parameter spaces, etc while allowing a computer to build trading systems? How can we create a logic space that lacks parameters? The answer to this comes in the form of two words: Price Action. This is the path that Michael Harris has followed within the past few years with the creation of his software (Price action lab) that attempts to use different price pattern combinations in order to find profitable systems on any symbol. Harris uses only a stop-loss and a take-profit as parameters, saying that his systems are robust because they lack any potential variations on entry criteria (what he calls type-III strategies). I was intrigued by this concept when I first read about it a few months ago and therefore I decided to implement my own software for price pattern based systems but, with a large twist. This software project – to implement the creation of parameter-less price action based systems – is called Kantu.
Harris uses a family of about 100 patterns to generate his trading systems but I wanted to have something much more powerful and generic. I implemented a price pattern creation engine that uses only comparative rules between candles (for example the last candle’s high is higher than the low of the candle 5 periods in the past) and then can implement several rules for each candle. These rules are parameter-less because they are entirely comparative, this means that price patterns are created by comparisons between different points in a price chart, something that is entirely free from any parameters. There are no comparisons against any size or volatility, but just comparisons of relative points in the chart. In the software the user tells Kantu the maximum amount of bars per pattern and rules per candle that will be used and Kantu generates a random set of price patterns that have randomly assigned rules and compositions (the actual amount of rules per candle, directionality rules and candle numbers for each pattern are decided at random inside the limits defined by the user). The program then performs a back-test of each one of the generated patterns and saves the statistics only if the results are profitable, symmetric and above a given trade number threshold. Kantu also implements random slippage perturbations as well as user-defined spread levels.
Kantu also implements several options for exits, you can include an SL and TP (as Harris does), you can include an additional separate exit price action pattern or you can simply find a single pattern that can work by always being inside the market. You can generate systems with only two parameters (SL and TP) or systems that are entirely parameter-less. Kantu also has a genetic optimization engine that allows you to improve on pattern results by crossing the most successful rules/candles on each breeding cycle (plus the addition of some random mutations). This allows you to find maximums in the logic space relative to several different statistics. This can be quite handy as the logic space can grow very large as the number of parameters and rules becomes larger. Since Kantu is an independent program, I have fit it with pre-filtering criteria (such as symmetry) that allow you to prevent focusing on unreliable results during the genetic search (as MT4 does).
–
–
Perhaps the greatest thing for our community is that Kantu is able to run back-tests in a very fast manner (hundreds to thousands per minute) and that systems generated with Kantu can be directly exported into F4 framework code so that they can be implemented and back-tested using MT4 (or any other front-end that is supported) . The exporting of the system ensures that results can benefit from the F4 framework’s features and that the system can be traded in an already debugged and reliable trading framework. Kantu has also been coded using Lazarus (freepascal) and therefore it is completely cross-platform compatible (as I avoided the use of any windows specific libraries). This means that Kantu binaries will be available for Linux, allowing people who use Linux systems to also carry out system development using this platform. It is also important to note that this is just a new development front, it doesn’t mean that we will forget about NN and WFA developments within Asirikuy :o)
The first version of Kantu, as well as some introductory videos explaining its purpose, design and uses, will be available to Asirikuy members within the next few weeks. If you would like to learn more about system development and how you too can develop your own trading solutions please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading in general . I hope you enjoyed this article ! :o)
Hey Daniel,
Very interesting! This is something that I wanted to to a while back but the potential complexity kept me at a distance. So I’m really glad that you decided to invest some time in this idea!
Something that I’m finding hard to understand is the following:
What is the difference between Teyacanani that was optimized, the parameters hard-coded to give you a “parameter-less” strategy and a strategy generated by the software you wrote? The software generates a strategy from trading rules that contains parameters themselves right?
I understand you say the price action patterns are parameter free, but by combining different patterns from an engine that generates patterns you sort of have “pseudo” parameters.
Hi Franco,
Thank you for your post :o) Well, you are indeed making choices, but these choices are not parameters (there is nothing to optimize once you select a system), neither do the rules have any internally fixed parameters. This means that system performance is more robust, because there is no parameter space. Let me know if you have any more questions :o)
Best Regards,
Daniel
Hey Daniel,
Thanks for the reply :) Let me illustrate more clearly. I see the software that generates the strategy as a strategy itself. The different trading rules/logic/patterns are the parameters so to say. Get where I’m heading? Although I’m a tiny bit skeptical I’m sure it is the best we can do. It is a lot better that generating strategies the normal way
Hi Franco,
Thank you for your reply :o) Well yes, this are what we would call “parameters in the logic space” but not parameters in the regular sense we discuss (parameters in the optimization parameter space of a strategy). You are choosing what to trade from an assortment of options, but these options are completely fixed and free of optimization parameters once a choice is made. You cannot avoid to make selections in the logic space because you need to choose something to trade! The best thing you can do to minimize selection bias is to make sure that your selection has no or very limited degrees of freedom. What do you think ? Let me know,
Best Regards,
Daniel
Hi Franco,
Thank you for your post :o) I am glad you find this interesting! It was indeed complex to get things running but now that everything is coded making advances will be easy. About your question, Teyacanani uses some comparisons of the candle bodies and ranges to both the ATR and some fixed numeric factors, the patterns generated by Kanut are entirely parameter-free, there are no comparisons or operations against any coefficients at all (the rules do NOT contain any internal fixed parameters). Let me know if you have any questions :o)
Best Regards,
Daniel
Daniel wrote:
“Well yes, this are what we would call “parameters in the logic space” but not parameters in the regular sense we discuss (parameters in the optimization parameter space of a strategy). You are choosing what to trade from an assortment of options, but these options are completely fixed and free of optimization parameters once a choice is made. You cannot avoid to make selections in the logic space because you need to choose something to trade! The best thing you can do to minimize selection bias is to make sure that your selection has no or very limited degrees of freedom. What do you think ? Let me know”
I totally agree with you, although I will need to see the actual rules generated to get a better perspective. Right now I’m speaking from what I “think” the software is doing. Looking forward to using the software :) Thanks for all your hard work!
Hello Daniel,
A friend informed me about your blog. This is good work. However, I think the following statement of yours is a bit contradictory:
‘However the answer to the above question became a lot clearer once I read the books written by Michael Harris which – although not particularly useful in practical terms in my opinion – did give me the idea that I am going to explain within the rest of this post (so it was conceptually a gold mine for me). ‘
These books are out-of-print by the way but from what I have read from your post, it appears that your algorithm works along the lines explicitly described in one of my books. So how can they be ‘not particularly useful’ and at the same time ‘conceptually a gold mine’?
Regardless, I wish you good luck with your new project and thanks for the mention.
Michael
Hi Michael,
Thank you for your post :o) It’s very good to have your comment here. I meant ‘not particularly useful’ in the sense that the books didn’t actually give me technical tools to achieve what I wanted – the implementation discussed in this post – but they did, as you mentioned, provide me with the concepts to implement these ideas myself. So I am sorry if my statement was ambiguous, I meant that while the books didn’t provide me with the explicit implementations, they did provide me with important concepts (conceptually a gold mine). Thanks again for commenting Michael and for the very good ideas you have shared through your books,
Best Regards,
Daniel
Hi Daniel,
I understand what you mean but book publishers do not like technical details and they impose limitations. It would be impossible to provide technical details in a book targeting a large audience.
I think your work is on the right track. I will comment about the “not feasible solution space” problem below.
Thanks again for mentioning my work and good luck to you.
Hi Michael,
Thank you for your reply :o) Yes, I understand what you mean as well. Although I have never written a book for a publisher I can imagine how publishers want the content to be “simpler” to appeal to a larger number of people. That said it’s a shame that the books fall “technically short” for those of us interested in reviewing some implementations. However the books do achieve their purpose – communicating your ideas – and therefore they are a good read for anyone interested in the concepts behind price action trading. Concepts are always more valuable. I hope you’ll keep coming back to read how this project evolves (as your input and comments are always very valuable). Thanks again for your post and good wishes Michael,
Best Regards,
Daniel
Hi Daniel,
Great job with the new implementation. I too wandered along a very similar path last Summer attempting to code a C based Candlestick Pattern genetic framework. Like Franco, the complexity was overwhelming to me and so instead I spent some time coding a proof of concept in MT4 where every conceivable candle relationship could be defined in a few dozen parameters. Using the MT4 GA engine thousands of combinations were tested, however, this is where I encountered a problem that ultimately forced me to shelve the idea. By randomly generating ‘higher than’, ‘lower than’ relationships between the OHLC of multiple candles, it is possible to arrive at completely impossible, ‘Escher-esque’ patterns (eg. Close of candle 1 is higher than close of candle 2, the close of candle 2 is higher than candle 3, but the close of candle 3 is higher than candle 1). In fact, it turned out there are vastly more of these impossible combinations than feasible ones, and so my prototype spent most of its time generating and testing these rather than finding profitable patterns (although it still did find some).
I’d be really keen to know if Kanut also suffers from this problem, or if you found some clever way around it!!
Best regards,
Sam
Hi there-
An important part of the algorithm that I developed had to do with “conflict resolution” to rule out not feasible solutions in advance and before going into backtesting mode and wasting time. It took me about 3 years working with one or two programmers at a time, about 3 times a week to come up with a solution that worked without hanging up the CPU with infinite loops, wasting a lot of memory, etc. This is a more involved part than configuring the patterns with OHLC and operators like or even = that I also used. You also need constraints on the pattern formations that lead to feasible solutions whether you are using a GP engine or a permutation scheme. It is not hard to do that but it takes some time.
All the best-
Correction for: ‘operators like or even = that I also used.’
Apparently the system does not accept greater than and less than symbols or I don’t know how to do it properly. The above sentence should read:
‘operators like greater than, less than, or even = that I also used.’
Hi Michael,
It’s really very interesting to hear the effort it took to develop your solution, although it doesn’t surprise me. I spent countless weeks trying to figure out a ‘conflict resolution’ algorithm and just ended up tying myself into knots so it makes me feel a little less incompetent knowing it took you 3 years and 2 programmers to find a workaround to this. For this reason, I’m especially curious to know if Daniel also found a solution and if so how he went about it.
Best,
Sam
Hi Sam,
You’ll definitely enjoy the post about my solution to this problem (it’s actually quite simple!). Thanks again for posting!
Best Regards,
Daniel
Fantastic! My instincts told me there must be some elegant way of doing it – so can’t wait to find out what is!
Hi Sam,
Thank you for your comment :o) I am glad you liked this implementation, it seems that many of us were actually on the same page since at least another 3 members (including Franco and you) had been working on this problem at some point. I have to say that the problem did seem quite complex at first but thankfully I was able to come up with some good coding solutions that made things a lot easier (freepascal is also a great language to do things like this, fast and yet not as complicated as C can be). The best decision was to implement this as an independent program as I first thought about doing it as you did (implementing an MT4 proof of concept) but after my prior experience with genetic programming on MT4 it did seem like a bad decision overall due to the lack of flexibility in MT4 optimizations and the general slowness of the back-tester.
About the elimination of conflicting rules within patterns, I actually implemented a function to do this – eliminating the Escher factor – something which I am going to dedicate a post to (as I really like how it turned out). Thank you very much again for writing Sam,
Best Regards,
Daniel
Daniel
Wow you can work fast. Thanks for the belated Christmas present (I assume this is the one you mentioned several posts back). I’m sure Michael Harris is very happy that someone has so publicly used one of his ideas.
Cheers
Rod
Hi Rodney-
Yes I’m happy because most have used my ideas secretly and they have never acknowledged reading my books although I know that they have because I used to get a buyer list.:)
Acknowledging the work of others like Daniel has done in my case is a sign of higher intelligence AFAIK.
Hi Rod,
Thank you for your post :o) Surprisingly this is not the Christmas present! So there are still some surprises on the way. Thanks again for commenting,
Best Regards,
Daniel
This looks very nice. Particularly the fact that the tool will work on linux, so I’ll be able to play a bit.
This remembers me the called equation-free modeling.
Best. Santiago
Hi Santiago,
I am glad you like how it looks :o) Definitely using Linux is a big advantage! The F4 framework is also cross platform compliant so someday we will be able to do trading only from Linux (so better to start developing tools for that!). Thanks for commenting,
Best Regards,
Daniel
OMG this is incredible work!!!
Daniel, congratulations – I read every word of this article with massively wide open eyes!
Had an idea – So you’ve done the entry logic very generically; very nice.. What if we also applied the exact same thing to the exit logic generation? ie. genetically figure out the best exit logic for the genetically found entry logic. I think it would increase the complexity by log(n) if you only do the exit logic genetic search on systems with entry logics that actually generate profitable results.
LOVE how the investment in the F4 framework is paying off!!!
Hi Mun,
Thank you for your comment and nice words about my work :o) About the exit logic, it’s already being generated via the same procedure as the entry logic. It is also important to remember that trades are also exited on opposite entry signals so you have actually two ways of exiting a trade (either via the exit pattern or a reverse signal from the entry pattern). As a matter of fact you can generate systems that use only one pattern and are always in the market (which can give some good results as well!). I am also glad that the investment in the F4 framework is paying off, we have definitely spent a lot of time and effort on this framework so it’s good to see how it’s evolving and leading to new algorithmic trading developments. Thanks again for posting!
Best regards,
Daniel
Hi Daniel,
nice tool to play with :)
But I’m very skeptical Kantu will do better than Runakuna. “Price action” as defined here translates to candle stick trading for me (with somewhat relaxed rules). But I fail to see why this approach does not suffer from the same problems as any other heuristic approach. Can you please point out the particular differences?
I also do not buy into Michael Harris’ arguments where he tries to proof that some parameter sets found using this method have a very low chance to be found just because of randomness (comparing a t-distributed variable with a 2-modal distribution will give you a very low p-value just by design). If this “proof” led you to dig further into this approach, please think again.
Another question is how tolerant the definition is when run on 2 broker feeds. As I understand it, it will be very feed dependent, unless you use some interval around the prices: if prices do not differ more than this interval, it can’t be decided which price is higher or lower.
Please proof me wrong (I know you will at least try it ;) ), but I think this approach will not yield better results than Coatl or Runakuna.
My view is: the causes why price moves are not directly observable. Even the prices you observe have to be treated as measured with error (as 2 brokers will most likely report different prices at the same time – who is right?). Thus you have to describe price action in a suitable way – neither too loose nor to strict. I think price field based rules tend to be too strict, while indicator based rules give too much degrees of freedom (you can generate a ton of very different price movements that will all give the same indicator value).
But the important point is: regardless whether this approach shows some merit or not, we will be glad to have found out about for sure. Thx for your enthusiasm and your work!
Best regards,
Fd
Hi Fd,
As always thank you for your post :o) I agree with several of the things you have pointed out. I know that there is no fundamental proof of why this technique might be better than Coatl or Runakuna (I didn’t try this because of the analysis offered by Michael). I implemented it mainly to be able to come up with systems that have less degrees of freedom and to be able to test how these systems behave in real trading against systems generated using other techniques. As always I try to keep my options open so I will walk this path along with the others we are working on (Neural networks, walk forward analysis, etc). Another reason why I implemented it is because this way I can overcome the limitations of the MT4 strategy tester so although the technique might not turn out to be fundamentally superior to other genetic approaches the implementation is indeed much more powerful. The implementation in itself – its larger freedom in the logic space and faster simulations – may lead to better solutions than Coatl and Runakuna, simply because its easier to find them (for example the algorithm I use to avoid testing of unreliable patterns, in MT4 you simply have to test everything because the strategy tester cannot implement any pre-filtering of parameters).
There are also some other curious things I have observed with systems created in this manner. For example I have observed that the systems are very robust regarding broker dependency – little variation between historical feeds – and even robust against aleatory distortions in the feed (done through the program). It is also worth noting that this is hugely due to the weekly arbitrary thresholds used in F4, if I remove this thresholds broker dependency becomes abysmal (two feeds are entirely different). Therefore this cutoffs to create matches in information between feeds are fundamental, at least in this case.
My hope, as you mention, is to be able to test this approach and find by experimentation whether it has less or more merit than the other ones we are exploring. Thanks again for posting Fd :o)
Best Regards,
Daniel
Fd- you wrote:
<>
I’m not aware of any application of bimodal distributions to trading systems although I’m far from a stat expert. Could you elaborate on what you mean? Thanks – Rick
Hi Rick,
if you have fixed SL and TP levels, you will have 2 peaks in returns, thus your return distribution is bimodal. However statistics is mostly dealing with unimodal distributions. Furthermore, many statistical test assume a normal distribution. If you want to gauge whether the returns from a specific parameter set are unusual good/bad or to be expected, you will first have to define what is “normal”. If your definition of “normality” does not comply with a Gauss distribution, a test which compares against the Gauss hypothesis will always result in the judgment “very unlikely”. Obviously, this will always happen with this kind of exit logic, giving you in fact no additional information.
@Michael Harris: at least this is what I understood from your web pages. If I’m wrong here it would be great if you could outline your analysis in some more greater detail.
Best regards,
Fd
Hi FD, you said ‘if you have fixed SL and TP levels, you will have 2 peaks in returns…’
I think when SL and TP are set as percent of entry they are not fixed but depend on order price. If series returns are nearly normally distributed so are the returns from SL and TP in percent, most probably that is. I looked at Harris’s pages and nowhere he claims you have to fix the SL and PT in dollar terms although he mentions that as an option for futures because of rollover adjustments.
Hi Rick,
just download the returns file from the proof page and do a frequency plot (can be done easily in Excel), then you’ll clearly see sl/tp with fixed pips were used.
Best regards,
Fd
Hi FD,
Which proof page do you mean? I have no idea of what you’re talking about.
The page I’m referring to is http://www.priceactionlab.com/Literature/bootstrap/bootstrap.html.
FD,
Thanks for the link. I now see what you mean. I had a quick look and it appears is a p-value of a bootstrap. The bootstrap distribution is for the means and it is always normal by virtue of law of large numbers. It doesn’t look like he finds the p-value of a bimodal but that of a bootstrapped distribution of means. It would be silly to do that since the distribution isn’t known anyway. These are non-parametric statistics as they assume no distribution of returns but I think the assumption is i.i.d.
@Fd, @Rick
Thank you guys for reminind me about that page. That was an older test as you may see from the QQQQ symbol that was changed to long ago to QQQ. @Fd is correct in that the distribution of returns is bi-modal for fixed exits but this test does not depend on the specific distribution of returns anyways. In addition, this is not any ‘proof’ of significance but only says that there is some evidence against the null hypothesis. A more important test is the out-of-sample performance and an even more important one is a forward test. The software I have developed can also do portfolio backtests which are much more conservative. At the end, no test can guarantee future performance.
I have updated the page with recent data: http://www.priceactionlab.com/Literature/bootstrap/bootstrap.html
Thanks again and good luck to all. Daniel is on the right track.
And another bug (now in the recent full windows version):
I open a data file, enter the parameters of the data, but when I want to load the inputs it says: selected history file does not exist. Please check path to be valid
What is wrong here? The path definitely exists!
Hi Eddi,
Thanks for writing. The path might be too long or it might contain some illegal characters in Pascal (for example if your language contains some non-standard characters). Try installing the software and datafiles in C:\OpenKantu and see if this solves your issues,
Best Regards,
Daniel