Slopey Graeme: another pipEasy-inspired trend trading EA

[SteveHopwood]

Good catch. Yeah, the sequence of events after bringing up the Expert Properties is a bit of a mystery. Personally, I think it should do a complete restart of the application, but all it seems to do is allow you to modify the externs and then it runs deinit() followed by init(). It doesn't reset global variables to their initial values (as shown here) and doesn't reset static variables in any procedures.

George

I tell people to forget the F7 key exists. We should always make changes to inputs by dragging a fresh instance of an ea onto a chart - never when the bot has trades to manage and only after temporarily disabling EA's.

Even better, wait until the weekend.

[MichaelM]

Just wondering how everyone is tracking with Graeme?

My version of G now has two "legs" both at +100pip JSL, with four more possibilities at BE

[SteveHopwood]

Hi Steve,

Been playing around with the Risk based lot size code.

I've got it working for G so that the lot size is always divisible by 2:

Add the following external variable:

Code: Select all

extern int     LotDivider = 2;   // <<---- MichaelM ADD (don't change the value for Graeme!)

...then UNcomment the "Stop Loss calculator" line in both HasBuyFilled() and HasSellFilled()
i.e. HasBuyFilled()

Code: Select all

//Stop loss calculator
if (StopLoss > 0) stop = NormalizeDouble(price - (StopLoss * Point), Digits);  // <<---- MichaelM MOD (removed comment symbols)

...then add the following line after the "Risk based lot calculator" line as follows

Code: Select all

//Risk based lot calculator
if (RiskPercent > 0) SendLot = CalculateLotSize(stop, price);
stop = 0;  // <<---- MichaelM ADD (To preserve the hidden SL feature)

...and finally modify the CalculateLotSize function as follows:

Code: Select all

double CalculateLotSize(double price1, double price2)
{
   //Calculate the lot size by risk. Code kindly supplied by jmw1970. Nice one jmw.
   
   if (price1 == 0 || price2 == 0) return(Lot);//Just in case
   
   double FreeMargin = AccountFreeMargin();
   double TickValue = MarketInfo(Symbol(),MODE_TICKVALUE) ;
   double LotStep = MarketInfo(Symbol(),MODE_LOTSTEP);
   
   double SLPts = MathAbs(price1 - price2);
   SLPts/= Point;
   
   double Exposure = SLPts * TickValue; // Exposure based on 1 full lot

   double AllowedExposure = (FreeMargin * RiskPercent) / 100;
   
   int TotalSteps = ((AllowedExposure / Exposure) / LotStep);
   double LotSize = TotalSteps * LotStep;
   
   /** MichaelM ADD START **/
   if (LotDivider > 0) {
     TotalSteps = MathFloor(TotalSteps / LotDivider) * LotDivider;
     LotSize = TotalSteps * LotStep;
   }
   /** MichaelM ADD END **/
   
   double MinLots = MarketInfo(Symbol(), MODE_MINLOT);
   double MaxLots = MarketInfo(Symbol(), MODE_MAXLOT);
   
   if (LotSize < MinLots) LotSize = MinLots;
   if (LotSize > MaxLots) LotSize = MaxLots;
   
   return(LotSize);

}//double CalculateLotSize(double price1, double price1)

To see the actual lotsize G wants to use, modify the EA comments code as follows:

Code: Select all

/** MichaelM MOD START **/
if (RiskPercent > 0) {
   ScreenMessage = StringConcatenate(ScreenMessage,Gap, "Lot size based on ", StopLoss, " points and ", RiskPercent, "% risk: ", CalculateLotSize(Bid, Bid+(StopLoss*Point)));
} else {
   ScreenMessage = StringConcatenate(ScreenMessage,Gap, "Lot size: ", Lot);
}
ScreenMessage = StringConcatenate(ScreenMessage," (Criminal's minimum lot size: ", MarketInfo(Symbol(), MODE_MINLOT), ")", NL);
/** MichaelM MOD END **/

Michael, when I came to look at this tonight, I realised you are talking about uncommenting the stop loss calculator.

I left StopLoss in the code only in case it is needed in the future, but it plays no part in this EA - I have learned from experience not to delete regular code until there is clearly no need for it. StopLoss is there but commented out in case 300 people suddenly demand a stop loss. I did not comment it out to save having to comment out a whole lot of extra code - another regular practise of mine.

No disrespect, I promise, but given that you did not understand this I am reluctant to adopt your further suggestions in case you are complicating thingies that do not need complicating. Instead of ensuring that risk-based lot sizes can be divided by 2, which demands an extra input, how about ensuring that the trade half-closure code in bool LookForTradeClosure(int ticket) is modified so that the bot knows what portion of the trade it is allowed to close before attempting to do so, by using a NormalizeDouble moderation based on the number of numbers after the decimal point indicated by Mode_Lotstep? This is my normal solution in similar situations.

