Trading in the FX market using mechanical trading strategies

OpenKantu: The first free and open source price action based trading system generator

Through the past two years at Asirikuy we have developed a substantial amount of knowledge in the generation, evaluation and live trading of automatically generated trading strategies. The first of our software development efforts in this field, Kantu, has now become deprecated within our community (see why below) and I have therefore decided to release this code into the open community in order to avoid wasting all this work and instead encourage others to also explore the possibilities of algorithmic system generation using an already built open framework.

Kantu is a trading system generator that creates trading strategies based on price-action derived rules (comparison of different open/high/low/close values) using OHLC data. Using it you can search for strategies within a selected logic space, finding those that match the statistical characteristics imposed by the user (for example you can search for systems which have a given Sharpe, reward to risk ratio, winning percentage, etc). You can see how the program looks on the image below:

–

–

These are the main characteristics of the software:

This and all future versions of OpenKantu will be available for free with fully open source code :o)

Coded in FreePascal/Lazarus , full source code available under the GPL v2 license.

Manual included.

Includes expert advisor (RecordBars_MT4) to export data from MT4 into a csv that can be used by OpenKantu

Multi-platform support. Precompiled binaries available for Windows but the software can be compiled from source on Windows, Linux and MacOSX.

Fast simulations, a 25 year test using daily data takes only 3 milliseconds while a 25 year 1H test can take around 60-80 milliseconds. This allows you to perform millions of tests within a realistic amount of time.

Multi-core support, you can perform tests using as many computer cores as your computer allows

Configure the system creation process to search systems with or without SL/TP within a set rule complexity (maximum shift, maximum rule number, etc)

Configure an out-of-sample window if this is desired

You can search for strategies on any financial instrument.

Filter systems using the pre-built statistics or a custom built filtering rule

Get trade-by-trade system results

Simulate portfolios made up of different generated systems

Get a mathematical expectancy analysis (MAE-MFE) for long/short trades for all generated systems

Get balance graphs with trade results showing on an OHLC graph of the data (see where the system has traded)

Export generated strategies to MT4

I would also like to point out that OpenKantu is NOT a holy grail generator and that use of the program without a good understanding of potential sources of bias (curve-fitting bias, data-mining bias) is bound to lead to losing strategies in forward/live trading. Remember that past performance is never a guarantee of future results. Although OpenKantu is coded in good faith end users are responsible for all uses of the software. The software is provided as-is, with no guarantees, implicit or implied. OpenKantu is also provided without any support, please refer to the manual for instructions on how to use the software. You can download windows binaries and the program’s source files by using the following links:

notes on building from source: If building from source make sure you install Lazarus, then install the synapse and ZMSQL packages included within the github repository before attempting to build the software. If you would like to make code contributions please contact me (leave a comment on this page) and we’ll coordinate so that you can contribute on github. All contributions that improve the software for the open community are welcome.

Remember that to reproduce the same testing results obtained in OpenKantu on MT4 simulations you need to use the exact same data within the generation process and the MT4 backtesting. Along the same lines your live/demo broker’s GMT, DST and weekly opening/closing times need to exactly match those of the data used within the generation process. Using different data leads to unpredictable changes in simulation results between the programs.

You may wonder why we decided to discard use of Kantu within our community (given all the above positive characteristics) we decided to move to pKantu as it has many advantages over our initial Kantu (now OpenKantu) implementation. With pKantu we have the following features:

Coded in OpenCL/Python with speed as the top priority

Explicit evaluation of the entire logic space (openKantu uses random sampling instead which can lead to important issues when attempting to evaluate some sources of statistical bias)

Extremely fast simulations using GPUs, around 100-1000x faster than OpenKantu

Evaluation of data mining bias using automatic random data generation

Community cloud mining implementation that allows us to sum up all our system creation and bias evaluation efforts

Many alternative stop loss evolution mechanisms (which means we have access to more advanced exit techniques)

If you’re interested in learning more about sources of statistical bias in automatic system generation and using pKantu, our latest automated system generation software 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.

Thanks for the great tool. It must have taken much work from the number of lines of the source codes.

I was playing with it for a while, and was wondering if I could enable the use of closing patterns. I checked the box in the options but the systems generated were still always in the market except the very beginning of the backtest period. Also, I couldn’t seem to make the max rules value work. I set it to 1 and the systems can still have more than one entry/exit rules.

I am very interested to see what the results look like when these work. Also, I am not sure the proper mechanism to use the exit rules. If we are in a long trade for some time, and one day all the buy entry rules and buy exit rules are satisfied at the same time, should I exit a trade?

Thanks so much for updating OpenKantu and that it is still available for free! I have tested the new version 2.10 and notice some bugs. Would you mind looking into them?

– When adding a symbol, it always fails at the end as it can´t find the “symbols.txt”. Yet Kantu uses a “symbols.csv”. So adding any new symbol fails and can only be done manually in the CSV file with a external editor.

– Regardless of how many systems I request in the Simulation -> Options dialog, it always generates 600 systems. The same for the CPU cores, I´ve set it to 8 (I have 8 cores), yet the generation uses a max of 32% CPU, so 3 cores (the default setting). It seems to pretty much ingore anything I set in the options dialog, even though the options are still set correct after a restart of Kantu.

Thanks for your comments :o) I have now fixed all the reported issues in v2.20. Please download and try this release and let me know if you find any other problems. Thanks for reporting bugs and using the software,

Now please don´t get me wrong, I highly appreciate the work you are doing, but since you were wondering why OpenKantu is not that popular in the MT4 community… apart from the above mentioned hefty bugs, it might also be for the reason that the backtests in OpenKantu / MT4 don´t really match at all.

I am a full time forex trader since 8 years now (only using automated approachs), so I am 100% sure everything in terms of spread, slippage, etc. between OpenKantu / MT4 is setup correct and it´s using the exact same data, still I can´t get the backtests to match at all. See:

I mean they LOOK close, but for example: the strategy in the picture has 7435 trades in OpenKantu but 3690 in MT4, which is a huge difference of course. The same goes for any other strategy I have tested and exported. Surely small differences are normal, but those difference are definitely not going to work and might be one of the reasons why people do not use OpenKantu.

Thanks for your comment :o) You were right in that there were some problems matching back-testing results between openKantu and MT4, particularly when using an SL/TP in the system generation process. I have now fixed all these issues in v2.20 and you should now see an almost perfect match in the number of trades. There are still some differences that might appear due to rounding differences between the two softwares but overall the number of trades should now be extremely similar, as well as overall trading result. Of course OpenKantu uses no swaps so you might still find some differences in absolute profit values due to this fact. I have now also changed the file generation to automatically set any used SL/TP as the default option in the expert and I have set disabled compounding to “true” as a default (since OpenKantu uses non-compounding simulations this should allow for a direct comparison). Do test this release and let me know if you find other issues. Thanks again for reporting bugs and using the software,

Thanks for writing. I see those columns on both the windows and linux binaries that have been posted on the website (tested on Windows 8.1 and on Linux Mint 17). Are you building from source? If so then this could be related with your particular window manager or the libraries you’re using to build the graphic interface. Can you scroll the table to the side? it seems that your scroll bar still has some room towards the left. Does maximizing the window help? Let me know,

