Holy Graily Bob's Candle Power

[SteveHopwood]

Thanks Thomas. I understand.

I do not approve but that is just tough because that is the way it is.

You are an invaluable source of information yet again.

[dreambig2]

Thx for all the information...don't understand yet of course but am going over it. :youknow:

[SteveHopwood]

Thx for all the information...don't understand yet of course but am going over it. :youknow:

Keep going over it. A decade ago, I had all that I now know still to learn. I was nobody. Look where I am now - a teensy bit of a somebody at least. Yet I am still learning.

Who knows where you could be in a decade. Even better, learn the lessons available here at SHF and cut the process short by 9 years.

Keep going, Tiger.

[RisklessPips]

Ok. Giving the wisenheimer here.

You are not alone. Mql4 is a subset of the C language. And there, as in many other languages, the result of an int divided by an int is not a float, but the floor of the division. You can avoid this by implicit or explicit typecasting.

Implicit typecasting in this case can be done by introducing a double (here a simple "1.0") somewhere in the early part of the equation:

Code: Select all

double x = 0;
int y = 1;
int z = 2;
x = y / (z * 1.0);

Explicit typecasting means making one part of the equation explicitely a double:

Code: Select all

double x = 0;
int y = 1;
int z = 2;
x = y / (double) z;

Dont rely on automatic type conversion and cast your data as early as you can.

Cheers, Thomas

Don't want to turn CP into coders corner but can I ask is it good practice given the above to declare all variables to be used in any calculation as double and only change them to int if required for human consumption?

Charles

[renexxxx]

Don't want to turn CP into coders corner but can I ask is it good practice given the above to declare all variables to be used in any calculation as double and only change them to int if required for human consumption?

The good practice is to declare a variable as an int if it only ever needs to store integer values. As a programmer you know that. You can use integers in a calculation (including division), you just have to be aware that the result of that calculation will also be integer unless, (like Thomas explained) you typecast one or more of the components to a double, or you include a double constant or other double variables in the calculation.

Similarly, you declare a variable as a double if you know that it can and will store double values. The word-length of integers is smaller than that of doubles, so there is also a (small) advantage of using integers if you don't need doubles.

[RisklessPips]

Don't want to turn CP into coders corner but can I ask is it good practice given the above to declare all variables to be used in any calculation as double and only change them to int if required for human consumption?

The good practice is to declare a variable as an int if it only ever needs to store integer values. As a programmer you know that. You can use integers in a calculation (including division), you just have to be aware that the result of that calculation will also be integer unless, (like Thomas explained) you typecast one or more of the components to a double, or you include a double constant or other double variables in the calculation.

Similarly, you declare a variable as a double if you know that it can and will store double values. The word-length of integers is smaller than that of doubles, so there is also a (small) advantage of using integers if you don't need doubles.

The answer I knew was right but feared given idiosyncratic Empty4.

Charles

[tomele]

Don't want to turn CP into coders corner but can I ask is it good practice given the above to declare all variables to be used in any calculation as double and only change them to int if required for human consumption?

The good practice is to declare a variable as an int if it only ever needs to store integer values. As a programmer you know that. You can use integers in a calculation (including division), you just have to be aware that the result of that calculation will also be integer unless, (like Thomas explained) you typecast one or more of the components to a double, or you include a double constant or other double variables in the calculation.

Similarly, you declare a variable as a double if you know that it can and will store double values. The word-length of integers is smaller than that of doubles, so there is also a (small) advantage of using integers if you don't need doubles.

I totally agree with Rene. Additionally, you must keep something in mind: Floating point values are often "unprecise". A double value of 4.0 might not be the same as an integer value of 4. For this reason there is a function named CloseEnough() in the code. Steve explains its necessity very clear in his comment:

This function addresses the problem of the way in which mql4 compares doubles. It often messes up the 8th decimal point. For example, if A = 1.5 and B = 1.5, then these numbers are clearly equal. Unseen by the coder, mql4 may actually be giving B the value of 1.50000001, and so the variable are not equal, even though they are. This nice little quirk explains some of the problems I have endured in the past when comparing doubles. This is common to a lot of program languages, so watch out for it if you program elsewhere.

So like Rene explained, stick to integer variables where you dont need floating point values. Otherwise you might introduce implications you dont really want.

Cheers

[SteveHopwood]

Just to let you know folks, that I have updated 1f with Tommaso's enhanced pip factor code. The EA should work with pretty much every pair your broker offers. Thanks Tommaso.

[szfxtrader]

Just to let you know folks, that I have updated 1f with Tommaso's enhanced pip factor code. The EA should work with pretty much every pair your broker offers. Thanks Tommaso.

Thank you very much!

[SteveHopwood]

Attached is a new experimental version with a feature supplied by Richard. Here is the bulk of the pm he sent me by way of explanation:

I've been following the Candle Power discussion with interest. One thought that struck me was that it might be beneficial to close it down once a certain equity increase had been hit and then start the process again.

Hopefully this would bring the diverging equity and balance curves into check periodically, and bank small bits of equity to slowly build our accounts.

I started with your 1f version, and have added my own Equity Module which you can see at the end of the code, along with the usual input/globals and user feedback in the usual places.

My standpoint was to use the account equity when we start a cycle and then from that point on calculate the change in that equity by our trading pair by Candle Power. Therefore the actual account equity that is being changed by other pairs trading or other experts working on the account.

I present it here privately to do what you will with. If you feel it has legs, I'm happy to share with everyone.

Richard.

This seems like a pretty good idea to me, so many thanks Richard.

Run it on demo for a couple of days folks. It can become V 1g once we know the code needs no modification.