Cheers

[MichaelM]

No worries Steve, it is your code and your thread.

I just published that code in case anyone else wanted risk based lot sizes.
I have been using it successfully on demo.

As for your concern about uncommenting the Calc SL code, you will notice my comment where I say something along the lines of "to preserve the hidden SL feature".
Yes, I am using risk based lot sizes while preserving the hidden SL feature

On another note, how is your direction assisted RSI trend detection tracking?
Any "legs" or trades at BE yet?
Can I suggest you add a myfxbook signature, to save me from bothering you with this question?

Cheers,
MichaelM

[SteveHopwood]

On another note, how is your direction assisted RSI trend detection tracking?
Any "legs" or trades at BE yet?

G started brilliantly. At his height, he could have closed the basket of trades at about +3%.

Since then, he has given back everything plus some more, and has just started to claw something back at the end of this week.

So, jury still out for now. Mind, the test is slightly unfair because I leave EA's to trade on demo unmolested - an idea that every one of my Serious Warnings dismisses as impossible to do successfully.

[SteveHopwood]

Latest update in post 1.

I have added Michael's fix to allow risk-based lot sizes to half-close. Cheers Michael.

Can you do me a favour, please, and look at this snippet from void CaterpillarTrailingStop(int TradesToCheck)

Code: Select all

         //Got this far, so Cat owns the trade and the stop needs moving.
         //Calculate the shift back from current candle to the candle open time of the previous cts move
         //Michael, can this little lot be replaced by iBarShift(NULL, CatTimeFrame, ctime, false);?
         shift = 0;
         ctime = GlobalVariableGet(CsGvName);
         while (iTime(NULL, CatTimeFrame, shift) > ctime && shift < iBars(NULL, CatTimeFrame))//Can probably replace this with iBarShift
         {
            shift++;
         }//while (iTime(NULL, CatTimeFrame, shift) > ctime && shift < iBars(NULL, CatTimeFrame
         //Point to the next candls
         shift--;
         //This is an attempt to stop the final trade in the sequence having its stop moved too early, because
         //this can result in it being stopped out as soon as it is opened
         if (shift < 2) continue;

I coded this before discovering iBarShift. If UseCaterpillarTS is enabled, then CountOpenTrades creates a Global Variable with the ticket number turned into a string and used as the GV's name, and the order open price as its value.

The code snippet loops back to find the shift that is 1 bar to the right of the time saved in the GV. This time is updated later on if the stop loss is moved, so Graeme always needs to know the value of this changing shift.

I am reluctant to change this because it might be clumsy programming, but it aint actually broke. Can all this be easily replaced with shift = iBarShift(NULL, CatTimeFrame, ctime, false);?

If so, does ctime's (Candle Open Time) declaration need turning into a datetime?

Cheers

[MichaelM]

You know the saying well

But yes, the while loop can be replaced by iBarShift http://docs.mql4.com/series/ibarshift

ctime is already datetime, so no need to convert it.

EDIT: Steve, thanks for considering my code and giving it your QA

Cheers,
MichaelM

[MichaelM]

So far I can single out GBPNZD pair as having attributed to 96% of the losses in my demo account due to it being in range for more than two weeks and it's Daily ATR(10) is greater than the 100 pip SL.

Going to stop trading this pair till it breaks out of range (1.90 - 1.94).

At least I have 1 leg formed at +100 pip JSL and one surviving at BE


EDIT: This little post of mine gave me a great idea to implement.

Let G start looking for trading opportunities only if price has broken either range high price or range low price.

Range high/low price can be user inputs.

Fingers are itching already to write the code

[scalpz]

...EDIT: This little post of mine gave me a great idea to implement.

Let G start looking for trading opportunities only if price has broken either range high price or range low price.

Range high/low price can be user inputs.

Fingers are itching already to write the code

Sounds like needing movable top & bottom lines to me. I'm sure we have been there before with some of the other ea's.
May lose the stealth effect of just numbers though.

Really liking your work & input around Steve's threads Michael - really impressive.

Had trade big numbers turned on & pickedup a buy on EURUSD passing through 1.32 last thing Friday. Got closed out at +4.4 pips on the retrace early Mon am.

cheers scalpz

[MichaelM]

Thanks scalpz

I was thinking the same thing with the movable lines, but then realised that G only trades the RN's so I just put in two external variables called RangeHigh and RangeLow so the user can input which RN range they don't want G to trade between (inclusive).
Then modified the StopTrading bit of the code to account for these two variables compared to the Ask/Bid if they are > 0

BTW, 1.32 is a normal RN, BRN are for example: 1.20, 1.30, 1.40, etc...

IMHO, the markets is still messed up, causing most, if not all pairs, to be rangebound (looking from a Daily perspective)