thanks, but I found the cause, I had to delete the config.ini from 2.10 and it re-appeared. Not sure why this is the case, as nothing in the relation to columns can be configured in the config.ini, but now I can do the tests:)

Ahhh, now it looks A LOT better:) Backtest in MT4 match almost 100% to the ones of Kantu, very good:)

A question I´d have: would it be possible to add a option to Kantu and the MT4 EA it create to let it trade fixed lots (1 lot for example)? This would make it a lot easier to evaluate the results for me without any money management nor lot-size adaption because of the ATR based SL.

Another bug I found: whenever I edit something for the symbol in Kantu, for example changing the “pointConversion” from 100.000 to 10.000, it says it saves the changes but then right away it jumps back to 100.000. The same goes for all other aspects of the symbol. Any editing I do to it in Kantu jumps back to where it was after “Save Database”, although it says it has saved the results.

Thanks for writing :o) I’m glad that it’s working now. Regarding the feature request, I will add it to the feature requests list but since this is an open source free project I sadly don’t have that much time for it so it may take a long while to implement. If you’re interested in contributing you might want to implement this within the OpenKantu source. You might also want to share your results and experience using the software on online FX forums so that others can also comment and contribute to the project :o)

Regarding your issue with the changes, after you change anything you need to make sure you click the checkbox on the top right part of the table since otherwise changes are NOT committed. After you make the change and click the checkbox you can then save the database and your changes will be truly saved to the DB. Let me know if you spot other problems,

However, the process goes fine if using “Find Systems -> Single Symbol” on each of the both pairs I am trying to use for the Multi Symbol search. So I guess it has nothing to do with my data but is a bug in OpenKantu?

Thanks for the report :o) This works properly for me. You need to ensure that ALL the pairs have data between the dates that you have specified within the Options dialogue. If a pair has data for some period and another pair is missing data then you will have this type of errors. Let me know if you spot something else,

thanks for all the help and all good about the fixed lots thing, no need to do that, I can do it easily in MT4 anyway, just would be great to see it in OpenKantu too because of the fitness calculations, but it comes close enough already. I am also lacking the time to code something like this for Kantu, truly sorry. But if Kantu works out for me, I will surely spread the word.

About the division by zero problem, I can´t get it to work. Both pairs (AUDUSD and EURUSD) have data from at least February 2001 to November 2015. The data is free of bigger holes or price errors (I am using that data since years already and always maintain it) and the options dialog I´ve set a start and end date that exists in both. Still I am getting the divide by zero whenever I try to generate something for multi pairs.

If you want, you could take a look at this with my data, I have packed up my whole Kantu directory and uploaded it here:

Maybe you can tell me what is wrong and where the problem is? If I can get this going and get some good results (which I already get on a single pair base), then I´ll surely spread the word about it. Right now though, I think the reason that it is not widely used is the technical knowledge you need to have to make it really work (see our discussion) and the bugs it has. For example, why doesn´t it say that there is a problem with the date-ranges instead of giving a divide by zero? The average Joe out there will just “bin” the program by that time, if you know what I mean. The same with the editing of the symbols, why do I have to click a checkbox after editing and before saving it? The average Forex trader that wants to generate strategies will not get that and stop using the program.

Thank you and keep up the great work!

P.S.: I was always eager to join your community at one point. I know the “real” Kantu is being run on GPU and I was wondering: does it have the same interface as OpenKantu or is it something completely different?

Thanks for your reply :o) Well actually there was indeed a bug! Thanks to your posted folder I was able to reproduce the issue and will post a fix tomorrow along with a few other minor changes (in line with the other usability issues you have mentioned). Make sure to visit the blog tomorrow for this update (I will post another reply to your comment once it’s uploaded). The issue had nothing to do with the dates, it was another problem that was exclusive to Windows machines (had not noticed because I was testing multi-pair only on Linux). Thanks again for reporting all these bugs and for offering to eventually spread the word :o)

Best Regards,

Daniel

P.S: pKantu does not have a graphic user interface, in order to make it as fast as possible we designed it as a “console-only” program. However it is 100-1000x faster than OpenKantu so we presently only use pKantu for price action mining. Right now we have a repository of more than one thousand trading strategies that we have generated and validated using this program and our cloud-mining setup (where several of us contribute GPU resources to evaluate data-mining bias and search for setups we like).

that´s seriously great to hear, thanks and I am looking forward to the new version already whenever it is done:) Much appreciated!

All right about pKantu, yes, that sounds great indeed – I am following your blog for a while already and know how you guys do it, just didn´t know it´s command line, which is even better since I am coming from Linux too:)

What I might have missed: how well are your pKantu generated strategies going? I actually would love to join the community, but because of the lack of live accounts that shows that “things are working going forward”, I have not done so yet. Is there any place where people that are interested to join your community can see the actual live results you guys are getting? At least for a few accounts? Thanks a lot:)

Little update: I tried to build some systems on M1 data (15 years). But Kantu runs out of memory quickly. There is more than enough free RAM on my machine (64gb) and the Kantu process seems to use only 1GB so even though that it is 32bit, it should not have hit the 2GB per 32bit process limit. Yet it brings this message. Could you look into that as well? Possibly a 64bit build would address this?

Thanks for the update :o) The new v2.21 is now out and fixes both the multi-symbol error and an error in the new symbol addition wizard in the symbol loading dialogue. I have also compiled the windows binaries for windows 64-bit so that those using 64-bit systems (most people nowadays) can benefit from using more memory. Do let me know if you find other bugs and thanks for your continuous reports,

Thanks for writing :o) Well I have a philosophy for our community that anyone who wants to join should join without any expectation of profitability. Past performance does not guarantee future results and we certainly do not want anyone to join thinking that “this is it” that they have found something “that works” and that they should just now load systems and expect money to roll in. Things do stop working and I do not want to give anyone the wrong expectations about what our community is about. It is about learning and understanding.

This is the precise reason why we don’t share any live results. I am aware that this is a poor marketing strategy and that many people want this information to join a community but I am content with having a potentially much smaller group of members who are in the community because they want to learn and understand trading rather than just because they saw something that had some historically profitable result that they want to carry out forward. I am aware that this is not for everyone and I certainly respect the view of those who want performance track records to join but it is simply not in line with the way in which I view my community and hence it is not something I am willing to share openly, all live accounts will always be kept private. If performance is something you need to join then our community might not be in line with your views. As I said I am content with having just those with a view aligned with my own as members although I don’t see anything bad in those who view differently.

Do let me know if you have any questions about our community or our software :o)

thanks a lot for fixes, I will test the new version with the next hour most likely already.

As for your community, yes, I understand where you are coming from, but honestly, I make a living from automated trading for 8 years already, it´s my main income and I know things in and out, down to the broker level in terms of how liquidity is setup with LPs, how they handle the flow, how FIX API works and what LPs love so that you get less rejects – it was a must to get into that area too because my trading consists mostly of scalping with a trade duration of 4 seconds or less.

Anyhow, as much as I enjoy this, I am here to make money in the end, like most people are. I am not sure I would spend all this time just for fun, there are certainly more interesting and more fun things in live to do than to trade Forex just for the sake of it, right? So I am always skeptical if someone wants to charge money without showing any results or says “we are just here for fun and no one needs to show results”, because most often this simply means they are not achieving anything and just want your money for that “REALLY working systems we have now” :)

I know that this is not the case with you for sure, I am reading your blog to long for that already and know you are not one of those fishy sellers, yet still , beside the great software you make, I´ve never seen anything in terms of live results either. Surely, I have those great backtests that you send from time to time and my theories as well, but I am missing the translation to live trading on that, because, as we all know, this is a whole different story then and those equity curves usually never go the way they did in the backtests:)

Again, I highly respect what you do here though, but I know that all theory, all anti-DMB simulations, all stability tests, all cloud-computing (and I am doing that as well) can look perfectly well and sound totally logic, yet it fails when going live (which it does in most of the cases as you surely know as well). So just relaying on theory and saying that this “SHOULD” work, is not really enough for me. Most of my theories that made perfect sense, have simply NOT worked when going live. So after all these years I´ve been through, I know that without seeing any kind of live results, I am a bit hesistant to sign up for a whole year. Because usually, and this is just from experience, if people don´t show their live results, it usually means they are simply not making money. If you had a monthly subscription model, even if it comes at a higher price than the yearly one broken down to a monhtly base, I´d already have taken a look for sure. Maybe something you´d like to consider?

In any case, thanks for the hard work you are doing and for providing your blog for free as well as OpenKantu! I will report back shortly.

Thanks for your reply :o) As I mentioned before I do respect your point of view – which is shared among many traders – but my position remains the same. The aim of Asirikuy is not to be a huge community but simply a community of like-minded traders who work towards an understanding of automated trading. Showing live trading results is incompatible with this as it brings lots of traders who do not share our philosophy and goals (which is something I experienced first hand when I experimented with showing results many years ago). I prefer to keep the member base small, made up of people who think more like me.

I know that many potentially worthy members (like yourself) would also walk away due to this fact but I am happy with this trade-off provided that with this lack of public live results almost everyone who joins does it with the mindset I am looking for. As I said, it’s perfectly ok if our community is not what you’re looking for, I know it’s not what everyone wants and that’s perfectly alright.

Do let me know if you find any other bugs with OpenKantu and thanks again for commenting and using the software,

thanks again for the reply and no worries, it´s all good. It´s just a bit unclear to me of why you guys are doing all of this if you are not making any profits from it. But of course you can do whatever you want with your time, just was wondering about that.

I did not find the time to look into the fixed OKantu yet, but I´ll do so soon. Thanks again for making the software available:)

Hi Daniel, OK great! What was fixed / changed if I may ask? What I noticing on 2.21 (and previous versions) is that the backtests in Kantu below M30 (e.g. M15, M5…) do not really match well with the resulting MT4 backtests. Altough the same data and spread and slippage values are being used. From M30 and up it seems to be better. Still wondering about this… With M5, there are thousands of trades difference sometimes between MT4 and Kantu.

Thanks for writing. You can look at the github changelog for each commit to see what is changing. Regarding the reported problem, I will investigate the issue to see if I can find the cause. My guess is that on the lower timeframes rounding issues becomes much worse and this is therefore causing significant mismatching. I’ll let you know if I find a solution,

OK great, thanks! I noticed why it doesn´t match, I used a to big max period. MT4 does only hold a max of 1000 bars back for whatever timeframe as I just saw. So you might possibly want to limit the “Max Shift” to 1000 in the options dialog Kantu, as not all people might know this.

Sorry, that only applies to the stat of the backtest in MT4 as I see when using the EA in the strategy tester. At first it loads 1000 bars only, then, as the backtest progresses past 1000 bars, it holds more:) So all good!

Thanks for letting me know :o) I’ll implement a change in the template so that the EA does not trade in MT4 if the number of bars is less than the maximum shift. Again let me know if you notice any other issues,

Thanks for writing :o) Actually the modifications are a little bit more involved since I have to make sure that proper UI messages show in case this happens when the person is live trading, etc. You also have to check against the ATR function’s max lookback period, not only the trading pattern. I will be releasing the update to v2.31 with these and some other template changes soon. Thanks again for writing,

man you are fast in fixing bugs and doing updates, amazing:) Ah yes, the UI messages, didn´t even think about them as I don´t look at them, but all good, you are right. And yes, the ATR period needs to be taken into account as well of course. I usually put all look back periods into a array, then do a arraymax to find the longest length. But you know how to do it….

Btw, I am getting really curious about pKantu now, if you´d just have a monthly subscription I´d go ahead and come in TODAY :)

And the system goes through the whole 15 years backtest in 2 seconds. Seems it has something to do with your new check for enough bars? My Kantu generated strategies are using lookback periods of up to 3000 bars on M15. I guess you decided to check the available bars OnInit now and stop the EA if there are not enough bars? So basically any MT4 EA which uses > 1000 bars, can never be backtested, should this be the case.

If so, you´d have to implement the check differently. You´d need to check this OnTick / Bar Open and don´t cancel the execution of the EA but wait until there are enough bars available for the EA to begin trading. The backtests at first only ALWAYS loads 1000 bars, but as the backtests progresses, it holds all bars accessible. So once the EA has passed 2000 bars into the backtest, there will be 3000 bars available for the look back periods and then it can begin to run. That´s how I do it in my EAs. Canceling the execution during the init is not a good idea as you´ll never get a backtest then with anything looking back more than 1000 bars.

Thanks for the quick fixes Daniel, everything seems to work now in that relation. The only strange thing that happened to me today is that I´ve been generating strategies on EURUSD M15 15 years of data from 2001 to 2015. In the strategies it generated, there was just ONE that did show the backtest only going until 2012, while all the other did go as set until 2015. This was during one run, I didn´t stop and restart or anything. But it just happened one time, so hard to tell why it did that….

Glad to know it works correctly :o) About the 2012 issue, sometimes you do find some systems that attack some very particular phenomena in the price series that at some point ceases to exist in any relevant quantity. This then manifests as having systems that appear to not back-test for the full length of the data but what happens in reality is that the entry criteria is not triggered through a good chunk at the end of the data. It is normal for this to happen from time to time, especially if rule numbers are higher than 3-4 and max shift numbers are high. Let me know if you have other issues,

yes, that would make sense for systems that trade very rarely. But my systems do need to have at least 1200 trades in 15 years. For that particular system it had 2284 trades from 2001 to 2012 in that “cut off” backtest and then disappears completely without even a single trade between 2013 and 2015? I think there is rather another problem somewhere. So I´ve exported this system to MT4 and voila, it indeed has 22XX trades until 2012, but also trades in 2013 to 2015 with another 800 trades.

Also, the equity curve is not filling the screen fully like all the others do. See these screenshots:

