EA programming issue
Mark,
I did not understand what you said, but I hope the guys at MT can get it.
The Step indicators have a problem, and maybe it is the reason that you tried to explain. I wrote an EA based on the Pluto method by Igor using those methods, but believe it or not, it did not work. I think maybe those indicators repaint the past.
I did not understand what you said, but I hope the guys at MT can get it.
The Step indicators have a problem, and maybe it is the reason that you tried to explain. I wrote an EA based on the Pluto method by Igor using those methods, but believe it or not, it did not work. I think maybe those indicators repaint the past.
Hi tradermaji,
Yeah, the Step indicator does repaint the paint, more precisely one value back
but I did put the faulty parts in comments. I have tried to synchronize the indicator
with the EA by computing values at the OPEN of the candle only and at the first
ticks of M1 timeframe :
for(shift=limit;shift>=0;shift--)
{
if (Time[shift] == oldTime) // If we're still within the same minute, just recopy
the previous values
{
UpBuffer[shift]=UpBuffer[shift + 1];
DnBuffer[shift]=DnBuffer[shift + 1];
continue;
}
... // Here we compute the new value
But this doesn't work, for unknown reason. I guess there is some extra information
I need to know in order to understand MT4 behavior better. But MT4 staff doesn't
seem to offer support on complex problems. I wrote to Igor too, but he never replied
to me...
Mark
You need to turn on your mind own. You must exactly to uderstand what you want realy.
I don't understand your problem, may be the problem is absent ?
Put code and try to explain - what is not working.
Put code and try to explain - what is not working.
I haven't posted to this forum to get insulted and it's not the role of moderators
to do it.
I've explained the problem clearly but given your approximate English, you seem to only speak Russian, which I don't.
Well, I'll try to find my answers elsewhere...
I've explained the problem clearly but given your approximate English, you seem to only speak Russian, which I don't.
Well, I'll try to find my answers elsewhere...
In general I have understood your problem. This problem is characteristic for Juric's
indicators. I resulted an example of alteration of one of indicators in Russian
article 15. Перевод индикатора из MQL-2 в MQL-4. I really not so well can speak on English , but language MQL44 I understand well.
You can publish a code of your indicator that I could cure it? Probably, my alteration
of your indicator will prompt you the decision for the further work.
Mark53, I believe the invocation of an indicator is the same regardless of whether
it is invoked directly when attached to a chart, or invoked via an EA.
The "closed-bar phenomenon" only applies to historic bars, which are processed when the indicator is first loaded. Or more precisely, when an indicator is attached to a chart, it is first invoked once for the purpose of producing the indicator values for past bars, and thereafter it gets invoked for every tick, as way of producing (and re-producing) the indicator value for the current bar (bar 0). As a result, the last bar 0 value is what survives when the chart is shifted to begin a new bar 0. However, it is up to the indicator programmer to decide which buffer values to set or change at every invocation.
When used by an EA, the indicator is invoked at most once for each tick, which is the first time the EA askes for a buffer value from it. In this case, the indicator is identified both by its "type" and by its parameters. I.e., for example, an iMA(3) is a different indicator (instance) from an iMA(57).
Now, when it comes to using an indicator from an EA, it tends to be that only historic buffer values are reliable, since in most indicators, the bar 0 value is recomputed for every tick. But, for instance, if you choose an iMA based on PRICE_OPEN instead of PRICE_CLOSE, then the bar 0 value is also reliable.
I agree it makes things difficult; it's all too easy for us to think solely in terms of bars, and forget or ignore that "the current bar" is under constant development. One way out is to make sure bar 0 is not used by the EA, but that it only considers bars 1 and up. Then you would typically add a time filter to its operation so that it would only make trade decisions at bar opening; trade management that depends on current situation would be performed at every tick, but the decision making about new trades would be done only at the first tick of a bar.
Alternatively, you have a two-parts decision logic, with bar-based history review using bars 1 and up, and a different situation assessment looking at the current time period of the current bar (which is in making). This would be the approach to use for longer time-frame methods, while the only-at-bar-opening approach fits the shorter time frames, perhaps even up to 30 minutes.
In any case, all but PRICE_OPEN of bar 0 of indicators are useless.
The "closed-bar phenomenon" only applies to historic bars, which are processed when the indicator is first loaded. Or more precisely, when an indicator is attached to a chart, it is first invoked once for the purpose of producing the indicator values for past bars, and thereafter it gets invoked for every tick, as way of producing (and re-producing) the indicator value for the current bar (bar 0). As a result, the last bar 0 value is what survives when the chart is shifted to begin a new bar 0. However, it is up to the indicator programmer to decide which buffer values to set or change at every invocation.
When used by an EA, the indicator is invoked at most once for each tick, which is the first time the EA askes for a buffer value from it. In this case, the indicator is identified both by its "type" and by its parameters. I.e., for example, an iMA(3) is a different indicator (instance) from an iMA(57).
Now, when it comes to using an indicator from an EA, it tends to be that only historic buffer values are reliable, since in most indicators, the bar 0 value is recomputed for every tick. But, for instance, if you choose an iMA based on PRICE_OPEN instead of PRICE_CLOSE, then the bar 0 value is also reliable.
I agree it makes things difficult; it's all too easy for us to think solely in terms of bars, and forget or ignore that "the current bar" is under constant development. One way out is to make sure bar 0 is not used by the EA, but that it only considers bars 1 and up. Then you would typically add a time filter to its operation so that it would only make trade decisions at bar opening; trade management that depends on current situation would be performed at every tick, but the decision making about new trades would be done only at the first tick of a bar.
Alternatively, you have a two-parts decision logic, with bar-based history review using bars 1 and up, and a different situation assessment looking at the current time period of the current bar (which is in making). This would be the approach to use for longer time-frame methods, while the only-at-bar-opening approach fits the shorter time frames, perhaps even up to 30 minutes.
In any case, all but PRICE_OPEN of bar 0 of indicators are useless.
Hi richplank,
From my own experience, indicators are not invocated the same way as I precised above. Indicators added to a chart are generated for each CLOSE value while indicators used from an EA are called at each tick. This is explained in MT4/MQL4 specifications. In most classic indicators (RSI, MAs, ATR, etc), this won't be problematical since all values calculations are independent from one another.
But there are cases where "historic buffers" (to take up your expression) won't be reliable. For instance, when the value of an indicator depends on a flag set by the previous call. According to the moment the indicator is called, the flag will be set or not within the same candle and this will interfere with the future values. I have mentioned the StepMAStoch indicator as an example but there are dozens. As you said, I tried to bypass the problem by generating a new value for my indicator only when a new candle is detected (see piece of code above) but this does not work. The only workaround would be to generate the indicator values at the CLOSE of each bar only. But that does not seem very easy to do.
The consequence of it is that my EA does not detect the indicator color changes at the very moment they are displayed on the chart... This makes things very approximative and risky. So far, that's the only real problem I've experienced with MT4. But that's a major one since it makes designing complex EAs almost impossible.
All the best,
Mark
From my own experience, indicators are not invocated the same way as I precised above. Indicators added to a chart are generated for each CLOSE value while indicators used from an EA are called at each tick. This is explained in MT4/MQL4 specifications. In most classic indicators (RSI, MAs, ATR, etc), this won't be problematical since all values calculations are independent from one another.
But there are cases where "historic buffers" (to take up your expression) won't be reliable. For instance, when the value of an indicator depends on a flag set by the previous call. According to the moment the indicator is called, the flag will be set or not within the same candle and this will interfere with the future values. I have mentioned the StepMAStoch indicator as an example but there are dozens. As you said, I tried to bypass the problem by generating a new value for my indicator only when a new candle is detected (see piece of code above) but this does not work. The only workaround would be to generate the indicator values at the CLOSE of each bar only. But that does not seem very easy to do.
The consequence of it is that my EA does not detect the indicator color changes at the very moment they are displayed on the chart... This makes things very approximative and risky. So far, that's the only real problem I've experienced with MT4. But that's a major one since it makes designing complex EAs almost impossible.
All the best,
Mark
Mark53:
Hi everyone,
There is a real problem linked with EA design. Most of us design an indicator and then build an EA to exploit it. But there's an intrinsic problem linked with that method. MetaQuotes shows an indicator by calling the start() method once a candle has been fully formed, i.e at the CLOSE value. Now, when an EA is running, the start() method is called at the beginning of each candle, i.e at the OPEN value. The result is that the view of the indicator and the values grabbed from it by the EA are unsynchronized... A workaround is to call the indicator on shift 1 from the EA. But things get worse when the indicator uses a buffer to store intermediate values and reads them to compute the new ones. If you run your EA in "all ticks" mode, then the values stored in the buffer will be correlated with all ticks ant not with the current candle. This makes the results of the indicator calls very different from what is showing on the screen. I haven't been able to solve that problem. The consequence of this is I've been struggling for months to try to use the fabulous StepMAStoch indicator coded by Igor (it's available for download on this site) from an EA. If some developers have managed to make an EA out of that indicator, I'm interested...
Thanks,
Mark
Is that why I get different results when DT-ZigZag-Lauer indicator is attached to a chart, than when I call the indicator from an EA? I've checked and re-checked the code to make sure I'm not making an obvious mistake. See code attachments.
Hi everyone,
There is a real problem linked with EA design. Most of us design an indicator and then build an EA to exploit it. But there's an intrinsic problem linked with that method. MetaQuotes shows an indicator by calling the start() method once a candle has been fully formed, i.e at the CLOSE value. Now, when an EA is running, the start() method is called at the beginning of each candle, i.e at the OPEN value. The result is that the view of the indicator and the values grabbed from it by the EA are unsynchronized... A workaround is to call the indicator on shift 1 from the EA. But things get worse when the indicator uses a buffer to store intermediate values and reads them to compute the new ones. If you run your EA in "all ticks" mode, then the values stored in the buffer will be correlated with all ticks ant not with the current candle. This makes the results of the indicator calls very different from what is showing on the screen. I haven't been able to solve that problem. The consequence of this is I've been struggling for months to try to use the fabulous StepMAStoch indicator coded by Igor (it's available for download on this site) from an EA. If some developers have managed to make an EA out of that indicator, I'm interested...
Thanks,
Mark
Files:
dt-zz-lauer-ea.mq4
2 kb
dt-zigzag-lauer.mq4
4 kb
Bad necro, bad, bad necro...
As a summary of what i think is the stated problem, the current value of (most) indicators varies during the current bar
If your EA needs to act during a bar rather than just at the end of a bar, consider storing the indi values in an array during the bars progress
This is particularly useful when using an indicator on e.g. the W1 to decide a trade for an EA working off the H1 chart
FWIW
-BB-
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
There is a real problem linked with EA design. Most of us design an indicator and then build an EA to exploit it. But there's an intrinsic problem linked with that method. MetaQuotes shows an indicator by calling the start() method once a candle has been fully formed, i.e at the CLOSE value. Now, when an EA is running, the start() method is called at the beginning of each candle, i.e at the OPEN value. The result is that the view of the indicator and the values grabbed from it by the EA are unsynchronized... A workaround is to call the indicator on shift 1 from the EA. But things get worse when the indicator uses a buffer to store intermediate values and reads them to compute the new ones. If you run your EA in "all ticks" mode, then the values stored in the buffer will be correlated with all ticks ant not with the current candle. This makes the results of the indicator calls very different from what is showing on the screen. I haven't been able to solve that problem. The consequence of this is I've been struggling for months to try to use the fabulous StepMAStoch indicator coded by Igor (it's available for download on this site) from an EA. If some developers have managed to make an EA out of that indicator, I'm interested...
Thanks,
Mark