Brackets

[WhoKnows]

As to not being shot in the HGB thread, I thought I'll ask the question here.
I am trying to test such questions myself by adapting the code, but sometimes it takes ages to wait for certain conditions and see the effects of your changes... so I'll thought I might better ask the coding GURU's.

In the MQL language are the following statements the same?

Code: Select all

line version 1:              if (OrderComment() == A || (OrderComment() ==B))
line version 2:              if (OrderComment() == A || OrderComment() ==B) 

The only difference is the extra brackets on the second part of the first line.

I know .... Amateurs trying to understand how MQL works....
But we all have to start learning somewhere.

[dudest]

In the spirit of MQL paranoia, I prefer doing it this way

Code: Select all

if ( (OrderComment() == A) || (OrderComment() ==B) )

Should yield the same as this though:

Code: Select all

if ( OrderComment() == A || OrderComment() ==B )

but I'd rather use the first notation ( lock it down and leave nothing to chance )

Cheers

[WhoKnows]

Thanks Dudest, I can imagine your version does lock it down, with only one way to interpret the brackets and logic.

But let me re-phrase the question a bit.
I have seen several statements in an EA with the bracket construction

Code: Select all

 if (OrderComment() == A || (OrderComment() ==B)) 

and me being paranoia I wondered if MQL with the brackets as above will process the part OrderComment()==B as intended.

I guess I'll have to make the change and test if it affects the behavior of the EA.

[dudest]

Thanks Dudest, I can imagine your version does lock it down, with only one way to interpret the brackets and logic.

But let me re-phrase the question a bit.
I have seen several statements in an EA with the bracket construction

Code: Select all

 if (OrderComment() == A || (OrderComment() ==B)) 

and me being paranoia I wondered if MQL with the brackets as above will process the part OrderComment()==B as intended.

I guess I'll have to make the change and test if it affects the behavior of the EA.

It will process as intended

Cheers

[dietcoke]

Thanks Dudest, I can imagine your version does lock it down, with only one way to interpret the brackets and logic.

But let me re-phrase the question a bit.
I have seen several statements in an EA with the bracket construction

Code: Select all

 if (OrderComment() == A || (OrderComment() ==B)) 

and me being paranoia I wondered if MQL with the brackets as above will process the part OrderComment()==B as intended.

I guess I'll have to make the change and test if it affects the behavior of the EA.

as dudest says in this case the brackets are meaningless, howeverwhen the statements become more complex, the brackets are essential when mixing up the use of || and && in the same if statement

Code: Select all

if (OrderComment() == A && OrderComment() ==B && x==42) 

is thesame as

Code: Select all

if (OrderComment() == A &&( OrderComment() ==B && x==42)) 

but

Code: Select all

if (OrderComment() == A || OrderComment() ==B && x==42) 

is not necessarily the same as

Code: Select all

if (OrderComment() == A ||( OrderComment() ==B && x==42)) 

The first is only truen when x=42
the second is true when ( OrderComment() ==B && x==42) or OrderComment() == A

[SteveHopwood]

As to not being shot in the HGB thread, I thought I'll ask the question here.
I am trying to test such questions myself by adapting the code, but sometimes it takes ages to wait for certain conditions and see the effects of your changes... so I'll thought I might better ask the coding GURU's.

In the MQL language are the following statements the same?

Code: Select all

line version 1:              if (OrderComment() == A || (OrderComment() ==B))
line version 2:              if (OrderComment() == A || OrderComment() ==B) 

The only difference is the extra brackets on the second part of the first line.

I know .... Amateurs trying to understand how MQL works....
But we all have to start learning somewhere.

Welcome to the club of "Amateurs trying to understand how MQL works." I am its leading exponent.

Line version 1 would throw up an error because you have an extra right bracket. Don't remember what the error would be even though it happens to me every day. Never code more than a couple of lines of CrapQl4 without doing a compile. The syntax error you made in the preceding sentence could throw up an error that bears no resemblance to the code you just typed and have you eventually abandoning several thousands of lines of code and starting again. Ok, going back a lot of years now, but guess how I know?