Thanks for your reply :o) Yes, there was indeed a bug. What happened is that some systems have inconsistent logic (logic that can give you a long and short signal at the same time) and this logical inconsistencies sometimes don’t show up until the test has advanced considerably. Such systems are now filtered and are not added to the results on version 2.33 (just out). Let me know if you find other problems and please spread the word about the software :o)

I will test 2.33 shortly, currently 2.31 is still running. I am wondering about one (not so important) cosmetic thing: why is the blue progress bar at over ~70% for me already while it has just discovered 1051 of 20000 requested systems?

Your results look quite oke.
Could I ask you what number of rules, shift and variantion
step do you use?
Do you have good OS results on 15 min?
20000 systems at 0.5 seconds is a long generation.
That is probably running for days…

>Could I ask you what number of rules, shift and variantion step do you use?

max 3, max 3000 and 3.

>Do you have good OS results on 15 min?

So far yes, but to early to really say, and as you know anyway, there is no real OOS doable at all with historical data. I am testing the strategies with boot-strapped data, input parameter variation of 25% though and make sure they at least have 1000 trades in the 15 years (though prefer the ones with 2000 trades or more of course simply for the reason of statistical significance), but the main idea is to use as many as possible equity-curve-uncorrelated ones on different pairs and TF´s too (that´s what I am experimenting with with Kantu right now, but currently M15 seems to give the best results at least for EU and GU in terms of signifance, low lookback period – most of the good strategies in that run use less than 2000 look back period on M15 – and the trailing stop can kick in quick as well to not miss the luck of the market wanting to give to me which it sometimes can already do within the 15 minutes just to reverse completely later on) and keep on adding to the portfolio as well as removing failing ones that exceed their worst historical drawdown or stagnation days. We´ll see where I get with that. At least that approach has been working for me in the past.

>20000 systems at 0.5 seconds is a long generation.
>That is probably running for days…

Yea, I am running it for days already, no problem though, I am happy with the speed and the quality of strategies OpenKantu seems to come up with – better than StrateyQuant (and I am into this one in depth as well since a long time) / PriceActionLab / Zorro etc…

What I was rather referring to is the fact that the blue progress bar is so far to the right side already with just 1000 strategies of the 20000 requested done. Shouldn´t it be exactly at the half once 10000 strategies have been found? Or at 25% once 5000 have been found? It´s no real problem, just a cosmetic thing I am wondering about.

One other thing I wanted to ask is about the trailing stop method Kantu uses: I see the trailing stop seems to be always adjusted to the current ATR, which is at first logical. However, as I see, this also means that the stop loss is sometimes set to a worse value than what it already was before. At least for my systems, the trailing stop, while also being ATR based, cannot become worse than what it was – as it is kind of not a trailing stop anymore then but a ATR adjusted Stop Loss.
E.g. when the SL was at 1.2010 for a SELL order already, it can´t become 1.2020 again later on, it can only become lower than 1.2010. The systems OpenKantu generates, I often see the SL going from 1.2010 to 1.2030 again if the ATR expands – which, at least by a visual check of the backtests, often makes trades lose money that could have been winners already.
Have you actually tried that approach too for Kantu / your systems in general? Surely a already existing systems that OpenKantu generated is not being improved by it (by my tries with that afters in MQL4), but I wonder what would happen if the systems are generated that way already in OpenKantu and what it would come up with then….

Allright about Lazarus, however, I am using FPC 2.6.4 right now and notice it comes up with a slightly bigger EXE file than your kantu.exe Are you also using FPC 2.6.4 or possibly a older version? Because the settings I use for compiling are exactly the ones your Lazarus project at Github loads.

OpenKantu does not implement any trailing stop mechanism. The reason why you see the SL move is because the SL and TP values are reset whenever you have a new signal in the same direction as a currently open trade (this is made to avoid trade chain dependency). This can sometimes look like a trailing stop but it is not because it simply resets the SL/TP levels to the values that would be present if a new trade had just been entered (so it can be worse than the initial SL as you have noticed). To access several real trailing stop mechanisms I would invite you to join asirikuy and use pKantu which has several true trailing stop mechanisms implemented. Thanks for writing,

P.S.: Have you tried using the Free Pascal Compiler 3.0 for OpenKantu yet? Just wondering how it would impact performance since they´ve done some bigger changes to it. But I see Lazarus is still using FPC 2.6.X and am not experienced enough to link FPC 3.0 into it.

I haven’t tried it but there are a significant number of incompatibilities between the 2.6 and 3.0 compiler in terms of the Lazarus libraries so I would rather wait for the Lazarus team to update the compiler instead of attempting to do this myself. The program already has all available compiler optimizations in 2.6 applied so I don’t know how much faster it could get if 3.0 was used. We’ll see in due time :o)

just found another thing that is kind of annoying (especially for unexperienced traders). If you put the risk really low for example 0.001 since one for example might want to trade 0.01 lots fixed, the EA comes up with:

It would be great if you simply could make it adjust for the minimum broker lot-size that is allowed instead to not send the trades (same for the max lot-sizes and lot-step, in case that´s not done yet?).

It is very important to prevent trading instead of rounding to the minimum lot size because the minimum lot size can sometimes imply a great increase in risk. Imagine if you were trading at a risk where you are supposed to trade at a 0.0001 lot size but your broker’s minimum lot size is 0.01 you are then risking 100x more capital than what you think you are because you are rounding towards the upside. Adequate risk control demands that you never round lot sizes towards the upside. If you see this minimum capital warning message then you should either increase the risk (knowingly risking more) or increase your available capital. Let me know if you have other questions,

I also just noticed that the calculated lot-size (besides the things mentioned above) does not take the TICK_VALUE into account, which makes it calculate wrong lot-size for non-USD based accounts or simply said if trading a pair that is not denominated in the account base currency. If you want to use it, here is my Lot-Size-calculation-function that takes everything into account, tick-value, account base currency, sl size (pass it to the function in points), min lots, max lots, lot step (and without using fixed numbers in case a broker has some exotic lot-step size), required margin and also allows to pass in fixed lots in case that´s needed:

