a trading strategy based on Elliott Wave Theory - page 291
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
And in this case the conditions of the experiment do not allow us to consider these results as evidence of a statistical advantage.
Ok.
"SL<MO" what is MO?
And another question, how to optimise SL, at least in a nutshell? Designate it as an external parameter, i.e. one SL for all trades?
The only thought is that it is hard to judge from these results, the conditions of the experiment are not right.
The new results are even less revealing. There are no statistics after all !
Out of 21 months of testing 10 are over sitting.
You are not claiming that your system is not wrong. So put a stop 20 and see what happens. At least statistics will appear.
And do not think that what we are writing here is a criticism of the trading Expert Advisor. In general, as a criticism.
By the way, switching to all ticks has led to decrease of MO from 38 to 23. This is not a bad result.
It would also be interesting to compare the same figures, but with stops in both cases.
MO is the mathematical expectation of gain.
SL can be optimized very simply. Output it as an external parameter and run optimization in the tester, setting the limits and step. Of course, in the code of the Expert Advisor you must add the condition of closing a position when the price falls below SL for buy and vice versa for sell.
The only thought is that it's hard to judge from these results, not the conditions of the experiment.
The new results are even less revealing. There are no statistics after all !
Of the 21 months of testing, 10 are over-sitting.
Yuri, I'm not at all flustered, not offended and it's perfectly fine. :о)))) MathCAD doesn't have a 10 month overshoot because it has code that doesn't allow such deals, but for other considerations. In terms of the model, 10 months of over-sitting is not a mistake. Nothing "terrible" happened for the model - the price was sitting in the channel (dangling from the edge). Incidentally, because of cases like this, I started trying to predict the trajectory itself.
You are not claiming that your system is not wrong. So put a stop 20 and see what happens. At least the statistics will appear.
I do not pretend, though I have not found any obvious errors yet - during the channel life the price passes the calculated level. But for sure they will appear sooner or later, I have no illusions, the model has some weak points.
Probably, I will deviate from my plan and use stops. I still rely on your advice, since I'm looking at MT now like a Neanderthal on a calculator. In matcad, it's simple - formulas as they are. :о)
Feel free to ask, at your service.
But for me it's vice versa. :-))
However, now I'm not looking at matcad, but at matlab. And no longer as a Neanderthal, but as a Cro-Magnon.
Two more points:
- In principle it is normal to expect a correlation between position holding time and profit value. On small times it seems to be there (by eye, I can be wrong). But on longer times (again "by eye") the situation looks more random. But randomly there should be small pluses as well as small minuses. And there are no minuses. Are there no occasional "adjustment" outputs in the code?
- Almost any strategy has periods of "applicability" and "non-applicability". If overshooting masks the "not applicable" period, introducing stops could be a disaster for the report. And non-adoption can be disastrous for the actual account.
Must count it. If not the first time, then the second time. You can see how it happens on the video - https://www.mql5.com/zh/forum/103424
So there is an automatic recalculation? But as far as I understand, there is no synchronisation of quotes with the broker's time. Ok, if we are talking about combining two long pieces, then the time jump at the junction, say an hour, will not be of principle importance. But what if the original story is a set of pieces and loading quotes fills in the holes? That would be a nice mix.
After loading the history myself, I immediately transferred it to the standalone terminal and did not mix it with anything.
I decided to broaden my answer a bit. Below you can see the statistics of channels lifetime (eurusd, hours) performed as follows: I fix channel length, move together with time, build a fixed length channel for each "current" bar and estimate its lifetime (by looking into the future, of course). At the same time I collected all sorts of additional parameters of the channels. In this particular case the channel has a length of 300 counts.
Of course, it is inferior to wavelet transform pictures, but pay attention to the very form of the curve (it persists for other periods and quotes), the channel almost immediately takes a stable position, i.e. a peak follows first, and then the duration decreases, but not vice versa, though it would be more logical to expect exactly such a picture. You can see that some channels live quite long, about 3.5 of their length (let me remind you that when looking into the future, the channel parameters don't change). Now, I do not know what the price trajectory is during this time, but it is almost sure that during the channel existence, the price will pass through the calculated level, of course, if additional criteria work, including the Hurst index. It can happen in 20 minutes, it can happen in a few days, it can happen in a few months. Of course, this is one of the unpleasant features - either believe or refuse the trade or allow a loss. Similar features in terms of degree of "unpleasantness", can be found in sufficient number in any other strategies and models.
In this model I'm not looking for a reversal area (other models are for this purpose). The core model code in MathCAD takes a few lines, and the code that blocks 10 month trades takes a few hundred lines. So, first tests of this model showed 20% of losing trades (after blocking), now it's 2% in MathCAD, it remains to be seen what will happen in MT.
By the way, the shape of the curve itself is useful. If you collect statistics (you may have already collected them) you will be able to classify extremums (either based on common sense or resorting to professional systems), and by looking at its shape near the current reference point (by backtracking a channel) you will be able to estimate the time of channel existence with a high degree of reliability.
In general, channels make a lot of sense... but that's just a philosophy.
to Candid
Two more points:
- In principle, it is normal to expect a correlation between position holding time and profit value. It seems to be present at small times (by eye, I can be wrong). But on longer times (again "by eye") the situation looks more random. But by chance there should be small pluses as well as small minuses. And there are no minuses. Are there no occasional "adjustment" outputs in the code?
- Almost any strategy has periods of "applicability" and "non-applicability". If overshooting masks the "not applicable" period, introducing stops could be a disaster for the report. And non-adoption can be disastrous for the real account.
Exactly for the reason that it's still early (the test is philosophical) I was wiggling like a Marquesan boat when Yuri had me with SL to the wall. And practically talked me into SL with a kind word and a gun. :о)
By the way, I was not using Stop Loss as an order parameter before and implemented it via controlling an open position, since the conditions are always changing.
to Yurixx
Yuri, please help me with SL. :о)
As I wrote earlier, never used SL, but used dynamic order control. Probably not very convenient because the system has to be connected to the server all the time, but in my opinion it makes more sense.
I vaguely remember that I had some problems with SL (it was about a year ago), or my brokerage company didn't allow to place them too far away or something else. Anyway, I looked through the documentation and "remembered" that it was the price level at which the order was closed. Ok, I told myself and entered the following parameters for SL depending on order type:
Bid-20*Point
Ask+20*Point
Not a single trade, now I try to understand why, or rather to request the error code. I have entered a few more options, but no deal. Eventually I got fed up with it and specified SL price level 20.0, it worked:
Like in that cartoon "I don't understand anything". Yuri, explain to the dinosaur how to set them correctly, and why the value of, say, 1.2 is worse than 20.0
1. You can not put SL at all, but dynamically control the price level yourself and "close" the trade in the right case. It's all symbolism, not trading. It is only gathering of statistics. But in this case everything must be done manually, not using a tester. So, we just need to write a script that runs through the history implementing the strategy and collecting the results in a file. There is nothing difficult, because 95% of the script is your Expert Advisor's text.
2. If you use the tester, then SL should be set in the orders you place, as it is done in the real world. What you have written I still do not understand what the problem is. The easiest way to solve it is to cut out the code snippets where you declare, define and use SL and put them here. Maybe the problem is in normalisation (all prices in orders should be normalised, i.e. rounded to Point accuracy). By the way, if you explicitly specified 20.0, then that is exactly the normalised value. And 20*Point is not. If you had set it explicitly to 1.2, that would work too (for buy). Try this:
Bid-20.0*Point
Ask+20.0*Point
However, once again: Bid,Ask can also be non-normalized.
That's what I'm going to do, as they call it, as always.
2. If you use the tester, then SL should be set in the orders you place, as it is done in the real world. From what you have written I do not understand what the problem is. The easiest way to solve it is to cut out the code snippets where you declare, define and use SL and put them here. Maybe the problem is in normalisation (all prices in orders should be normalised, i.e. rounded to Point accuracy). By the way, if you explicitly specified 20.0, then that is exactly the normalised value. And 20*Point is not. If you set it explicitly to 1.2, that would work too (for buy)
The problem is that it gives error code 130 - wrong stops. :о)
How tricky it is. Is there any function that just rounds the number to 4 decimal places?
Now, I don't know what the price trajectory will be during this time, but it is almost certain that during the channel's existence, the price will pass the calculated level, provided of course that additional criteria work, including the Hearst index. It could happen in 20 minutes, it could happen in a few days, it could happen in a few months.
So, the channel did not break down during that 10-month trade (at this drawdown)? It was a powerful channel, though :)
Ok, I said to myself and entered the following parameters for SL depending on the order type:
Bid-20*Point
Ask+20*Point
Not a single trade, now I am trying to understand why, or rather to request the error code.
Look at the log, if OrderSend does not work, there is a record of the reason.