![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Prices, lots, money - fixed precision.
Indicators are floating.
This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.
wouldn't it be better to replace it with
Or is it wrong?
The problem of comparing numbers to double precision is far-fetched and comes from basic ignorance of the math.
Either give clear instructions on how to solve this "problem", or one of the two =)
But there will be performance problems.
Any suggestions (user level, not MT developer level)?
It is often better to do all lot and level calculations in whole numbers. Many times faster and without sampling errors in principle.
Once again.
Prices, lots, money - fixed precision.
Indicators are floating.
This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.
After that, I have simply adopted NormalizeDouble() as a mandatory procedure. I really do not yet have a good understanding of how the code sometimes works, that's why I am interested in how it should be done.
And what approach do you suggest instead of NormalizeDouble()?
Any suggestions (at user level, not MT developer level)?
It is often better to do all lot and level calculations in whole numbers. Many times faster and without sampling errors in principle.
P.S. And your ComparePrice is a very interesting solution, I didn't even get it right away.
Once again.
Prices, lots, money - fixed precision.
Indicators are floating.
This difference is in essence, although double is used to represent both. It actually determines what you call "programming style".
Again, everyone's criterion for "correctness" is different. To my understanding, for example, NormalizeDouble() is a ridiculously inefficient and, consequently, absolutely unnecessary function.
First, write several Expert Advisors on your own order and feel the storm of your customers because the stop loss has suddenly turned out to be 1 point wrong... And then explain to them about the absurdity of NormalizeDouble() function, I wonder how it will work out for you=)
And it turns out that even the price taken from the server from your order still needs to be normalised!!!
There were and are a lot of talks about incomprehensible performance of the EA when tested on incomprehensible historical data.
For price, for example. Bids, there, asks, stops:
If you take price comparison, you don't need such an overloaded function as I have.
And in simplified form it works as fast as ComparePrice:
First, write a few Expert Advisors on your own order, feel the storm of customers because the stop-loss suddenly turned out to be 1 pip wrong... And then explain them about absurdity of NormalizeDouble() function, I wonder how it will work out for you=)
Let me tell you a secret.
I have written many more custom Expert Advisors than needed to start with. I have never felt the urge to buy them because I have never gave any reason to do so. In my programs, the stoploss is guaranteed to be (and not "appears") where it should be. Accordingly, I don't have to explain anything of the kind to the customer, especially about some very specific function. It seems to me that the whole point of writing an EA is to get rid of such questions and explanations for the client.