double GetLotSize(double Stop_Loss) //StopLoss in POINTS, not Pips
{

int DigitsMulti = 1;

if (Digits == 4 || Digits == 2)
DigitsMulti = 10;

Stop_Loss = Stop_Loss / DigitsMulti;

double divided_by = 0;
double Lots = FixedLots; //to be set in global variables of the EA
if (MoneyManagement) // to be set in global variables of the EA
{

I seem to understand why you haven´t done the correct risk adaption with tick value and tick size etc., you´d need to do it in OpenKantu as well so that backtests match, but there you don´t have the data available to calculate the tick value. Hmm…. then you might most likely just want to leave it as is since otherwise the MT4 backtests won´t match the Kantu ones anymore.

The really simplest thing to avoid this would be if Kantu simply could generate it´s systems on fixed lots instead of using money management already when generating the strategy. That would also lead to more robust strategies from my past experience since I love to judge a system without money management on fixed lots as well. So if OpenKantu had a mode to generate strategies based on fixed lots, that would be great, and also would make it easier to get them to match in MT4.

Note that OpenKantu does not use any compounding it generates systems based on a fixed loss of around 1% of the starting capital per signal (meaning a constant amount of money per signals is risked through the whole test). You see variations in the lot size because the SL is not always the same but no compounding is actually used. This is the same as if you were trading a fixed lot size with a fixed SL. The fact that the SL is not fixed – as it varies with volatility – implies that the lot size needs to change to risk the same amount of money on each trade. If you used a fixed lot size then you would risk more on more volatile markets (as the SL would widen) which would heavily distort your results (you would favor systems that have better results under more volatile markets). When you export to MT4 you can actually set DISABLE_COMPOUNDING to FALSE so that you can actually compound returns (risk a fixed percentage of the account per trade).

Yes, I know that Daniel. Still, the 1% are wrong in live trading since you don´t take into account the TICK VALUE in your money management formula. For example, if trading EURUSD or GBPUSD on a USD based account, it´s all correct because the tick value is 1 in that case. But if you trade USDJPY on a USD based account, the tick value is 0.8 right now for example. Same if you trade EURUSD on a EUR based account, tick value is 0.7 then for EURUSD, etc.

Yes, OpenKantu assumes that the deposit currency is always equal to the quote currency. Therefore it assumes a JPY account when trading USDJPY, USD account when trading EURUSD, etc. I cannot correct to a constant deposit because conversion rates are not available in OpenKantu so back-tests would mismatch with MT4 results. You can always compensate for this by adjusting your risk or – if you want to reproduce exact results – then you can carry out a simulation using an account denominated in the quote currency (as the simulator assumes).

Yes, I understand you don´t have the possibility to get the tick value in Kantu if not all pairs needed for the calculation exist. So no problem for now.

However, can you make the MQL4 code adjust to not skip trades because the trade would be below 0.01 lots and adjust it to the minimum lot-size the broker accepts? That´s in any case better than completely skipping it – important for small accounts.

Thanks for posting. Yes, I replied to both your trailing stop and minimum lot size comments before. Here is a copy of my replies:

About the minimum lot size: It is very important to prevent trading instead of rounding to the minimum lot size because the minimum lot size can sometimes imply a great increase in risk. Imagine if you were trading at a risk where you are supposed to trade at a 0.0001 lot size but your broker’s minimum lot size is 0.01 you are then risking 100x more capital than what you think you are because you are rounding towards the upside. Adequate risk control demands that you never round lot sizes towards the upside. If you see this minimum capital warning message then you should either increase the risk (knowingly risking more) or increase your available capital.

About trailing stops: OpenKantu does not implement any trailing stop mechanism. The reason why you see the SL move is because the SL and TP values are reset whenever you have a new signal in the same direction as a currently open trade (this is made to avoid trade chain dependency). This can sometimes look like a trailing stop but it is not because it simply resets the SL/TP levels to the values that would be present if a new trade had just been entered (so it can be worse than the initial SL as you have noticed). To access several real trailing stop mechanisms I would invite you to join asirikuy and use pKantu which has several true trailing stop mechanisms implemented.

I always reply to each particular comment so make sure to check for nested replies on your comments to see any answers that may appear hidden. Let me know if you have other questions,

thank you, yes, what you say makes sense and I think the same, but not getting trades does not make sense either as with a bit of the “typical forex luck” you are only catching the losers then and miss the winners then:) I have added the function on my own now, so that it will not give this message but simply adjust to the brokers minimum required lots. So no worries.

As for the trailing stop, I understand, it´s just the stop being moved to be in sync all the time, interesting. Yes, I also checked your previously nested replies, there was no reply to that question yet. Hence I had re-asked.

As for pKantu: does it generate MQ4 code as well or can the resulting systems only be traded via your framework?

I´d be in right away if you have a monthly subscription model, but paying in advance for a year is nothing for me – that´s also the response I had from most other people I told about OpenKantu (and pKantu). They´d love to join the community, but no one of them wants to pay for a year. Max for a quarter to see if it is something for them first…

Thanks for your reply. In pKantu systems are created for the F4 framework (no MQL4 code is generated) however the F4 framework works with MT4 so you can also trade pKantu systems in Metatrader just as easily as you trade the current OpenKantu systems only that you get to use all the improvements available in F4. For example you get to benefit from all the time refactoring and rate equalization capabilities, the advanced logging and all the additional functional possibilities included within the pKantu system codes. You also have source code access to everything, all F4, plus all the code generated by pKantu so the approach is equally transparent.

About the subscription model, it won’t be changed. I am not in a rush to get any new subscribers so I am happy to get only those who agree to make a yearly commitment. It’s certainly fine if you don’t want to join because of this reason. Our doors are open if you ever agree with a yearly commitment. Please feel free to report any new issues with OpenKantu and as always feel free to spread the word about the software,

thanks for the reply, yes, I totally get what you say – no interest from my side then currently, besides OpenKantu.

I´ve noticed one really huge bug: when you trade the created EAs (D1 timeframe) live or backtest them via the “Every Tick Method”, it enters trades intra-bar on the selected timeframe instead of finished bars. However, in OpenKantu it of course only trades on “bar open” like it is supposed to do.

As long as you backtest in “bar open” mode in MT4, everything matches up, but as soon as you got to the “every tick” method, it shows that the EA is not checking if a new bar has opened or not, but opens all the trades intra-bar once a SL was hit instead to wait until the next full bar.

This way the MT4 backtests (and live trading too) do not match the OpenKantu backtests at all. Only if you backtest in “bar open” mode in MT4 it all matches up.

You need to add a function that checks if a new bar has began in the MT4 code and only open new trades then, not intrabar once a full SL has been hit, as the live trading results are completely different this way.

There you can see the issue. Once going to every tick backtesting mode in MT4 or live-trading (it would happen there just like that too), backtests don´t match anymore. This might be one of the main-reasons why OpenKantu didn´t get popular yet, since as the MQL4 code is right now, live trades can never have matched the backtests trades.

You might also want to check for if the trade really opened or not, since for the D1 timeframe it would trade at 00:00 at my broker, but my broker does not accept trades during 23:55 to 00:05 as it´s rollover time then for him, he still prices though, so the EA would get an error when trying to open a trade. So we can only enter at 00:05, which would be no real problem as the price will most likely be not much different.

So you should add a variable that checks if a trade was really opened or not in the previous attempt already. Simplest way to do this, at least how I do it in my EAs, is to check for current open orders under the EAs instance ID and if that order was opened current bar or not.

Thanks for writing :o) Yes, there was indeed a bug within the generated MQL4 code. This is now fixed in v2.34. The template now implements an adequate way to account for execution only once per bar, including retries on failures of order send/modification commands and survival of the state to platform restarting. I have also implemented a few additional fixes that were needed on the template in case of TP modification errors and also made a few minor changes to improve speed. Tests now match between OpenPrice only and the other testing modes as far as I tested. Let me know if you find any other bugs and thanks for reporting,

