Shelley's multi-pair basket trader

[SteveHopwood]

I'm not sure what the discrepancy is between my positive results this morning and anybody else's negative results... could be anything... settings? criminal? EA version?? I have no idea... But I do know that I was trading WITH the M30 Slope filter ENABLED.... and I was out of the markets 30 minutes after NY open.....

You and I and anyone else with a firing brain cell knows this; it is the usual stuff. Different crim = different feed = different results etc.

Or maybe the unlucky ones had their platform disconnected at the wrong time.

Or had their tp/sl inputs wrong.

Or, and this is far more likely, obstinately refuse to learn how to trade 10.2 properly. Ok, so I know this EA is not about 10.2, but it is about Slope.

Slope is central to 10.2.

Bob developed 10.2 for his own Cowboy IBFX trading. Now, I am no expert here, so what I am about to write may be incorrect, but here goes anyhow: if a system is developed using one time scale and traders try to use it on a different one, is it not possible that the system might not work on the different one?

Guys, I thought I made this obvious and clear in all my 10.2-related threads: there is no substitute for learning about 10.2. Sorry, but did I use too many two-syllable words in writing this?

Hang on. I just went back to post 1 and see where I went wrong. I posted this:
"To trade this robot, you have to understand:

• How to use EA's.
  Trend trading and retracement, Range trading and Counter Trend trading. You will get all of this from http://www.forexfactory.com/showthread. ... ost4846473
  The concept of basket trading."

I see where I went wrong. This is what I should have posted:
Listen, you pathetic, pea-brained, dim-witted cretin: even begin to consider using this robot without understanding 10.2 and you will lose all your money.

Understand now, guys?

[alex_forex]

Please put that sentence in all your "post 1"

[fxarun]

This is pure awesomeness !!!
Thanks Steve for this gem !

[SteveHopwood]

Please put that sentence in all your "post 1"

Good idea.

[SteveHopwood]

Coders, I cannot see why the jumping stop appears not to be working.

In CountOpenTrades()

Code: Select all

if (AdaptiveJumpingStopPips > 0) JumpingStopPips = AdaptiveJumpingStopPips * OpenTrades;

sets up JumpingStopPips

then start() has this block:

Code: Select all

      //Look for an opportunity to update the jumping stop loss
      if (JumpingStopPips > 0) 
      {
         JumpingStopLoss();
      }//if (JumpingStopPips > 0) 

then

Code: Select all

void JumpingStopLoss()
{

   if (PipsUpl >= JslPips + (JumpingStopPips * 2) )
   {
      JslPips+= JumpingStopPips;
      GlobalVariableSet(PipsTpGvName, JslPips);
   }//if (PipsUpl > JslPips * 2)
   
}//End void JumpingStopLoss()

should update JslPips whenever the PipsUpl has moved sufficiently far.

Can you see anything wrong in the logic?

[garyfritz]

Hehe. Bet you had a ball.

I did rather! But I was quite annoyed that it behaved while I tested it, behaved for the first two baskets, and THEN when I wasn't watching it started misbehaving. Grump.

I'm not at all sure I interpreted your logic & flags & etc correctly. Do you have any guess where I went wrong? Here's what I did:

* Created ContinuousTrading extern & set OriginalShelly to false
* Set ComeWhatMayCloseHour to 24
* Set adaptive TP/SL to 10 / 15
* In LookForTradingOpportunities(), after the if (OriginalShelley) code (long & short), I added:

Code: Select all

   if (ContinuousTrading)
   { 
      SendLong = true;   // or SendShort = true, as appropriate
   }//if (ContinuousTrading)

* In start(), in the if (ForceClosure) code, I added "BasketSent = false;" -- might not have been necessary but I don't think it would hurt anything? (Originally the next section looked at BasketSent but I changed it to check OpenTrades == 0 and forgot to remove this BasketSent bit)
* In start(), after the if (ShelleyPlusGary) code, I added:

Code: Select all

      if (ContinuousTrading)
      {
         if (OpenTrades == 0)
         {
            ReadTable();
            if (!StopTrading) LookForTradingOpportunities();
         }//if (!BasketSent)
      }//if (ContinuousTrading)

