ea work fine for all pairs exept on YEN pairs - page 4

New comment
 
Alain Verleyen: How my code could work as I want and still have bug ?
Show your code! I've asked you to provide a specific case but you have not.
 
Alain Verleyen:

How my code could work as I want and still have bug ?

I'll wade in on both sides of the argument. You are each defining the word "bug" very narrowly: either only as something which is causing a problem now (software doesn't meet current requirements); or as anything which might conceivably cause a problem in future (software wouldn't meet possible future requirements). The difference between those two is always in part a personal and subjective assessment of what may happen in future.

There are plenty of things which are not bugs but which are still bad code, because it is very likely that requirements or circumstances will change and cause problems.

For example, even if someone thinks they are certain that they will only want to trade EUR/USD, I would still suggest it is a bad idea to use a hard-coded NormalizeDouble(..., 5).

But is that scenario comparable to using NormalizeDouble() instead of rounding to tick-sizes? I would argue that it's not the same, on three grounds:

  • The figures from every MT4 broker I have seen say that there is extremely little automated trading of contracts whose tick-size is not a power of 10. It's therefore very unlikely that a random contributor to this forum is going to end up trading one of these things. NormalizeDouble() will be fine for 99.9% of people.
  • The pip size calculation in the OP's code will cause a problem before NormalizeDouble() does. While there's no agreement, and certainly no "rule", about what the pip size is on something like the S&P, almost no one would argue that it's 0.01 on the grounds that the price is quoted to 2DP. Therefore, if the use of NormalizeDouble() is a bug, then the pip size calculation is a bigger bug because it will affect more contracts... but no one's worrying about that.
  • There are plenty of brokers whose tick-value figures for equity indices etc are wrong, because they are in the contract's base currency rather than the account's deposit currency, and widely referenced code on this forum will not work properly. Dwelling on things such as rounding to tick-sizes rather than using NormalizeDouble() ignores the general reality that you can't hope to write code which works without problems on all contracts with all MT4 brokers, and that starting to trade new asset classes is very likely to require changes to code, regardless of how careful you think you have been.
I'll also repeat one other factor which strikes me as important. The common error of closing trades while looping from 0 to OrdersTotal()-1 is a logic problem. Using NormalizeDouble() instead of rounding to tick-sizes is a knowledge problem, and not related to programming: not knowing that some contracts move in increments which are not powers of 10.
 

JC:

There are plenty of brokers whose tick-value figures for equity indices etc are wrong, because they are in the contract's base currency rather than the account's deposit currency, and widely referenced code on this forum will not work properly.

... If we're being strict, using MODE_TICKVALUE is a potential bug just like NormalizeDouble() is a potential bug. It will work in most cases but not all; similar to NormalizeDouble(). It is more reliable to get SYMBOL_CURRENCY_PROFIT and do your own conversion from that currency to the account deposit currency.

 
JC:

... If we're being strict, using MODE_TICKVALUE is a potential bug just like NormalizeDouble() is a potential bug. It will work in most cases but not all; similar to NormalizeDouble(). It is more reliable to get SYMBOL_CURRENCY_PROFIT and do your own conversion from that currency to the account deposit currency.

Nice
 
Alain Verleyen:
Nice
... the difference being that the documentation says that MODE_TICKVALUE should work. But not in the real world.
 
JC:
... the difference being that the documentation says that MODE_TICKVALUE should work. But not in the real world.

I know...all what you wrote above is right.

Still I noticed your initial answer was with NormalizeDouble(), just fixing the digits and avoid hardcoded parameter. May I ask you why ?

 
Alain Verleyen:

Still I noticed your initial answer was with NormalizeDouble(), just fixing the digits and avoid hardcoded parameter. May I ask you why ?

Why what? Why that answer instead of rounding to the tick size?

 
JC:

Why what? Why that answer instead of rounding to the tick size?

Yes. Just curious, feel free to not answer.

 
Alain Verleyen:

Yes. Just curious, feel free to not answer.

The OP was saying that he/she hadn't managed to spot any of the messages in the Experts log where MT4 was recording "...invalid price" (plus an error log from the EA itself). Under those circumstances it seemed best to keep things simple.
 
JC:
The OP was saying that he/she hadn't managed to spot any of the messages in the Experts log where MT4 was recording "...invalid price" (plus an error log from the EA itself). Under those circumstances it seemed best to keep things simple.

That's it.

We now have a good topic to use as reference 


12345
New comment
Reason: