Is there a "How MT4 really works" manual? - page 2

New comment
 

The issue is around getting the H1 RSI part-way through a historic hour at the end of an M15 bar. Why would anyone wanna do that lol. IMO that's like trying to get the Bar[0] value for H1.

Therefore, against a historic M15 bar running from 13:30 to 13:44, the indicator is going to plot an H1 RSI value from 13:59 . Big logical error. As they've got no business plotting the data Except for Once per Hour.

Would they have this same error if they plotted the data at the Top of the Hour 00:00? I'm guessing not.

Thats why in my example, I drew the line on the hour instead of at 12:24.

In multi-timeframe if you're looking at M15___RSI for 13:30 to 13:44. You cannot look at 13:00-13:59 Hour RSI to base your trades. That'll be looking at Current-Bar Info. Heck, I don't even recommend looking at 13:30 to 13:44 if the current time is 13:44. You should be looking at 13:15 to 13:30. vs the Previous Hour's RSI (H1 value from 12:00 to 13:00).

IMO, if you're trading a multi-timeframe strategy, you're in effect trading the Highest-Time frame of the multi-timeframe. All your entry signals should be based on the Previous Bar value of Highest TF. If the smaller guys happens to agree then - confirmed; not the other way around.

 
ubzen:

The issue is around getting the H1 RSI part-way through a historic hour at the end of an M15 bar. Why would anyone wanna do that lol. IMO that's like trying to get the Bar[0] value for H1. Therefore, against a historic M15 bar running from 13:30 to 13:44, the indicator is going to plot an H1 RSI value from 13:59 . Big logical error. As they've got no business plotting the data Except for Once per Hour. [...]

My personal opinion isn't necessarily different to your personal opinion, but the possible logic becomes a little clearer if - keeping the principle the same - it's a question of an M15 indicator or EA where you "don't want to go against the daily trend", i.e. comparing M15 and D1 rather than M15 and H1.

If you don't use interim D1 values then, by 11:45pm each day, there can be substantial recent price action which you're ignoring, and the signal from your indicator (or the behaviour of your EA) can suddenly and massively switch as the time goes from 23:59 to 00:00.

Taking an even more extreme example, I know people who are basically trading (manually) off an M5 chart, but with an eye always on the D1 trend. If you've got an indicator or EA running on an M5 chart, then if it's only using the last complete D1 bar, that's anything up to 287 M5 bars ago.
 

Always JJC your insights are much appreciated. I Agree fully with the above statements. At least now I understand how people are getting re-paints on their Multi-Timeframe indicators. As for the issue of losing too much information on completed D1 Bars.... because you're using old value 22 Hours later; I say you toke it too far but not far enough. Some people don't even like losing info on M1[0] Bars because they're still looking at M1[1] Bars during a News Spike. I'm sure you're aware of what happens to indicators and back-tests trying to simulate a trade within that environment based on M1 H-L-O-C.

 

Thanks for the excellent discussion, gents. (<-- assumption :))

I understand the issues of e.g. intra-bar price action hitting stops. If you have multiple stops that can be hit within one bar, there is no way for MT4 to determine which one gets hit first -- short of looking at a lower timeframe. Not to keep harping on TS, but it's what I know best -- in TS they've actually added the ability to do exactly that, to look "inside" the bar. So e.g. you could be running a system (EA) on M30 bars, but tell it to resolve fills using M5 or M1 or even tick data. Assuming you have those lower timeframes in your database, TS can use it to correctly determine which stop got hit first. But that's "cheating." :) I don't expect MT4 to do that. I don't even usually use it in TS. If I need finer resolution, I move to a lower timeframe.

BTW I realized I misspoke. In particular in the multi-timeframe case, TS *can* look different in history than in realtime. TS handles MTF by placing multiple data streams (e.g. M5, M15, H1) on the same chart, and then your system accesses the appropriate data stream. But if you do that on historic data, you'll see the results of the *completed* higher-TF bar, which is essentially looking into the future just like the MT4 higher-TF functions. So in that case, TS does have the same weakness as accessing higher-TF data in MT4.

There is no easy way round this in MT4. In order to calculate the true historic RSI on the higher timeframe, you have to (a) manually build your own H1 bar data with the correct interim value for the last of the bars, and then (b) do your own RSI calculation on this special bar series.

That's precisely what I did. The indicator I was experimenting with calculated Heiken-Ashi bars on the data, then you used the standard "HA trend must line up on 3 TFs" logic to make manual trading decisions. I calculated the HA on bar 0 by using what I had so far. So e.g. for the M15 HA value in bar 0, I'd calculate the intermediate HA with the ticks as they arrived, using bar 0's Open, the highest/lowest ticks so far, and the current Close. Obviously the bar 0 value could change as new data came in.