I'm very puzzled why it would have worked all those times while I was testing it, and on the first two "live" baskets, and then kablooey...

[garyfritz]

Can you see anything wrong in the logic?

Is it still setting the JSL, then not advancing it any further?

I think it's in LookForBreakeven(). You call it in start():

Code: Select all

      //Look for chance to move the basket stop loss to breakeven
      if (OpenTrades > 0)
      {
         LookForBreakeven();
      }//if (OpenTrades > 0)

Then in LookForBreakeven() you set JslPips to BreakEvenProfitPipsLock even if you've already hit breakeven:

Code: Select all

   if (BreakEvenProfitPips > 0)//Zero setting disables this feature
   {
      if (PipsUpl >= BreakEvenProfitPips)
      {
         BreakevenAchieved = true;
         JslPips = BreakEvenProfitPipsLock;
         GlobalVariableSet(PipsTpGvName, JslPips);
      }//if (PipsUpl >= BreakEvenProfitPips)      
   }//if (BreakEvenProfitPips > 0)

So JslPips keeps getting reset back to BreakEvenProfitPipsLock and you can't get past BreakEvenProfitPipsLock + JumpingStopPips. The if should be "if (!BreakevenAchieved && PipsUpl >= BreakEvenProfitPips)" -- or you could add the check in the earlier if. Or you could combine them all into one if: "if (BreakEvenProfitPips > 0 && !BreakevenAchieved && PipsUpl >= BreakEvenProfitPips)"

[Zypip]

I have tested Shelley today again with the following setup and results:

- Original Shelly : +500 pips ish
- Shelley with TMATRUETF 60M : +250pips ish
- Shelley with slope conf TF 60M : +100pips ish

If I could be allowed one wish it would be to have the slopeconf TF trigger at 0.4/-0.4 instead of the current 0.8/-0.8 (actually user definable would be fantastic for fine tuning). From my preliminary analysis it would increase the number of trades without too much impairing on the retracement filtering.
Still using v1r with Gary's setfile with jsl disabled.
Will keep my comparison settings running to see which one will fail first and if one can survive future significant retracements. I may add another Empty4 session using SCTF and TMATRUETF set at 30M.

-

[SteveHopwood]

I'm very puzzled why it would have worked all those times while I was testing it, and on the first two "live" baskets, and then kablooey...

You will find your experiments much easier in a new addition to post 1.

There is an emerging demand for a Simple Shelley, so I have obliged. Please read 'Simple Shelley' in post 1. Please note that disentangling everything that we have added was not so simple, so there might be some unexpected behaviour initially.

[SteveHopwood]

Can you see anything wrong in the logic?

Is it still setting the JSL, then not advancing it any further?

I think it's in LookForBreakeven(). You call it in start():

Code: Select all

      //Look for chance to move the basket stop loss to breakeven
      if (OpenTrades > 0)
      {
         LookForBreakeven();
      }//if (OpenTrades > 0)

Then in LookForBreakeven() you set JslPips to BreakEvenProfitPipsLock even if you've already hit breakeven:

Code: Select all

   if (BreakEvenProfitPips > 0)//Zero setting disables this feature
   {
      if (PipsUpl >= BreakEvenProfitPips)
      {
         BreakevenAchieved = true;
         JslPips = BreakEvenProfitPipsLock;
         GlobalVariableSet(PipsTpGvName, JslPips);
      }//if (PipsUpl >= BreakEvenProfitPips)      
   }//if (BreakEvenProfitPips > 0)

So JslPips keeps getting reset back to BreakEvenProfitPipsLock and you can't get past BreakEvenProfitPipsLock + JumpingStopPips. The if should be "if (!BreakevenAchieved && PipsUpl >= BreakEvenProfitPips)" -- or you could add the check in the earlier if. Or you could combine them all into one if: "if (BreakEvenProfitPips > 0 && !BreakevenAchieved && PipsUpl >= BreakEvenProfitPips)"

Breathtaking again. How do you do it? You are able to put your finger on the most inefficient of code and instantly spot the bloop. Fantastic.

FYI, my limited understanding is that mql4 evaluates all conditionals in an if (a && b && c) even if a fails. Placing these conditionals separately is my own way of trying to cut down on 'overhead'. Limited, I know, but that is me.