FWIW, and that is probably quite a lot but that is up to you whether you believe me or not, I use brackets to overcome my lack of understanding of operator precedence. Said precedence should be universal, but this is CrapQl4 we are talking about here, so I take nothing for granted.

So, if I have a formula that adds num1 to num2 and then divides the result by 2 I cover myself. So the formula becomes
double ResultOfCalulation = (num1 + num2) /2;

More professional coders here understand the rules of precedence better than me. Some of them even (misguided in my opinion but that is another story) trust CrapQl4 rules of operator precedence . I don't and use brackets to save me hours of bug-hunting in the future. Guess how I learned it was a good idea to do this?

You would be well advised to take close notice of my, "Guess how I know?" statements here. This is blisteringly hard-won experience I am passing on to you.

[WhoKnows]

Thanks for all your input.

I think all said the same thing, and nicely summarized by Steve

operator precedence should be universal, but this is CrapQl4 we are talking about here, so take nothing for granted

So the way to go is to code with as many brackets are needed to make it absolutely foolproof

Apparently programming is still as it was a Zillion years ago when I spent a couple of days frustrating over a non-running Fortran thingy.... to find that I used a ; instead of a : which I could not see on the bloody orange letter screen.

[SteveHopwood]

Thanks for all your input.

I think all said the same thing, and nicely summarized by Steve

operator precedence should be universal, but this is CrapQl4 we are talking about here, so take nothing for granted

So the way to go is to code with as many brackets are needed to make it absolutely foolproof

Apparently programming is still as it was a Zillion years ago when I spent a couple of days frustrating over a non-running Fortran thingy.... to find that I used a ; instead of a : which I could not see on the bloody orange letter screen.

When I first started coding this rubbish, { and ( were as close to indistinguishable as could be. Given even worse eyesight than me now , they probably still are. Don't even bother to have nightmares about the time I spent tracking down the bloops they created.

Fucking CraptQl4 is diabolical now. It was fucking diabolicer back then. You would need a power of a lot to add to diabolical back then to gain even the merest inkling of what we had to put up with.

Mind, those cretins at crapperquotes have come up with some wonderful stuff to derail us coders lately. Just try to keep up with me and the other coders here (and some of them are seriously good) to learn how to attempt to defeat it. Don't try to do it alone - you will lose.

Good luck my friend. We are here to help you.

[WhoKnows]

Thanks.

No, I won't try to write much Craptastic code myself.
But I have to learn the essentials to be able to hack the codes from others and test and confirm if I can find things to improve.

I always like to prove for myself it works before raising it in a wider audience.
Hence e.g. I was looking at that closing code in HGB and asked Trendinator if he saw the same..... before raising it as a potential logic issue.
Also in my trial weeks ago I did prevent entries at Yellow by adding if (TmaStatus == Tmarangesignal || TmaStatus == TmaInitializing) return(false); to line 2285ish.
So generally I am just tinkering ....

For me HGB manual gives nice results, but HGB EA not yet. Especially in non-trending times HGB EA appears to suffer.
- Preventing Entry at Yellow improved things in my tests
- I hope your new version with closing on Waves will bring HGB EA closer to HGB manual
(although we have to accept it probably will never be as good as manual as you cannot code everything that you see... e.g. trendlines, news. But we can at least try to get it closer)

Some other ideas:
I think there is a much better closing method (am testing it manually).
Closing trades on Waves one TF lower preserves a lot of 'gain' that HGB now gives away. Conceptually it of course makes sense. My manually testing (slow progress) looks very promising. Unfortunately I have little time to trade manually.
Finding how to implement another TF in the same EA will have to become my next project.

Some other big effects I found so far were time of trades (ok I'll duck now ). Somehow trades initiated in the second half US and Asian period caused a NET loss (in MY trials). Is this because that period is generally less trending?

Also I definitively found that halfway the UK and halfway the US session there often appears to be draw-dawn in open trades. But no idea yet how to tell HGB to take profit and reset. May be the point about closing on waves one TF lower would solve this.

Enough ideas to keep busy. I have a 'warped' perspective.
My beef with most systems is that the focus is always on Entries. IMHO the deciding factor in being profitable is more determined by Exits and MM. So I will hobby away with the exit part.