Then I did a similar thing with the higher TFs in historic bars, but instead of using realtime ticks as they arrived in realtime, I used lower-TF bars that comprised the higher-TF "super-bar." So say I was calculating this on M15-H1-H4 on historic M15 bars. On the 08:00 M15 bar I calculate HA using the 08:00 OHLC, and that's the M15 value. The H1 value would be the same, since the H1 "super-bar" contains the same OHLC data (so far) as of the 08:00 M15 bar. Then on the 08:15 bar I calculate a new M15 HA for that bar using the 08:15 OHLC. But for the H1 HA I calculate it using the 08:00 Open, the 08:15 Close, and the highest high / lowest low in the two bars. I continue doing this on each bar, calculating a "current so far" H1 HA for each M15 bar. (Including on bar 0 -- for example for the tick that arrived at 08:35 I used the 08:00 open, the bar 0 close, and the highest high / lowest low since 08:00.) At the end of the 08:45 bar I've calculated 4 different intermediate (well 3 intermediate and one final) H1 HA values, and displayed all of them on the indicator. Those 4 HA values are calculated on historic M15 data, but they are equivalent to "snapshots" of the HA values you would have seen in realtime at 08:15, 08:30, 08:45, and 09:00 if you calculated HA on an H1 bar. The resulting historic chart looks exactly like it would have in realtime, so it's safe to visually backtest a strategy based on closed bar-1 data. Obviously you can't visually backtest based on intermediate M15 bar-0 values but you generally shouldn't be making trading decisions based on that anyway IMHO.

I can post that code if anyone's curious. I don't claim it's a great example but it might be of interest.

 
garyfritz:

I understand the issues of e.g. intra-bar price action hitting stops. If you have multiple stops that can be hit within one bar, there is no way for MT4 to determine which one gets hit first [...]

There are 3 separate topics here:

A. Simplifying slightly, MT4's strategy tester (i.e. backtesting) will use M1 data if it can get it (and then invent a series of individual ticks within each M1 bar according to a complex set of rules). It's actually possible to load real historic tick data into the backtesting if you feel that's important.

B. Within the backtesting environment, access to higher timeframes is modelled correctly. An EA which is being backtested on e.g. the H1 timeframe cannot see into the future beyond the current backtesting date-time by e.g. examining D1 data. The crystal-ball issue only applies when trying to perform retrospective as-at calculations, whether that's for display purposes within an indicator or some equivalent complex set of trading rules in an EA.

C. As a partial exception to B, you can manually add indicators to the chart for a visual-mode backtest, i.e. for additional visual confirmation, unrelated to what the EA is doing. These indicators slightly break the backtesting sandbox; they can see future data by querying higher timeframes. But this doesn't affect the EA being backtested.

 
jjc:

There are 3 separate topics here:

...Might be worth spelling out B and C for future reference. If you do a backtest of the following EA (in visual mode, so that you can the results):

void start()
{
   double PeriodList[] = {PERIOD_M1, PERIOD_M5, PERIOD_M15, PERIOD_M30, PERIOD_H1, PERIOD_H4, PERIOD_D1};
   string strComment = "";
   for (int iPeriod = 0; iPeriod < ArraySize(PeriodList); iPeriod++) {
      double vClose = iClose(Symbol(), PeriodList[iPeriod], 0);
      strComment = StringConcatenate(strComment, "Period #" , PeriodList[iPeriod], ": ", DoubleToStr(vClose, 8), "\r\n");
   }
   Comment(strComment);
}

...then the latest price reported on all timeframes is the same value: the current simulated price. The EA does not have the ability to see future prices outside of the backtesting sandbox.

However, if you run a visual-mode backtest of an EA, such as the following dummy one:

void start() {}

... and you manually add the following custom indicator to the visual-mode backtesting chart:

#property indicator_chart_window
void start()
{
   int OpenTimeOfCurrentTimeFrame = Time[0];
   int OpenTimeOfCurrentD1Bar = iTime(Symbol(), PERIOD_D1, 0);
   Comment("Current timeframe Time[0]: ", TimeToStr(OpenTimeOfCurrentTimeFrame), "\r\niTime(D1, 0): " , TimeToStr(OpenTimeOfCurrentD1Bar));
}

... then the indicator can see into the future on higher timeframes. The value of Time[0] will be correct, i.e. the open-time of the current simulated bar, but the time reported for D1 will be today's date rather than the simulated date. This doesn't affect the performance of a backtested EA, but it does affect the ability to verify what an EA is doing by adding a separate indicator to its backtesting chart.

12
New comment
Reason: