Could EA Really Live By Order_History Alone?

Ubzen
5301
Ubzen  

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.

//~~~~~~~~~~MaxDownX-Function:
void MaxDownX(){
    if(OrdersTotal()>0){
        double DrawDown$=t_BankHigh-Acc_Equity;
        if(DrawDown$>0 && t_BankHigh>0){
            if((DrawDown$/t_BankHigh)*100>t_MaxDownX){
                t_MaxDownX=(DrawDown$/t_BankHigh)*100;
}   }   }   }

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?

dabbler
1091
dabbler  
ubzen:

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. (EDIT: Order History length can apparently be changed by a PostMessage. See WHR's post further down)
Ubzen
5301
Ubzen  
dabbler:
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.

dabbler
1091
dabbler  
I think there is a problem with the global global variables that are saved to disk. I have never used them but I understand from posts of others that they can fail to save on incorrect system shutdwns/crashes. I do use OrderHistory myself but in "batch mode". In other words I manually set the history length then run a script to plot all trades, for example. I wouldn't like to comment about using OrderHistory on a live EA. Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it, which gets a bit long winded when you are doing 6 months worth of data.
Ubzen
5301
Ubzen  

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.

dabbler
1091
dabbler  
I have certainly considered using a Global_Variable to hold the account balance at the start of the day so that an errant scalper could shut itself down if it was loosing badly on the day, but since I have as yet to create a profitable scalper the other bit is not yet necessary!
Ubzen
5301
Ubzen  

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 ;)

William Roeder
24277
William Roeder  
  1. dabbler:
    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.
    A Post_message can change that.
  2. dabbler:
    Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it
    Order History sort by closing date - MQL4 forum
  3. 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
1091
dabbler  
WHRoeder:
  1. dabbler:
    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.
    A Post_message can change that.

Excellent! I have updated my copy of aswincmds.mqh

Thanks :-)

dabbler
1091
dabbler  
WHRoeder:

  1. dabbler:
    Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it
    Order History sort by closing date - MQL4 forum

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!

Ubzen
5301
Ubzen  
WHRoeder:
  1. dabbler:
    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.
    A Post_message can change that.
  2. dabbler:
    Using OrderHistory the first thing I do is sort it into a sensible order (like last closed orders) before using it
    Order History sort by closing date - MQL4 forum
  3. ubzen:
    The solution I'm thinking about seems similar to that of calculating MAE/MFE for orders.
    See my code
Thanks allot WHRoeder. Now I can hopefully be truly Global.Variable.Set Free.