NormalizePrice() any suggestions on how to do this better - page 2

New comment
 
Alexandre Borela #:

Aging? MQL's is way more capable than the TradingView's language, even with the bugs, the only better alternative is to just
write directly in C++.

The standard library serves only to show the capabilities of the language, but most experienced programmers are either using
alternative open source ones or private solutions.

It is not a language aimed at novices and that's good, it gives power to those who know how to code instead of restricting them
because feature X would be too complex for a novice to understand.

Hi Alexandre, Dominik,

i didn't want to start a discussion about languages (that was already senseless in the 90's, when i did ANSI-C and C++ started to become really popular) - everybody has his own reason why he prefers this or that language/product for his use. 

What i meant wasn't technical: If you want to hold its own on the market in the long term against a growing number of competitors with fancy new features the IMHO most important argument will be robustness and quality.

Concerning the Standard Library: i agree with you, but that's just our personal opinion, as long it's not officially/publicly stated. What counts to the "Outer world" is the message to them, and that's stated in the docs:

"MQL5 Standard Library is written in MQL5 and is designed to facilitate writing programs (indicators, scripts, experts) for end users. Library provides convenient access to the most of the internal MQL5 functions."

So if there are known BUGS (i don't talk about a poor interface like where you have to hand over an array AND the array's size as a 2nd parameter :), then these should be fixed.




 
Thomas S. #:

Hi Alexandre, Dominik,

i didn't want to start a discussion about languages (that was already senseless in the 90's, when i did ANSI-C and C++ started to become really popular) - everybody has his own reason why he prefers this or that language/product for his use. 

What i meant wasn't technical: If you want to hold its own on the market in the long term against a growing number of competitors with fancy new features the IMHO most important argument will be robustness and quality.

Concerning the Standard Library: i agree with you, but that's just our personal opinion, as long it's not officially/publicly stated. What counts to the "Outer world" is the message to them, and that's stated in the docs:

"MQL5 Standard Library is written in MQL5 and is designed to facilitate writing programs (indicators, scripts, experts) for end users. Library provides convenient access to the most of the internal MQL5 functions."

So if there are known BUGS (i don't talk about a poor interface like where you have to hand over an array AND the array's size as a 2nd parameter :), then these should be fixed.




I would prefer for them to just deprecate the standard library and point to a series of open source implementations so that people can choose
the one that they find best or implement their own. This way MetaQuotes' devs could focus on compiler's issues and adding new features to it
like returning references, exceptions, allowing function pointers to point to methods etc...




 
Alexandre Borela #:

I would prefer for them to just deprecate the standard library and point to a series of open source implementations so that people can choose
the one that they find best or implement their own. This way MetaQuotes' devs could focus on compiler's issues and adding new features to it
like returning references, exceptions, allowing function pointers to point to methods etc...




A very good suggestion!

 

So I have investigated on the rounding function of NormalizePrice

Here is my finding

std-lib:

NormalizeDouble(MathRound(1.3555/0.00001)*0.00001,3);

will give as result: 1.3559999999999999

while my function will return: 1.3560000000000001

Now the question is, which is better?

 
Dominik Christian Egert #:

So I have investigated on the rounding function of NormalizePrice

Here is my finding

std-lib:

will give as result: 1.3559999999999999

while my function will return: 1.3560000000000001

Now the question is, which is better?

It depends on what you are trying to achieve, the name of the function NormalizeDouble or NormalizePrice is too
vague, do you want to round to the nearest tick? truncate? round? round down? round up?

It also depends on where you want to use the result, if I see 1.35599999 or 1.35600001 in the debugger I would
consider both values equal because of the way doubles work, I know they are imprecise and everytime I use them,
I always consider a margin of error (or epsilon) to compare them.

This is specially true if you use PrintFormat and specify the precision, it will print 1.356 in both cases.

   double a = 1.3559999999999999;
   double b = 1.3560000000000001;
   PrintFormat("%.3f", a);
   PrintFormat("%.3f", b);

So in this case, it would be pointless to worry about the digits.

 
Right.

Interesting aspect. I use it to "normalize" the ATR value and then compare it to price...

That's the main use case, but they are, given the "significant digits" equal.


 
Dominik Christian Egert #:
Right.

Interesting aspect. I use it to "normalize" the ATR value and then compare it to price...

That's the main use case, but they are, given the "significant digits" equal.


Avoid rouding them, it'll introduce more errors.

https://floating-point-gui.de/errors/comparison/

Although the author does not recomend fixed epsilons:

Math.abs(a-b) < 0.00001
if your case is simple enough and you know the precision,
they are perfectly valid.
 
Dominik Christian Egert #:
Right.

Interesting aspect. I use it to "normalize" the ATR value and then compare it to price...

That's the main use case, but they are, given the "significant digits" equal.


You don't need to normalize to compare, you need to normalize only to use price with trading functions. That's different things.

 
I should explain where the issue is coming from.

I take the ATR and half it. I add these two values to a given level and subtract them from the same. Now I need to compare these values to the current price.

So if I add them, then in some situations the value is lower than the price even if it (when rounded correctly) weren't. So it's off by a fraction. But this leads to wrong assumptions.

Also if (I know it's not the case for this Examen, but there are situations in which this applies) I divide 0.00009, I get as result 0.000044999999 so this rounds to 0.00004, which is wrong for my use case. It would need to be 0.00005.

I didn't expect this to be so precisely working, but if I ignore this error, I get bad results. If I manage this, results are correct.

Well, that's the source.

So I was thinking how to solve this and therefore I wrote my own function to "Normalize Price".

So, yes, I need to round the value. Especially because ATR values are way off from being "compatible" with price values.

That's my issue at the moment.
 
Thomas S. #:

Hi Alexandre, Dominik,

i didn't want to start a discussion about languages (that was already senseless in the 90's, when i did ANSI-C and C++ started to become really popular) - everybody has his own reason why he prefers this or that language/product for his use. 

What i meant wasn't technical: If you want to hold its own on the market in the long term against a growing number of competitors with fancy new features the IMHO most important argument will be robustness and quality.

Concerning the Standard Library: i agree with you, but that's just our personal opinion, as long it's not officially/publicly stated. What counts to the "Outer world" is the message to them, and that's stated in the docs:

"MQL5 Standard Library is written in MQL5 and is designed to facilitate writing programs (indicators, scripts, experts) for end users. Library provides convenient access to the most of the internal MQL5 functions."

So if there are known BUGS (i don't talk about a poor interface like where you have to hand over an array AND the array's size as a 2nd parameter :), then these should be fixed.




Nobody said the bugs are not fixed, if they are reported.

The problem is the fact there are bugs, a standard library which is not reliable is not a standard. Then if there is a bug fix you need to wait it to be available or fix it yourself. Beside that most classes are just wrappers to mql functions.

1234
New comment