High and low between OrderOpenTime() and OrderCloseTime()
For already closed trades, without keeping track of the tick data (+times), you are limited to the M1 resolution.
For currently open trades, and future trades you can track down the highs and lows and whatever data you need easy.
For already closed trades, without keeping track of the tick data (+times), you are limited to the M1 resolution.
For currently open trades, and future trades you can track down the highs and lows and whatever data you need easy.
Are there any functions in MQL4 that allow keeping track of tick data and times for closed trades generated by the tester? How about in MQL5?
BTW, what I'm working on is a script that runs from my EA's deinit() function that calculates MAE/MFE in $ and also in pips. Perhaps I should show specifically what I'm talking about with some code. Suppose I have this code that gives the highest bar between the order open and order close bars:
OpenBar=iBarShift(NULL,PERIOD_M1,OrderOpenTime(),false); //the order was opened on this bar CloseBar=iBarShift(NULL,PERIOD_M1,OrderCloseTime(),false); //the order was closed on this bar HighestBar=iHighest(NULL,PERIOD_M1,MODE_HIGH,OpenBar-CloseBar,CloseBar+1); //shift of bar with highest price between order open & close hiDollars=iHigh(NULL,PERIOD_M1,HighestBar); //returns the HIGH of bar found in previous line //if I replace this line: HighestBar=iHighest(NULL,PERIOD_M1,MODE_HIGH,OpenBar-CloseBar,CloseBar+1); //with this line: HighestBar=iHighest(NULL,PERIOD_M1,MODE_HIGH,OpenBar-CloseBar,CloseBar); /* It creates a problem IF the HIGH occurs during the "closeBar" (as often the case during price shocks such as NFP). However, by starting from "CloseBar+1" it avoids the problem of the MAE/MFE being MORE than the number of pips actually incurred IF fixed stops and take profits are being used (ie - S/L=50, T/P=100). But the downside is that some pips are shaved off the MAE/MFE and it loses some statistical precision and integrity along with it. It is not the true MAE/MFE. On the other hand, if I'm NOT using fixed S/L's and/or T/P's, then the HIGH that corresponds to the MAE/MFE may very well have been significantly higher than the closing price of the trade, if the trade was allowed to go on for some time, and then the price returned to a more favorable price. But, again, if that occurred during the "closeBar" the high of that BAR will be returned and NOT necessarily the high of the TRADE */
Do you see what I'm talking about? I can post a chart from the tester for clarification, if necessary.
I'm struggling with trying to make this work correctly. Again, thanks.
Hello outofdebt,
Within the second post, I believe 1005phillip is describing what you're struggling with.
https://www.mql5.com/en/forum/132675
Like zzuegg and everything seems to be suggesting.... Why can't you just track the lowest #-of-pips or profit during the order life during the back-test. Example: IF( orderprofit() < i_Last_Lowest_Order_Profit[array] ){ i_Last_Lowest_Order_Profit[array]==orderprofit(); i_Last_Lowest_Order_Pips[array]== orderopenprice()-ordercloseprice()* i_Pip2Real ; }.
Yeah, yeah this'll be more time consuming and resource consuming But there's a price to be paid for more accuracy. As far as mql5, maybe asking the mql5 forum would be better. Giving this some taught, there are 2 methods I can think of in terms of getting the exact mxe value within mql4, however they only apply if you program them in before the test or log some things during the test. 1) Is the method I described above tick-by-tick during testing or 2) Save the Volume as well to something like a csv file. That way you can always go back and calculate which tick-volume the trade closed upon.
The above methods would obviously not work for someone who want me to calculate their mxe based upon their Strategy Report for example. In that case they'll be limited to the m1 resolutions. Anyways, I'm much too lazy a programmer to code any of this anytime soon, as I simply could be concentrating more on how to make my current systems better.
I hope I made sense and you're not offended by my tone. Some people seem to think I grumpy lately :)
Hello outofdebt,
Within the second post, I believe 1005phillip is describing what you're struggling with.
https://www.mql5.com/en/forum/132675
Like zzuegg and everything seems to be suggesting.... Why can't you just track the lowest #-of-pips or profit during the order life during the back-test. Example: IF( orderprofit() < i_Last_Lowest_Order_Profit[array] ){ i_Last_Lowest_Order_Profit[array]==orderprofit(); i_Last_Lowest_Order_Pips[array]== orderopenprice()-ordercloseprice()* i_Pip2Real ; }.
Yeah, yeah this'll be more time consuming and resource consuming But there's a price to be paid for more accuracy. As far as mql5, maybe asking the mql5 forum would be better. Giving this some taught, there are 2 methods I can think of in terms of getting the exact mxe value within mql4, however they only apply if you program them in before the test or log some things during the test. 1) Is the method I described above tick-by-tick during testing or 2) Save the Volume as well to something like a csv file. That way you can always go back and calculate which tick-volume the trade closed upon.
The above methods would obviously not work for someone who want me to calculate their mxe based upon their Strategy Report for example. In that case they'll be limited to the m1 resolutions. Anyways, I'm much too lazy a programmer to code any of this anytime soon, as I simply could be concentrating more on how to make my current systems better.
I hope I made sense and you're not offended by my tone. Some people seem to think I grumpy lately :)
Yes, I have based my code around Phillip's MAE/MFE code. In fact, I have spent months dissecting it, and trying to verify it, understand it, and make it work for me. But, I ran up against a brick wall, and for the life of me, I just could not figure out certain parts of his script ... what it was doing and why. So, I decided to try to make my own simplified and scaled down version of it. (What a better way to improve my MQL coding skill than a project like this!?!?)
But, now I am beginning to see why his code seemed to do illogical and crazy things ... probably for the same reason(s) as I'm now discovering.
You have been helpful and your "tone" is fine. In the examples you provided, I recall there being similar code in Phillip's script ... that I eliminated in my version because it didn't make sense to me. Maybe I need to go back through it again, analyze it closer, and put it back in to eliminate the problems I'm having. (That's probably why it was in his code ... I'm starting to have that "A-HA moment" ... LOL)
I will try to go through this over the weekend and I'll post an update when (and if) I figure this out.
Thank you for taking the time to help.
Sure thing try keeping it simple. Phillip, WHRoeder and all the other great programmers around here are Awesome!! however I cannot comprehend all their codes back-then nor now for that matter of fact. And like I said to myself at one point, if I don't understand something in programming, its not the Other-guys fault nor a Bug. It's 99.99 percent My-fault, this attitude allows me to look harder for my mistakes instead of screaming Bug or Dumb and quiting.
I believe you can get mae/mfe stuff (for back-tester) using the simple format I outlined above and then save the value of the array to file.csv. I saw your codes on calculating mxe within the other thread .. and it's very impressive to say the least. I actually saved the link and would return to it if I'm ever looking for an example on how to calculate cross-rate value in account denominated currency .. but that's when I get there ... if I get there. I'm saving that one for multi-currency hedging or arbitrage strategies which mql4 cannot simulate.
Added: You'll need a simple Function for this instead of a Script.
Sure thing try keeping it simple. Phillip, WHRoeder and all the other great programmers around here are Awesome!! however I cannot comprehend all their codes back-then nor now for that matter of fact. And like I said to myself at one point, if I don't understand something in programming, its not the Other-guys fault nor a Bug. It's 99.99 percent My-fault, this attitude allows me to look harder for my mistakes instead of screaming Bug or Dumb and quiting.
I believe you can get mae/mfe stuff (for back-tester) using the simple format I outlined above and then save the value of the array to file.csv. I saw your codes on calculating mxe within the other thread .. and it's very impressive to say the least. I actually saved the link and would return to it if I'm ever looking for an example on how to calculate cross-rate value in account denominated currency .. but that's when I get there ... if I get there. I'm saving that one for multi-currency hedging or arbitrage strategies which mql4 cannot simulate.
Added: You'll need a simple Function for this instead of a Script.
*** UPDATE ***
OK, after spending *A LOT* of time going through Phillip's and Rosh's versions of this script, I have come to the conclusion that there just isn't a simple way to be more precise than PERIOD_M1 with the "CloseBar" of the MxE calculations of trades generated by the tester. Both Phillip's and Rosh's versions of this script have the same issue as me.
I spent some time researching this, and I can see a possible way that this could be more precise, but it would involve a script that collects tick data and writes it into a file, and another script to read the data from the file to be used for the MxE calculations. But, this gets exponentially more complicated and I just am not willing to put that much effort into it at this time just to get a little more accuracy for this one test statistic. There are plenty more test stats that I can use to evaulate and test my EA's.
To resolve this issue, I am just going to use the OrderClosePrice() if the MxE occurs during the CloseBar and I'm using fixed S/L's and T/P's. If not using them, I will just use CloseBar + 1 on PERIOD_M1 chart. It will be a little off and pips will be shaved of the MxE, but it won't be over. Perhaps I could add in a calcualtion that finds the average # of pips shaved off the MxE calculations, and add that to my final calculation in my Excel spreadsheet ... ???
Anyways, I am just leaving this as it is. It won't 100% accurate, but it looks like something I will just have to live with. (BTW, in MQL5, it is the same situation it won't make any difference)
*** UPDATE ***
OK, after spending *A LOT* of time going through Phillip's and Rosh's versions of this script, I have come to the conclusion that there just isn't a simple way to be more precise than PERIOD_M1 with the "CloseBar" of the MxE calculations of trades generated by the tester. Both Phillip's and Rosh's versions of this script have the same issue as me.
I spent some time researching this, and I can see a possible way that this could be more precise, but it would involve a script that collects tick data and writes it into a file, and another script to read the data from the file to be used for the MxE calculations. But, this gets exponentially more complicated and I just am not willing to put that much effort into it at this time just to get a little more accuracy for this one test statistic. There are plenty more test stats that I can use to evaulate and test my EA's.
To resolve this issue, I am just going to use the OrderClosePrice() if the MxE occurs during the CloseBar and I'm using fixed S/L's and T/P's. If not using them, I will just use CloseBar + 1 on PERIOD_M1 chart. It will be a little off and pips will be shaved of the MxE, but it won't be over. Perhaps I could add in a calcualtion that finds the average # of pips shaved off the MxE calculations, and add that to my final calculation in my Excel spreadsheet ... ???
Anyways, I am just leaving this as it is. It won't 100% accurate, but it looks like something I will just have to live with. (BTW, in MQL5, it is the same situation it won't make any difference)
I think you have also spread.....
You can't see the spread in history of prices
But the spread of your broker can have different values
Another point......
Slippage You allow some slippagge every trade to close or open a trade
this is for not getting requoted often
This is not calculated in histpory prices....
Conclusion from me It is possioble a little spread difference with history
I think you have also spread.....
You can't see the spread in history of prices
But the spread of your broker can have different values
Another point......
Slippage You allow some slippagge every trade to close or open a trade
this is for not getting requoted often
This is not calculated in histpory prices....
Conclusion from me It is possioble a little spread difference with history
RE: spread
You can insert it into the formulas with this:
MarketInfo(symbol, MODE_SPREAD)
// which will return the spread value at the time the trade took place
RE: slippage
You can use the order closing price that will include the slippage:
OrderClosePrice()
But, you are right, both of these will affect the accuracy of calculations in real time vs. trades generated by the tester. However, it would be possible to get a more accurate simulation by having a script read tick data values from a file. However, this will get very complex and since I am merely trying to generate test statistics that calculate MAE/MFE in this application, I'm not going to pursue this any further than just using:
CloseBar=iBarShift(NULL,PERIOD_M1,OrderCloseTime(),false) OpenBar=iBarShift(NULL,PERIOD_M1,OrderOpenTime(),false); //the order was opened on this bar HighestBar=iHighest(NULL,PERIOD_M1,MODE_HIGH,OpenBar-CloseBar,CloseBar+1); //highest bar between order open and close HighestBarTime=iTime(NULL,PERIOD_M1,HighestBar); //time of highest bar LowestBar=iLowest(NULL,PERIOD_M1,MODE_LOW,OpenBar-CloseBar,CloseBar+1); //lowest bar between order open and close LowestBarTime=iTime(NULL,PERIOD_M1,LowestBar); //time of lowest bar // which is accurate down to the PERIOD_M1 level. But if the high/low between order open and order close occurs in the // 'CloseBar' you will lose accuracy in the MAE/MFE calculations. There is no way around this without having the script // read tick data from a .CSV file and this will have to be synchronized with the tick data that the tester would be // using to generate trades during the backtests.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
I have a dilemma:
Since iTime() returns an integer value corresponding to the number of seconds since 1/1/70 (UNIX time), is it possible to break down and access OrderOpenTime() and OrderCloseTime() to the same level?
Suppose I am looking for the high or low value between the order open time and the order close time. If the high or low occurs in the SAME bar at the order close bar, the iHigh() or iLow() will return the HIGH or LOW of that bar, even if the order closed BEFORE the close of that bar. In other words, suppose the EURUSD HIGH (between order open and order close) occurs at 2011.12.15 09:44 (and 30 seconds) at a price of 1.30005. But the order closes at 2011.12.15 09:44 (exactly) at a price of 1.29990. Even using "PERIOD_M1" the iHigh() will return the price of 1.30005, even though the order closed at 1.29990 and was never open while the high (1.30005) of that one minute bar was hit.
MY QUESTIONS:
Hypothetically - What if we ONLY want to return the high that occured when the trade was actually open, but that high happened to be HIGHER than what the order was closed at, but LOWER than the high of the order close bar ... and all these events occurred in the SAME bar? (ie - 1.29991)
Are there any ways to get around this tricky situation? Or will the limitations of MQL4 prevent such a precision value to be returned? Thanks.
(NOTE: I am using just small increments here as an example; in reality, it would be more like amounts of 0.00100 or more, especially around NFP's and other price shocks)