dlewisfl wrote: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.

dlewisfl wrote:

Baluda wrote:

dlewisfl wrote: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).

garyfritz wrote:

dlewisfl wrote: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.

Fx93 wrote: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.

Fx93 wrote: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.

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