Coding for beginners - this is how Steve started

[SteveHopwood]

I found an upload limit that I changed to unlimited. I am not sure if this solves the problem, so would you care to try again with the single zip and report back?

[ironrick]

Hmmm.... Still says:

The attachment’s file size is too large, the maximum upload size is 2 MB.
Please note this is set in php.ini and cannot be overridden.

Don't what it means exactly but maybe it will help in your settings search.

Lemme know and I will try again

R

[gaheitman]

Hmmm.... Still says:

The attachment’s file size is too large, the maximum upload size is 2 MB.
Please note this is set in php.ini and cannot be overridden.

Don't what it means exactly but maybe it will help in your settings search.

Lemme know and I will try again

R

Perhaps it requires a restart of the board.

[SteveHopwood]

Hmmm.... Still says:

The attachment’s file size is too large, the maximum upload size is 2 MB.
Please note this is set in php.ini and cannot be overridden.

Don't what it means exactly but maybe it will help in your settings search.

Lemme know and I will try again

R

Not a clue, but thanks anyway. Tomorrow, I can at least point people in the direction of your posts to fill in the gaps.

Thanks for everything you have done.

[fxozgirl]

Hmmm.... Still says:

The attachment’s file size is too large, the maximum upload size is 2 MB.
Please note this is set in php.ini and cannot be overridden.

Don't what it means exactly but maybe it will help in your settings search.

Lemme know and I will try again

R

You will need to have ftp access to the forum to change php.ini
Not sure what sort of access Steve has to the source code of the forum, but that's what he will need

[SteveHopwood]

Hmmm.... Still says:

The attachment’s file size is too large, the maximum upload size is 2 MB.
Please note this is set in php.ini and cannot be overridden.

Don't what it means exactly but maybe it will help in your settings search.

Lemme know and I will try again

R

You will need to have ftp access to the forum to change php.ini
Not sure what sort of access Steve has to the source code of the forum, but that's what he will need

None that I know of. The software lives on the server, which is owned by Erwin's company.

[scalpz]

Found a couple of gold nuggets in relation to Steve's coding methods.
Posting here so other cut & paste coders like me can see them when reading this thread.

I see that someone other than Fmfx is interested in what is going on here, so a few more words of explanation.

Those of us who are not trained programmers have to adopt our own coding style. In doing so, consistency helps a lot. Look at the code snippet that offers up external inputs to the user when the EA uses a moving average:

Code: Select all

extern string  mai="----Moving average----";
extern int     MaTF=0;//Time frame defaults to current chart 
extern int     MaPeriod=50;
extern int     MaShift=0;//The MA Shift input
extern string  mame="Method: 0=sma; 1=ema; 2=smma;  3=lwma";
extern int     MaMethod=1;
extern string  maap="Applied price: 0=Close; 1=Open; 2=High";
extern string  maap1="3=Low; 4=Median; 5=Typical; 6=Weighted";
extern int     MaAppliedPrice=0;
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
double         MaVal;
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Now remove the 'Ma' from each input:

Code: Select all

extern int     TF=0;//Time frame defaults to current chart 
extern int     Period=50;
extern int     Shift=0;//The MA Shift input
extern string ame="Method: 0=sma; 1=ema; 2=smma;  3=lwma";
extern int     Method=1;
extern string  ap="Applied price: 0=Close; 1=Open; 2=High";
extern string  ap1="3=Low; 4=Median; 5=Typical; 6=Weighted";
extern int     AppliedPrice=0;
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
double         Val;
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

What we are left with is a generic set of inputs that relate to the fields of indi's that we use all the time on our charts.

So, all I do when setting up a group of external inputs is place a shortened form of the indi in front of the variables to customise them - RsiTF, AtrTF, BandsTF etc

As my amateur coding evolves, so does my ability to structure my code in such a way that LUC has fewer and fewer opportunities to invite his buddies for lunch. Variable naming consistency helps me a lot.

Post from straight after in same Fmfx-auto trader thread:

Timely. It so happens that - as a total coding tyro - I've been battling to adapt an EA to use an alternative indi to the one it natively references (nothing to do with this thread however). Thanks again, Maestro.

This can be impossible sometimes. How easy it is to do depends on how well the indi was coded in the first place.

The first thing I do when approaching a custom indi is pray that it was coded by squalou.

This is a rare event, so the second thing I do is pray that it was not coded by an idiot. This is also quite rare.

The third thing I do is open the Data window. This gives a rough idea of which buffers the coder has used to store information. Hover the mouse over a candle and you will read the value/s held by the buffers. Bear in mind that the buffer index starts at 0, but displayed Value fields start at 1, so that buffer 1 stores the value shown as Value 2 in the data window etc.

Mind, different indis display differently in the data window, so it takes some playing around to work out exactly how to interrogate the indi successfully.

All of which goes some way to explain why I bloody hate bloody custom indis.

I would say, "Welcome to my world" except that only an idiot enters it. Instead, I will simply say, "Good luck. You need it."

And almost like Steve says, "Good luck. We need it."
cheers Scalpz

[scalpz]

Found another nugget, this one from Squalou in Scoob's Forex Robot thread -

Hi all,

I spotted the same bug while backtesting.
And found the bloody CraaaaaaaaaaaaaaaaaapT4 bloop that i had already hunt many times in the past...

A note to coders for their future productions :
It has to do with comparisons of "double" values:
sometimes, simply comparing double values like this :

Code: Select all

if ( A == B )  they_are_equal();

when A seems to be equal to B, doesn't work...
Even if you Print() A and B you will NOT see ANY difference.
However the test fails...
This is due to the way Empty4 handles doubles internally.
Approximations lead to differences beyond the 8th decimal, and therefore the stored values are not identical anymore in memory.

In order to solve this issue, Empty4 designers provided a small function that is designed to prevent this issue:

CompareDoubles(A,B)
which needs
#include "stdlib.mqh"

You should either use this function like this:

Code: Select all

if ( CompareDoubles(A,B) )  they_are_equal();

or code its equivalent inline :

Code: Select all

if ( NormalizeDouble(A-B,8)==0 )  they_are_equal();

Soooo...
In the case of FR, here is the line that should be fixed :
go to the function "TradeExist()", and replace this line

Code: Select all

            if(OrderType() == cmd && OrderLots() == lots)

like this :

Code: Select all

            if(OrderType() == cmd && NormalizeDouble(OrderLots()-lots,8) == 0)

And that's it...
Damn Empty4... !

Sq

cheers scalpz
edit: sorry, maybe these 2 posts should be in the Utilities/code snippets thread at
http://www.stevehopwoodforex.com/phpBB3 ... f=15&t=166
- needs a mod to shift them, or take out this edit if they disagree. ta.

[SteveHopwood]

cheers scalpz
edit: sorry, maybe these 2 posts should be in the Utilities/code snippets thread at
http://www.stevehopwoodforex.com/phpBB3 ... f=15&t=166
- needs a mod to shift them, or take out this edit if they disagree. ta.

I had not seen sq's post, so this is news to me.

It also explains a struggle I had a while ago, when I knew two numbers to be the same but the program would not recognise this. I had to get around it by putting them both into a string and comparing that instead.

Would you copy this into the utilities thread as well, please? Info like this needs dissemination.

Nice one.

Cheers

[garyfritz]

Warning, educational but geeky detail ahead:

As much as we all love Empty4's many and varied failings, we can't blame Empty4 for this one. This is common to virtually any language that handles floating-point values.

The CPU hardware that represents and manipulates numbers doesn't work in decimal the way we do. The numbers are represented in binary (base 2 instead of base 10). When it's an int (integer) value, that's no problem -- binary integer values are exactly equal to decimal integer values, so integer 1234 == integer 1234, all the time.

But floating-point numbers are represented by a long binary number, and that binary number is often not precisely equal to **ANY** decimal value. So e.g. "double x = 1./3.;" produces a value that can't be exactly printed in decimal -- and probably can't be exactly represented in binary, either.

But when you PRINT a number, the binary value gets converted to decimal, and probably truncated to some number of decimal places. Generally print functions don't print stuff that's 8-10 decimal places past the main value -- because you don't want "5" to get printed as "5.00000000001436284" -- but it's still there in the binary value. That printed decimal value is an APPROXIMATION of the exact binary value stored in the variable.

And -- the binary value is not always exactly what you think. E.g. "double y = 5.0;" is probably represented precisely as 5.0, exactly. But "double y = 15. / 3.;" or "double z = sqrt(25.);" might NOT be precisely 5.0. It might be approximately 5.00000000001436284. They LOOK the same when you print them the normal way, but they're not EQUAL.

And the == operator (in MQL and in most languages) tests for EQUAL. EXACTLY equal. Bit-for-bit identical. And internally, in the double variable, 5.0 is NOT exactly bit-for-bit identical to 5.00000000001436284. So the == test fails.

I wouldn't even guarantee that "NormalizeDouble(A-B,8) == 0.0" would always work. 0.0 is well-represented in binary floating point and it will be EXACTLY zero. NormalizeDouble to 8 decimal places MIGHT represent it as exactly zero, or it might not. Depends on how NormalizeDouble is implemented.

I don't know how CompareDoubles is implemented either. Hopefully it's safe, but this IS Empty4 we're talking about.

If you're paranoid you could use something explicit like "#define ReallySmall 0.00000001; if ((A-B) < ReallySmall) { ..."

That should work for most cases you're likely to run into in MQL. But if you're comparing really tiny numbers, like atomic weights or the IQ of Empty4 designers, even that might fail. E.g. if x is 10^-20 and y is 10^-21, x is actually 10x larger than y. They're not even close to equal. But x-y is 0.00000000000000000009, which is much smaller than ReallySmall, so the test above would say they're equal. To handle cases like that, you'd want to do something like "if ((A-B)/B < ReallySmall) { ..." (and don't forget to test if B==0 first). That scales the A-B value so the ReallySmall test works even for Really Small values of A and B.

[/pedantry]