that sounds very good, thanks. I will check it out. May I ask how often it retries until it gives up on the trade? Because the EA might get a ton of errors between 23:55 to 00:05 on my broker when they still price, but reject all trade attempts with “Market is closed”. This would make 5 minutes of errors from when the EA starts to try to enter from 00:00 to 00:05, so possibly, depending on the amounts of ticks, up to 500 rejections before it finally gets in at 00:05.

Btw, in that relation it would also make some sense to have a spread-filter in the EA. At 00:05 the spread can be at 10 pips or more sometimes. So while the broker does allow trading during that time from 00:05 and up, it might be at extreme costs, while at 00:07 the spread could be normal again and we could have saved several pips of entry costs while the market still hasn´t moved to far off. What I´d imagine is a spread-filter that only enters on the new bar once the spread is below “X” pips (setable in the EA). What do you think?

Thanks for writing. The experts will not attempt to enter a trade if the market is closed (even if ticks are coming in). It checks the IsTradeAllowed variable before attempting to enter a buy trade or a trade modification so if tickets are coming in but your broker is not allowing trades it will not attempt to enter. It will also only log error messages if the difference between the last error print and the current error is greater than 60 seconds so at most you will get 5 lines if the system encounters that trading is not allowed during this window.

Regarding the spread filter, sure, I will add it to the next version. Let me know if you have other questions or bug reports,

I am not sure, but I may have found a new bug. I´ve tried to merge 2 strategies from the pool (both EURUSD) to a portfolio to see the results it would give via the “Show Portfolio Results”. While the amount of trades is shown correct, the others stats are all “0”. Is this normal?

Yes, this may be a bug. This is because there was some error in the calculation of the statistics from the portfolio curve so the calculation of the statistics was aborted and all values except those saved within the testing process were set to 0. It may be difficult to reproduce without the exact same data since these errors may be particular to very specific system/data combinations. I will try to see if I can reproduce something similar. Let me know if you spot something else,

IsTradeAllowed() is returned as “true” during that time, I already checked that. So will the EA still handle the errors that will follow through that behavior and get into the trade once trades are not rejected anymore or does it stop after a certain amount of retries until the “next bar” (which would be the next day for a daily system).

Access to our full historical data (any timeframe) is currently restricted to only Asirikuy members. The daily data included with OpenKantu is daily data downloaded from the Alpari NZ platform (freely available to anyone) but at Asirikuy we use data derived from a private 1987-present 1M data set.

I have been able to reproduce and have fixed this bug in v2.40 :o). I have also added the MAX_SPREAD_PIPS external variable to the MQL4 template so that you can set a max desired spread and added the Trade allowed check based on MarketInfo(Symbol(), MODE_TRADEALLOWED). Let me know if you have any issues with the latest release,

Thanks for writing, hope you enjoy the new release. About the EA, the systems always retry for the duration of the WHOLE bar if there is a signal, there is no retry limit. But you will NOT see an error message on every tick since the EA only logs errors once every 60 seconds. This is for both the higher spread AND whatever errors happen on trade entry. Do let me know if you notice any new bugs,

Thanks for writing :o) There is no genetic optimization (or any other optimization for that matter) within the pattern generation process to avoid the increase in bias that comes with this type of searches. The searching process is entirely random. This has some disadvantages as well because it complicates the measurement of mining bias within the process – not as much as genetic optimization though! – and if the space is small then you start having duplicate system testing (because unprofitable results are not saved to prevent increases in memory usage).

We tackled these problems in pKantu. In pKantu we generate the entire set of systems for the searched logic space, save it and evaluate the entire space sequentially. These changes lead to much less complicated and efficient data mining bias testing. This of course is only possible due to the fact that pKantu is much faster than OpenKantu. Let me know if you have other questions,

Best Regards,

Daniel

PS: The “optimization target” dropdown box in the options dialogue is completely useless, it is a remnant of some tests I performed ages ago. I will remove it on the next update.

You need to use MarketInfo(Symbol(), MODE_TRADEALLOWED) not the global IsTradeAllowed() function, I will modify the template to use that from the next update. If you check with MarketInfo you should get that trading is not allowed for that symbol at that time. Also in case of errors the program retries continuously until it gets the order through, only that errors are only logger once every minute.

As for the 2 checks, how is the behavior if I set a spread of 0.5 pips and have a system that trades on the daily bar…. now it is 00:06 and the spread is 1 pip. Will it wait until the spread becomes 0.5 pip again for a tick and then enter the trade or will it wait until the next bar (day) to open a new trade?

As for MarketInfo(Symbol(), MODE_TRADEALLOWED), that is the same as IsTradeAllowed() and also returns “true” during my brokers rollover, though you still get the “market closed” message when trying to place trades during 23:55 to 00:05. So how does the EA handle that scenario, does it keep on trying for the whole bar (day) to get into a trade or does it give up after a certain amount of retries?

OK, that sounds like exactly what is needed then. No problem, it does not need to log it. Remember, MT4 has 2 different logging areas. One is for the EA, and the other is the Journal. Even if the EA only logs every 60 seconds, the journal area/log will log each and every single trade attempt (and failure or success).

thanks for the explanation, that´s what I was hoping for. And yes, I was asking this because of the “optimization target” option;) All good then and great to hear about pKantu being so fast!

Another question: how do you deal with time-zone-shifts between brokers in the F4 framework (where pKantu systems are being run)? If daily bars are being used, do you have UTC unified historical data for each pair and generated the systems on that with pKantu? And the F4 framework is then adapting the correct offset for each (MT4) broker you trade it at?

Thanks for writing. In F4 we generally correct the data to GMT +1 non-DST/ GMT +2 DST because market opening times also change with DST so we have concluded that a DST adapted time zone is the best to take advantage of fixed hour filters and things of this sort. Our back-testing data (the one we use for system generation in pKantu and back-testing in general) is already in this format and when live trading the F4 framework corrects the broker’s data to match this same structure. We also generally trade weeks from Monday 4 to Friday 19 in order to ensure we can have the exact same structure independent of broker opening/closing times. This also eliminates some noisy behavior that might happen along these lower liquidity hours. The F4 framework uses NTP synchronization as well to ensure that all these adjustments are done correctly. In the end the framework is able to always refactor data so that you always trade the exact same thing, regardless of how your particular broker handles DST, GMT changes and weekly starting/ending times. Let me know if you have other questions,

ok great, thanks for letting me know about this. Since you are asking: would it be somehow possible to add the swap (at least estimated) to the backtests in OpenKantu? Ths CSV would then have 2 extra fields, one for swap long, one for swap short. I know it won´t be 100% accurate, but at least would get things a little more “real”.

The problem is that swaps depend on each Forex platform’s data and cannot be directly exported through the MT4 history center, therefore adding swaps would imply having a potentially bigger mismatch with MT4 results since swaps would need to come from another external source. The added complexity of having to put swaps into the data also means that less users will be able to easily use the software and understand its results. For these reasons I am not going to implement swaps in OpenKantu simulations. Thanks for writing!

well, results do differ a lot more now to MT4 in terms of total profit (not trade count which is now very accurate), which relates to OpenKantu not using any kind of swap and MT4 using swap. So MT4 results are always worse in terms of total profit compared to OpenKantu, by a pretty big degree actually especially for D1 strategies which hold trades for several days.

What I was looking for is not a daily historical swap value, but 2 extra fields for “swap long” and “swap short” – just like for the spread, in the CSV file. Unexperienced users could simply leave that field at “0”.

Surely, you now could say I could simply add the swap long and short total values to the spread in OpenKantu, but since spread is charged once per trade and swap long / short each day for each trade and trades do often last for completely different lengths in the created systems, it would be more accurate to implement it in a way that OpenKantu charges it daily on each trade. That´s just like MT4 does it and they use the last known swap values from the last time you connected to your broker. At least it would get us a little closer to reality than not using it at all. And 2 extra fields in the CSV would already do the trick.

In any case it would be more accurate than not having ANY swap at all, like it is now in OpenKantu.

Btw, I have found a few more systems in the generation process which end trading years before the history-data ends or just start years after the history data begins. I´ve set minimum trades per year to 35 already, but this one simply seems to look for backtest years * 35 trades in the END, not per year – which these systems fullfill.

I think there should be an extra option in the filters section that says something like “must trade at least X times in each year of history data”. So that the system really MUST have at least X trades in each year of the historical data than to look if it did met the average at the very end of backtest. This would prevent such “instable” systems from going into the end-results. Thanks.

The current trades/year filter only accounts for having that number of trades on average, it does not look for having those number of trades on each year. Certainly that would be a possibility but implementing it requires significant re-coding. I will keep it in mind for possible future feature additions when I have more time. Thanks for the suggestion,

I disagree with you on this. Having inaccurate swaps is worse than having no swaps at all because you can end up with systems that are profitable only due to your present swap assumptions (which are wrong if you are not considering actual historical swap rates at each moment in time, they have changed a LOT through the years). At least under the current implementation you do not run into this risk and your strategies are at least swap-neutral (they were not mined with any bias related to present swap configuration). Another important thing for me is to keep the input format exactly as the current MT4 history center exporting format, so I do not want to add any extra fields that might complicate things for less advanced users. Due to the above I won’t be adding swaps to the simulations. However thanks a lot for making suggestions,

all right about trades per historical data year filter, whenever you have the time, that would be a nice addition.

As for the swaps, I don´t agree with you here. First off I am not talking about the history data CSV files from MT4 but about the SYMBOLS.CSV of OpenKantu – I meant adding 2 extra fields to the SYMBOLS.CSV (which has nothing to do with MT4 compatiblity). And you could simply limit it to negative numbers only for the swap values so that no bias can be created because of the swap in the backtests. And you can just leave it at “0” as default in the SYMBOLS.CSV so non-advanced users would not get in touch with it at all.

The system that OpenKantu currently creates for D1/M240 are simply not matching the MT4 backtests in terms of profits or the live results since the swap (which is negative most of the time on most brokers for either side anyway) is not taken into account. And adding the swap costs to the spread won´t do any good since trades last for different durations and hence do have total different swap costs.

I totally understand that you seem to work different and no offense taken – it really was just a look for me at OpenKantu to see if it can create anything useful for me compared to StrategyQuant, but without even being able to use at least a estimated (negative) swap rate (which, if being negative, would not be able to create any positive bias), I don´t see this going anywhere for me as it is simply to inaccurate to trade this live.

Thank you for the efforts though, I much appreciate it and should you ever have swap in OpenKantu, I would be pleased to take another look and also spread the word more about OpenKantu. But I can´t do that right now since I am not convinced about it yet with the lack of such features. And seeing all the bugs it had and that needed to be fixed first (especially the one with the live trading basically not working at all like in the backtests because it would enter several trades within the same bar), it seems no one has really seriously used it yet too unfortunately. Otherwise someone else would have reported all these bugs already. I hope that changes as you advance OpenKantu and come up with more features in it that your users suggest.

Daily data is the same as MT4, straight exported, and only bar open mode backtest in MT4, not “every tick”.

For other strategies it´s all fine, but there are some where it simply doesn´t match and OpenKantu starts trading much later while the generated MT4 strategy starts right away months or years before with the same data as in OpenKantu.

With all those hiccups and the missing swap feature it´s really hard to get anything useful from OpenKantu unfortunately :(

That difference in starting times is simply because of differences in the initial buffer lengths in both programs (in openKantu it’s different depending on the system characteristics so for different systems you’ll have different startup times). To make them match you can simply set the MT4 starting date so that it matches what you see in OpenKantu, that way they will both start trading at the same time. Well it’s a pity that you won’t be able to use the program due to some of its limitations. Hopefully others will be able to benefit from it despite these issues. Thanks for writing,

Thanks for writing. Well yes, since we simply never traded the Kantu systems using directly generated MQL4 files in our community (since we always trade through F4) the MT4 templates did have a lot of bugs, so thanks a lot for all your help in getting them fixed. Despite its limitations I hope some traders will find OpenKantu useful for their system building needs. If you’re presently using StrategyQuant (which also does not support swaps) the current limitations should not be so different. Thanks again and merry Christmas to you too,

thanks for your answer. That was my thought too (about the initial buffer lengths), but that´s not the case, since most of the OpenKantu strategies start indeed in 1989 (where my backtest data starts). About 20% though do start end of 1990 only, while in MT4 they still start in 1989. So the initial buffer can´t be the explanation as it then should be the same for any strategy (yes, the distances for Open / Close / High / Low are also similar for these strategies, so that can´t be it either).

Thanks for writing. The problem is indeed related to initial buffers, buffers are not only related with the shifts, there are other things that go into the buffer calculation that influence this (you can look into the code to see this).

About pKantu, cloud mining is just an option, you can certainly just mine on your GPU and use the systems that you create privately. Cloud participation is not mandatory, it is just a possibility given by the software. Let me know if you have other questions about pKantu,

As for pKantu: the systems it generates, are they the same “style” as in OpenKantu or can they use advanced trailing techniques like you´ve mentioned? I mean does it have other modes for trailing the stop or taking profit during the generation process already (not meaning to add them later on in the F4 framework)?

Is there possibly a video somewhere where I can see pKantu in action generating some strategies?

Thanks for writing. Yes, the systems are in the same “style” as OpenKantu in the sense that they are all price action based strategies. They do have several additional trailing stop mechanisms available (at least 6 mechanisms which are not available in OpenKantu). These are all implemented on F4 as well. We currently have no video showing the generation process (when pKantu is working you just see a console output with the generation times, number of systems found, etc). Let me know if you have other questions,

One thing I found today is that one of my generated strategies does not modify it´s SL daily (trading D1) while all others do. Isn´t it supposed to update the SL for open trades in ANY case each day adjusted to the current ATR on each currently opened trade? All my other strategies from OpenKantu always did so far in live trading, but this one (generated in the same run as the other ones) doesn´t do it and also doesn´t do it in the backtest, which I just verified.

See these 2 pictures, backtested on the same data, you see one strategy modified it´s SL for the open trade today (18.) while the other did not. And that´s also exactly how it was in live trading today, one modified the SL, the other didn´t do anything and also printed nothing in the log. So the behavior must be coming from the strategy design as it acts exactly the same in the backtest.

Is this correct this way or this is a bug? As normally the SL should be adjusted each bar open to stay in sync with the trade-chain.

Thanks for writing. Behavior is correct. In the OpenKantu systems the SL is only updated if there is a signal in the same direction on that bar. If a system has no signal on a bar then it will not update the SL. You may have found a system where signals do not happen as frequently as for others and hence the SL is not updated. Bear in mind that these strategies do not use a trailing stop (the SL is not adjusted on every bar, as a function of time or as a function of price) the SL is only updated if and only if you have a signal in the same direction as a currently open trade. There is no reason why there should be a signal on every bar (that depends on the logic). Proper trailing stops are implemented in the case of pKantu. Let me know if you have other questions,

all right, then that explains it. It only adjusts SL if there (still) is a signal into direction of the currently opened trade. If there is a opposite signal, it would close the current trade and place a new one. If there is no signal, it would leave the SL as is. Correct?

Yes, I know it´s no trailing stop, but I was under the impression that it would always adjust the SL to the current ATR value on each new bar. But your explanation makes even more sense and gives even less trade-chain-dependency. All good

What I am wondering, if pKantu generates systems with trailing stops, how do you avoid trade chain dependency in that case? I mean, yes, it´s clear that you still trade every signal, but if entering the trade at a later time when re-starting a system, it can´t be in sync when using a trailing stop. Well, at least not until the next new trade.

Thanks for writing. In pKantu the same thing happens although using a trailing stop. A trade is entered and after that the SL is moved as a function of time according to the trailing stop, if a signal in the same direction happens the trade is reset (the SL is set to the initial value and the trailing stop counter is reset), if an opposite signal happens the trade closes and reverses, etc. If your systems have complex enough logic or hour/day filters they will rarely be reset by signals in the same direction. The systems don’t have any trade chain dependency. Let me know if you have other questions about pKantu,

Also one more question for you if you don´t mind. You mentioned you have your own data-sets at Asirikuy with 1M data from 1987 to today. Can you let me know for which pairs you have the history from 1987 as 1M and which pairs start in later years (if any). Also, especially since I´ve never seen 1M data from 1987 in a good quality yet, is the data actually free of holes? Basically I am looking for a description of the data-set which I would get when I join. Thanks a lot:)

