Making a Python trading system for MT. - page 10
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I don't do optimisation and all sorts of parameter fitting and selection. A different methodology, but you need an environment like MatLab, R, SciLab, etc. Python is just as good.
I also don't need 10^6 bars. For everything - about 6, maximum 9 months on minutes is enough. Now the test is 3 months -2.5 m, though the system is not so complicated yet.
The longest one is learning ML, but there is nothing better than Python, and here it is only as a scripting language. Say, neural network response of 5 layers, about 60 neurons - 3-5 ms.
So far I don't see any real confirmation of the scaremongering.
No, I'm not in any way trying to scare or even to thicken the colors, the fact that you yourself write all the analytical infrastructure is already - super!
You are doing the right thing, I'm just thinking out loud about what I have faced and stumbled over myself, if you don't mind I won't get in the way))
No, I'm not trying to scare or even paint over the top, the very fact that you write all the analytical infrastructure yourself is super!
You're doing all right, I'm just thinking out loud about what I've faced and stumbled over myself, if you don't mind me getting out of the way)).
Yes, it's okay to communicate. Different opinions are fine. Opponents are always good).
Yes, we communicate normally. Different opinions are fine. Opponents are always good.)
Okay. Well then, what more can be said after reading https://c.mql5.com/3/236/Public.zip ...
I would certainly like structure and clarity, as long as the python is working on "divide and conquer".
As a minimum we need a clear separation into something like "interfaces" of datafeeds modules, their (datafeeds) analytics/forecasting, execution and analytics of trade results, ideally these modules should be independent
Abstracting from details, in main there should be at least four complex objects, data, models of these data, implementation (execution) of models to the market and the object of estimation of this activity.
In the simplest case the feed will simply be an array of candlesticks, the only subtlety of working with such a feed is to have a reliable protection of the models/execution/estimation modules from peeking into the future, the simplest model can be any indicator, such as RSI, stochastic, or neural network indicator, either modulated or in its pure form. It is an interpretation of forecasts into a trading signal and its idle/real execution, for example at crossing some levels of the forecast module, etc. And estimation is "testing", in fact the tester is just an idle run through the whole datafeed series, technically it is better to work with the current state of the market, model/execution/estimation modules as in reality, but it's much slower than issuing signals for the whole series and then running them separately in the tester, but there is a great danger of spying the future and getting unrealistic results.
PS: Now all the guru of Forex will throw at me, but I must say that in algotrading stoplots and trailing stops - a harmful technology, they are only for manual, episodic trading, in the case when you open a position for a lucky chance and go on a picnic, and when the AI continuously monitors the market, then act depending on your local drawdown makes no sense, no dependence of the future market movement on this at all and decisions of the AI should not be taken on this basis.
OK. Well then, what more can be said after reading https://c.mql5.com/3/236/Public.zip ...
You are attacking Public in vain. It's just a simple strategy template with a simple strategy on 2 MAs, trailing stop and tester. It should have a simple code where everyone can understand it, and nothing unnecessary. Besides, there is an opportunity to experiment with indicator strategies. And, if anyone starts modelling strategies in Python, this template can be edited and developed as needed.
In fact, it was originally designed as a test bed for testing various modules of the system and for further publication in this topic. In any case, it is not at all what you think it is. All in all, it's not what it looks like.
PS By the way, what makes you think your tester works correctly? The tester is a tricky thing....
"testing", in essence the tester is just an idle run through the whole datafeed row, technically it is more correct to work with the current state of the market, model/execution/estimation modules as in reality, but this will be significantly slower than if you immediately issue signals for the whole row and then run them separately in the tester, but this way there is a great danger of spying the future and getting unrealistic results.
This is an interesting question. It is also interesting because the forum is already producing legends about miracles of testing). Actually, that's why we need our own tester, which we can fully control.
What is a tester - it is just a loop that should inform the strategy about the number of a candle (or the number of something else, a tick, say) which the tester has to work with. In addition, the tester collects data about the state of the strategy and somehow systematizes them in the archive for further processing by the user. That's all. What is there to be afraid of? Even if the tester tries very hard, there is nothing he can do).
There can only be one reason for testing to be insidious - the strategy itself works with other data types in real life than in testing. For example, with ticks instead of candlesticks. And a fun life is guaranteed for us.
As long as we use only Open or only Close in a strategy and provided that only this and nothing else is used in real trading, we are not in danger (if there are no obvious errors, of course). But as soon as we try to use OHLCV in testing, we have a lot of opportunities to look into the future. First, HL has no time stamps, and secondly, the price within a candle can behave in any way it wants, and any assumptions about the price behaviour can only lead to distortions in the test.
In this kind of analysis we are very limited in what we can do, and in fact we can use OHLCV information only at the beginning of the next candle. Almost all we can do without risk is to close the trade if the price in the current candle goes below the stop. The stop, in doing so, should of course not change on the current bar.
ZS I assume this is the time to talk about tick testing ). I don't use ticks in testing, and I believe that analyzing ticks is analogous to trying to calculate the trajectory and movement parameters of an aircraft by measuring its fuselage vibrations and trajectory fluctuations.
Interesting question. It's also interesting because there are already legends about the wonders of testing in this forum). Actually, that's why we need our own tester, which we can fully control.
What is a tester - it is just a loop, which should inform the strategy about the number of a candle (or the number of something else, a tick, say) which the tester has to work with. In addition, the tester collects data about the state of the strategy and somehow systematizes them in the archive for further processing by the user. That's all. What is there to be afraid of? Even if the tester tries very hard, there is nothing he can do).
There can only be one reason for testing to be insidious - the strategy itself works with other data types in real life than in testing. For example, with ticks instead of candlesticks. And a fun life is guaranteed for us.
As long as we use only Open or only Close in a strategy and provided that only this and nothing else is used in real trading, we are not in danger (if there are no obvious errors, of course). But as soon as we try to use OHLCV in testing, we have a lot of opportunities to look into the future. First, HL has no time stamps, and secondly, the price within a candle can behave in any way it wants, and any assumptions concerning price behaviour can only lead to distortions in the test.
In this analysis we are very limited in what we can do, and in fact we can use OHLCV information only at the beginning of the next candle. Almost all we can do without risk is to close the trade if the price in the current candle goes below the stop. The stop, in doing so, should of course not change on the current bar.
ZS I assume this is the time to talk about testing on ticks ). I don't use ticks in testing, and believe that tick analysis is analogous to trying to calculate the trajectory and motion parameters of an aircraft by measuring its fuselage vibrations and trajectory fluctuations.
I agree with many, the tester needs its own, transparent and fast, the algorithm itself in the simple case (when only markets on the best(bid, sask)) is about 10 lines of code, but even in it you can shoot yourself in the foot. Well, for example, if you use the "instant execution" that is, to calculate the deal at the time of the signal, so it happens when a man took a candlestick, for example, one Klos and then took from this series which nibuya differences mashah and then on their turn again on klos (bid or ask) opened / closed a deal at the time of the signal, this error will give a slightly more positive result than the real, it will not be obvious. On the other hand, if we take the next candle to trade on the previous signal, the result will be significantly more negative than the real one. Classically, the signal is considered on options, and the trade is based on the slows of the same candle, but it is also not very good, practice shows that the signals are better on options, and transactions should be processed by the mean (H+L+C)/3, although some people mix them more cleverly.
By the way, everything is very respectable and acceptable if they are packed into "tick candlesticks", i.e. candlestick structures containing ticks which have passed between the open and the close, the indicator can be calculated by ticks and executed by ticks inside a candlestick, though IMHO it doesn't have much sense, the results will be quite similar.
But with the glass there is more difficulties and ambiguities, fortunately it concerns only those who uses the sums which can strongly dry up this glass and so it is possible without the glass.
I agree with many things, the tester needs its own, transparent and fast, the algorithm itself in a simple case (when only markets on the best (bid, ask)) is about 10 lines of code, but even in it you can shoot yourself in the foot. Well, for example, if you use the "instant execution", that is, to calculate the transaction at the time of the signal, it happens when a man took a candlestick, for example, one Klos and then took from this series which nibutuya differences mashah and then on their turn again on klos (bid or ask) opened / closed a deal at the time of the signal, this error will give a slightly more positive result than the real, it will not be obvious. On the other hand, if we take the next candle to trade on the previous signal, the result will be significantly more negative than the real one. Classically, the signal is considered on options, and the trade is based on the slows of the same candle, but it is also not very good, practice shows that the signals are better on options, and transactions should be processed by the mean (H+L+C)/3, although some people mix them more cleverly.
By the way, everything is very respectable and acceptable if they are packed into "tick candlesticks", i.e. candlestick structures containing ticks which have passed between the option and the close, the indicator can be calculated by ticks and executed by ticks inside a candlestick, though IMHO it doesn't have much sense, the results will be quite similar.
But with the glass there is more difficulties and ambiguities, fortunately it concerns only those who uses the sums which can strongly dry up this glass and so it is possible without the glass.
) In general, it is a deep modernization of the classic Stochastic Oscillator, but in spite of common genes, the descendant has very little in common with the classic Stochastic Oscillator. The mathematics is completely different, but the external similarity is obvious.
So far the indicator has been implemented only in Python. Its purpose is to determine the moment of entering the deal and as a part of its supporting mechanism. You can already see from the figure that it does this well and in time.
Of course, the indicator is not intended for use by itself, but only in symbiosis with other methods and indicators.
I think that maybe I should put the indicator in MQL and put it in the Market.
Those who read the topic From theory to practice already know that my system and A_K2's system are built roughly on the same ideology - channel work. The only difference is that mine was built a year ago. I've already written before, that now this strategy is implemented and tested in Python, with some minor changes, but there's no sense in launching it - nothing new is expected.
Since I had no ideas in particular, I've been developing all sorts of indicators - one of them is in the post above. I've made about ten of them. As the result I have decided to cross hedgehog with hedgehog: to combine work in the channel with trend following into one consistent system. I have not tried it as a whole yet, but I have practiced some elements. Everything seems to fit, but I still have some questions. I cannot say what will come out in practice, may be nothing. Let us wait and see.