Is it practical to recommend that people use Historical-Transactions recovery for all-cases?
No, the problem is that the OrderHistory length is set by the user and apparently cannot be changed by an EA. The history could be set to one day, for example, and that would probably mess with your requirements.
Correct. I had to reverify an old_post here. So using history is obviously a bad-idea for especially a commercial EA.
Added: But I guess the question still remains. For someone who thinks historical_setting is not a huge problem I'd still like to see your solution to the problem using order-info.
Well, everything have it's advantages and dis-advantages. Tho Global.Variable.Set() is un-documented and I've noticed that allot of career programmers do-not like un-documented features, I Love Global.Variable.Set(). Saving to Files is nice also but I'll only use them if I need to save Arrays. Going back to Global.Variable.Set(), in theory, sure it could fail to save information because most people would save Global.Variable.Set() at the End of the Start(). But this same argument could be used upon someone saving to file also.
I've scaled down the usage of Global.Variable.Set() and Global Variables in general within my programming for the sake of Memory efficiency. If not for proper Programming Ethics/Resources, I'd prefer to use Global Variables to Function-Calls because I can use Global_Variables within any function. Also while using Global_Variables it feels like I'm making a Function return multiple Values rather than 1. On the +Side for Global.Variable.Set(), I feel like I can inter-act with them easier within the Terminal.
Another reason I'd scale down the Global.Variable.Set() is because there can end up being too many variables to manage or within the view plain. But the two variables I've always have to keep are the Bank-High and Max_DrawDown%. As to the issue of "fail to save on incorrect system shutdowns/crashes". IMO it's a non-issue given the two variables above I like to save. Also, how often does a trading computer crash or gets shut down. If someone's using Global.Variable.Set() to save stuff like Buy_Signal==true instead of recalculating every-time then I see a potential problem.
Thats another good example of usage for Global.Variable.Set(). Just a reminder tho, someone else is going to point this out even if I don't ;). You can use Order_History/Order_Active_Info to get that information for the above case. So basically you just built a function looking at OrderOpenTime vs OrderProfit etc.
As far as that Scalper.... Good Luck ;)
- dabbler:A Post_message can change that.
No, the problem is that the OrderHistory length is set by the user and apparently cannot be changed by an EA. The history could be set to one day, for example, and that would probably mess with your requirements. - dabbler:Order History sort by closing date - MQL4 forum
Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it - ubzen:
The solution I'm thinking about seems similar to that of calculating MAE/MFE for orders.{//++++ Compute hiBal, loBal, RRR, int tickets[], nTickets = GetHistoryOrderByCloseTime(tickets); double tradePips[]; ArrayResize(tradePips, nTickets); double balances[]; ArrayResize(balances, nTickets+1); double pipsLost = 0., pipsWon = 0.; int nLost = 0, nWon = 0; double prevBal = AB; for(int iTicket = 0; iTicket < nTickets; iTicket++) if ( OrderSelect(tickets[iTicket], SELECT_BY_TICKET) ){ double profit = OrderProfit() + OrderSwap() + OrderCommission(), pips = profit / OrderLots() / perPipPerLot; balances[iTicket] = prevBal; prevBal -= profit; tradePips[iTicket] = pips; if (pips > 0.){ pipsWon += pips; nWon++; } else if (pips < 0.){ pipsLost -= pips; nLost++; } } balances[nTickets] = prevBal; int iHiBal = LocalExtremeArray(balances, MM.Lookback, 0, +1), iLoBal = ExtremaArray(balances, iHiBal+1, 0, -1); double hiBal = balances[iHiBal], loBal = balances[iLoBal]; if (nWon * nLost > 0){ double riskAve = pipsLost / nLost, rewardAve = pipsWon / nWon; win.rate = nWon; win.rate /= nWon+nLost; // FP divide RRR = rewardAve/riskAve; expectancy = (win.rate * rewardAve - (1-win.rate) * riskAve) / riskAve; } else{ win.rate=1.; RRR = 1.; expectancy=0.; } }//++++ Compute hiBal, loBal, RRR, makeUpPips
See my code
- dabbler:A Post_message can change that.
No, the problem is that the OrderHistory length is set by the user and apparently cannot be changed by an EA. The history could be set to one day, for example, and that would probably mess with your requirements.
Excellent! I have updated my copy of aswincmds.mqh
Thanks :-)
- dabbler:Order History sort by closing date - MQL4 forum
Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it
Obviously I know that and do that too. For example one script of mine finds the last 8 open orders (and then closes them).
However a simple test of
"now that I have no open orders, is my loss for today too great"
is very elegant as a balance compare against a previous balance. And by very elegant I mean one line of simple code.
But as I said, that is not a problem at the moment. The problem of getting a profitable EA is top of the list!
- dabbler:A Post_message can change that.
No, the problem is that the OrderHistory length is set by the user and apparently cannot be changed by an EA. The history could be set to one day, for example, and that would probably mess with your requirements. - dabbler:Order History sort by closing date - MQL4 forum
Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it - ubzen:See my code
The solution I'm thinking about seems similar to that of calculating MAE/MFE for orders.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Glancing over this Post. It reminded me of a process which I've taught I'd be able to code by now. It's about creating Experts which depend Entirely upon information stored on the Brokers servers. Example Order_Properties of Open/Closed orders. I have no problem with this design/approach, in fact I've frequently recommended the approach. But would OrderSelect() info work for recovery upon the average expert?
I'll give an example of a typical calculation I've included within most of my Experts for the past year. It's Account_Level Draw-Down. The code I've generally used looks as follows.
The variables with the t_ are Global_Variable_Set every tick. Now how could something like this be done using OrderHistory information?
I mean I have some ideas, but it seems very complicated when playing-back the process within my head alone. Not to mention the reluctance to fix whats not already broken and easier.
The solution I'm thinking about seems similar to that of calculating MAE/MFE for orders. You take the OrderOpenTime and the OrderCloseTime and OrderLots and OrderOpenPrice and OrderClosePrice and Point_Value. Then you look for the Minimum/Maximum Prices in Order Life-Span. But all this solves the Maximum Peak/Trot for a Single Order. In the case of Account_Level there could be multiple orders opened/closed simultaneously. With that, all I can think of a Summing the MAE/MFE's Looping++ from Left-Right. Does this sound about right or is there an Easier way?
Lastly, given the ease of Hard-Saving a variable vs Obtaining the answer from Historical-Transactions. Is it practical to recommend that people use Historical-Transactions recovery for all-cases?