POOLER/SAN Stunning generosity

[Fx93]

The backtest I posted was OTB default settings. I've located some DD spots:

3/2/2008: goes 90 pips past 10x.
4/23/2008: goes 50 pips past 10x.
9/12/2010: goes over 1000 pips past 10x. For some reason my first test ignored this trade, perhaps being in another. I'll see if I can work with it.

Edit: Using a 1 2 4 8 6 5 4 3 2 1 lot structure solves it with same profit percents as OTB.

[garyfritz]

I've never had a problem doing something like this for example:

Code: Select all

if (NormalizeDouble(MA1,Digits+1) == NormalizeDouble(MA2,Digits+1))

I've only seen the problem when NormalizeDouble() is not used. I'm just curious if someone has seen the problem when NormalizeDouble() is used.

NormalizeDouble() should work for most cases, if you're satisfied with the Digits resolution. (But I wouldn't guarantee it. I believe it's possible for NormalizeDouble() to come up with different results for two values that are identical for the first N digits. For == to work, they have to be EXACTLY equal.)

CloseEnough() doesn't try to check if they're equal. It just looks to see if they're CloseEnough, which the case of Steve's code means they're equal to within about 8 digits. Notice that's not 8 digits after the decimal point, but 8 significant digits! So e.g. 0.000000001 and 0.00000000001 are equal according to a NormalizeDouble() test, even though the first one is 100x bigger than the second one. CloseEnough() says they're different.

If all you ever compare is prices, NormalizeDouble() will be fine. But if you compare things like oscillator values (that can cross zero), etc, CloseEnough() is safer.

[SteveHopwood]

There are other variables defined globally that should be defined locally, as well as other inefficiencies (e.g. not using arrays and copy/pasting code unnecessarily, the number of times he reads through the order pool each tick, using the error message function in the source instead of using an include, needlessly defining variables). The source file for this EA could easily be ~500 lines instead of the 1400+ and be much more efficient.

You are right, for a coder this EA looks like a spaghetti western. Keep in mind though that we are talking to non coders too. It is easier to just intialize the global variables locally. If this EA is any good someone should do a serious rewrite, I'm sure more issues, dare I say bugs, will surface.

Paul

There looks to be a bug where he saves info to the global varables. He copy/pasted a line and forgot to change two of the names (in function subSaveValues). He executes the same statement twice.

void subSaveValues()
{
CalculateADR();
double op = iOpen(Symbol(),0,0);

//Buy limit line and TP
double spread = MarketInfo(Symbol(), MODE_SPREAD);
double Bdistance = BUY_OR;
double Sdistance = SELL_OR;

double Bprice = NormalizeDouble(op - (Bdistance * Point), Digits);
double Sprice = NormalizeDouble(op - (Sdistance * Point), Digits);

double Btp = Bdistance*(BTP_Percent*0.01);
double Stp = Sdistance*(STP_Percent*0.01);

GlobalVariableSet(OP,op);
GlobalVariableSet(BDIST,Sdistance);
GlobalVariableSet(BDIST,Sdistance);
GlobalVariableSet(BTP,Btp);
GlobalVariableSet(STP,Btp);
}

The function should look like this once you get rid of all the un-necessary stuff.

Code: Select all

void subSaveValues() {
   CalculateADR();
   double Bdistance = BUY_OR,
          Sdistance = SELL_OR,
          Btp = Bdistance * (BTP_Percent * 0.01),
          Stp = Sdistance * (STP_Percent * 0.01);
   GlobalVariableSet(OP,NormalizeDouble(iOpen(Symbol(),0,0),Digits));
   GlobalVariableSet(BDIST,NormalizeDouble(Bdistance,0));
   GlobalVariableSet(SDIST,NormalizeDouble(Sdistance,0));
   GlobalVariableSet(BTP,Btp);
   GlobalVariableSet(STP,Btp);
   return;
}

Some headaches could be caused by the frequent mixing of data types (INTs and DOUBLEs).

V 1a is in post one with this fix. Nice one, dlewisfl.

[dlewisfl]

I've never had a problem doing something like this for example:

Code: Select all

if (NormalizeDouble(MA1,Digits+1) == NormalizeDouble(MA2,Digits+1))

I've only seen the problem when NormalizeDouble() is not used. I'm just curious if someone has seen the problem when NormalizeDouble() is used.

NormalizeDouble() should work for most cases, if you're satisfied with the Digits resolution. (But I wouldn't guarantee it. I believe it's possible for NormalizeDouble() to come up with different results for two values that are identical for the first N digits. For == to work, they have to be EXACTLY equal.)

CloseEnough() doesn't try to check if they're equal. It just looks to see if they're CloseEnough, which the case of Steve's code means they're equal to within about 8 digits. Notice that's not 8 digits after the decimal point, but 8 significant digits! So e.g. 0.000000001 and 0.00000000001 are equal according to a NormalizeDouble() test, even though the first one is 100x bigger than the second one. CloseEnough() says they're different.

If all you ever compare is prices, NormalizeDouble() will be fine. But if you compare things like oscillator values (that can cross zero), etc, CloseEnough() is safer.

Thanks Gary. I've never seen NormalizeDouble fail, but it could be possible I guess.

[Pooler]

The backtest I posted was OTB default settings. I've located some DD spots:

3/2/2008: goes 90 pips past 10x.
4/23/2008: goes 50 pips past 10x.
9/12/2010: goes over 1000 pips past 10x. For some reason my first test ignored this trade, perhaps being in another. I'll see if I can work with it.

Edit: Using a 1 2 4 8 6 5 4 3 2 1 lot structure solves it with same profit percents as OTB.

Hi Fx93,

What do you consider to be OTB? Just checking that you saw my last reply. If you use the settings on the EA as in post 1 you going to get unrealistic (worse) readings than the one I posted with the the spreadsheet. Trust me I filled many a spreadsheet and demo'ed almost every conceivable combination and the settings I have on the spreadsheet("settings 2") are still the best.

Please respond that you've read this because I would hate for you to do a lot of work with the wrong settings.

Cheers

[Fx93]

I don't understand your spreadsheet in regards a set file for the Euro, but if you post your settings I'll backtest them for the Euro.

I have found so far using the OTB settings but changing the lot structure to 1 2 4 8 6 5 4 3 2 1 avoids the blow up of 9/12/10 and survives the 7.5 years. However during my backtest on 9/7/2009 if there was just 20k in the account it would have blown up, 22k works, so to be "safe" I would say a starting 25k balance trading .1 lots is necessary on a 50:1 broker. My test started with 20k and it turned into 52,500 from 1/1/2005-5/31/2012, 7.5 years.

Since this worked I then tried to extend the pivot times to 24 hours to get more trades and perhaps increase profit, but this blew up on 9/5/2007.

I also tried changing the profit structure from OTB to 90 75 70 60 50 50 50 50 50, but didn't see a real increase.

Personally I will not be trading this live until I have $2500 I can easily kiss goodbye. The settings that work seem too fickle and when the pivots are extended to the full day there is a blow up. I know of other Ea's that statistically produce the same or better profit without the blow up risk.

[Pooler]

I don't understand your spreadsheet in regards a set file for the Euro, but if you post your settings I'll backtest them for the Euro.

I have found so far using the OTB settings but changing the lot structure to 1 2 4 8 6 5 4 3 2 1 avoids the blow up of 9/12/10 and survives the 7.5 years. However during my backtest on 9/7/2009 if there was just 20k in the account it would have blown up, 22k works, so to be "safe" I would say a starting 25k balance trading .1 lots is necessary on a 50:1 criminal. My test started with 20k and it turned into 52,500 from 1/1/2005-5/31/2012, 7.5 years.

Since this worked I then tried to extend the pivot times to 24 hours to get more trades and perhaps increase profit, but this blew up on 9/5/2007.

I also tried changing the profit structure from OTB to 90 75 70 60 50 50 50 50 50, but didn't see a real increase.

Personally I will not be trading this live until I have $2500 I can easily kiss goodbye. The settings that work seem too fickle and when the pivots are extended to the full day there is a blow up. I know of other Ea's that statistically produce the same or better profit without the blow up risk.

Hi,

Settings attached

[SteveHopwood]

Just to let you all know that I have put Philip's latest settings file in post 1. Should you lose it and want to redownload it any time, that is where you will find you.

[Fx93]

Hi Pooler, using your settings on the Euro on a 5min chart from 1/1/2005-5/31/2012:

30k became 58,287, which is about 13%/yr. without money management. I started with 30k because you said you start with 3k. It does just avoid that 9/12/10 trade that would blow about any account.

One idea is that you could scratch the martingale idea, maybe use 1-4 levels but then opt for a stop loss, and see if when incorporating MM compounding the strategy works.

[dlewisfl]

V 1a is in post one with this fix. Nice one, dlewisfl.

A few other changes that can (or should) be made.

- The "BrokerIsECN" user input does nothing, there is no code for it. I deleted it on mine.
- The "Slippage" user input does nothing, there's no code for it. The value of 6 is hard-coded for slippage in all of the OrderSend commands. I changed each 6 to be the Slippage user input.
- The color for the "PivotLine" object is hard-coded as "Black" in the code, doesn't work well for those who use black background. I created a user-input for it on my version.