Data is 1M OHLC bid data for the following pairs: “EURUSD”, “USDCHF”, “EURJPY”, “USDJPY”, “GBPUSD”, “AUDUSD”,”AUDJPY”,”EURAUD”,”GBPAUD”,”GBPCAD”,”USDCAD”,”GBPJPY”,”EURGBP”. All of the data starts 01.Dec.1986 For EUR based pairs data before 1999 is for the DEM equivalent pair. I have passed the data through diagnostic scripts and it has no holes as far as I can tell. The data is in GMT +1/+2 format. Note that volume information is only available on the data since around 2014.

Yes it is hole free 1M data since 1986. However it is true that there are other issues that might affect data quality which I simply cannot guarantee are not present. Things such as filtering algorithms, aggregation techniques etc which might have been used by the data provider and I may be unaware of their use (since I cannot easily detect it). For this reason I still wouldn’t use it to simulate things like scalping systems or lower timeframe strategies (strategies below the 30M). For these having tick data is probably an absolute need.

That´s great to hear Daniel, I really wonder where that data is from, but of course that´s not my business. Because as far as I know, there is no other source than Olsen Data for such reliable 1M data from 1986.

Yes, aggregation and filtering, etc. may affect things, but that´s the same nowadays. OTC markets will never be the same between any broker, especially on the non-majors where feeds differ a lot more than on the majors.

For heavy scalping this might not be suitable, but for bar open systems that trail on bar open only as well and don´t have to small stop losses that might get hit on the first bar already and hence produce wrong backtests results, such data is fine still even for M5 systems – at least that´s my experience. Not saying that I have a working one on M5, but live trades always matched the backtests afterwards, so that is all fine if doing it this way.

Anyhow, I think you got me now, to many good things you have to offer there for the yearly price you are charging. So I am sure I will soon join as a member:)

Another question for you (hope you don´t mind the many questions) in terms of the flexibility of pKantu. Say I want to search for systems but use 3 of my computers (distributed over the internet). Can I start the main-task on one of them and it uses the resources (GPU + CPU) of the other 2 too by launching a “client only” module on these 2?

Thanks for writing. No problem, I’m happy to answer. When using pKantu each computer would need to perform a separate mining task, you cannot distribute mining tasks between different computers. Let me know if you have other questions,

I see, so there is no way to efficiently use several computers to perform one mining task – each computer would have to run it´s own one? That´s kinda to bad, it would make a lot more sense to distribute such tasks between various computers if you have many like I do. Is this a planned feature for the future?

I am also wondering how the cloud mining is possible then at all if pKantu can´t distribute tasks between several computers?

Thanks for writing. There is no plan to include this in the general pKantu release. For cloud mining we have a server-based instance management script that distributes mining jobs and then gathers results within a dedicated server. However this setup is not available to members, it is only implemented within our servers for the Asirikuy community’s cloud mining effort. If you want to carry out this task privately (cloud mining) you would need to develop your own setup to distribute pKantu jobs and gather/consolidate the results. Do let me know if you have other questions,

Thanks for writing and very glad to hear that :o) I have just sent you your login information. There is a lot to take in so feel free to take your time and post on our forum or email me directly if you have any questions or issues. I always answer emails within 24 hours. You can communicate with me directly from now on to avoid cluttering the blog’s commenting section (unless you want to comment something relevant to a blog post, which is also always welcome). Thanks for joining and welcome aboard,

thanks for the nice words as well, much appreciated and what I see so far is absolutely up to what I was looking for! Just got myself the M1 data from 1987, kinda amazed about the high quality, respect.

It also has already brought me a “ahh yess” effect since I was now able to backtest 2 EURUSD M30 systems, which I had generated with SQ on data from 2000 to 2015 and which did well going forward live so far, on data from 1987 till now, which equals a 13 years OOS test (yea, no real out of sample exists, but still, on “unseen” data) and got this:

Which shows that the strategies are not feed-dependent (they still do well on the new 2000 to 2015 data), are doing almost as perfect during 1987 to 2000 and did as excepted in live trading so far. Alone THAT find made it worth for me to join Asirikuy.com, so anything else coming from here for me now, is already “free” for me:)

I will go more in depth the following days, but so far everything seems clear and well documented. If anything comes up, I will post it on the Forum so that the knowledge can be shared with everyone else.

Thanks again and glad to be on board (you managed to convince me and I don´t regret it yet, alone the history data is worth the membership).

Great to hear that :o) Very happy to read that you’re enjoying our community! The historical data is definitely one of the great perks of joining our community but surely you will find many of our other tools useful as you become more acquainted with our content. I look forward to hear about your experience with them. Thanks again for joining and merry Christmas to you too,