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
Good catch. However from a trading point of view, you need either 1.70060 or 1.70061, they are both correct. So maybe you will want to chose the best one according to your trading operation, rather than relying on a mathematical rounding scheme.
In this scenario, if your step-size == 0.00001 then you should only get 1.70061 as a result, and a value of 1.70060 is close but incorrect.
In this scenario, if your step-size == 0.00001 then you should only get 1.70061 as a result, and a value of 1.70060 is close but incorrect.
Sorry but I don't understand your reasoning. What is "step-size" ?
Sorry but I don't understand your reasoning. What is "step-size" ?
step-size is the value of the step that you are rounding to. eg. lot_step = 0.01 (2 digits), or tick_size = 0.00005...
In this example-case, we are working with a 5 digit symbol with a tick-size == 0.00001
step-size is the value of the step that you are rounding to. eg. lot_step = 0.01 (2 digits), or tick_size = 0.00005...
In this example-case, we are working with a 5 digit symbol with a tick-size == 0.00001
Please understand that a "trading point of view" is not relevant here. This is purely a mathematical issue for which @amrali has provided a solution.
There is no need to discuss the "trading point of view" here as it is off-topic for this thread and will ultimately escalate into a another heated debate ending in someone being banned again. So, please try to avoid that!
Please understand that a "trading point of view" is not relevant here. This is purely a mathematical issue for which @amrali has provided a solution.
There is no need to discuss the "trading point of view" here as it is off-topic for this thread and will ultimately escalate into a another heated debate ending in someone being banned again. So, please try to avoid that!
I am just trying to understand what @nicholishen said. There is no reason for an heated debate or whatever. This is a forum about trading, isn't ?
Please explain me why from a calculated price of 1.700605, a real price of 1.70060 is "incorrect" ? If I am missing something I would like to understand it.
I am just trying to understand what @nicholishen said. There is no reason for an heated debate or whatever. This is a forum about trading, isn't ?
Please explain me why from a calculated price of 1.700605, a real price of 1.70060 is "incorrect" ? If I am missing something I would like to understand it.
Like Fernando said, "this is purely a mathematical issue", and in the mathematical sense the expected result is for the 5 to be rounded up to the nearest digit instead of down. The MathRound function is producing inconsistent results and if you aim to avoid inconsistency then I'd advise using ND instead, as wisely suggested by @amrali. To get us all back on topic, the CDouble library no longer uses the MathRound function in favor of more consistent results.
I am just trying to understand what @nicholishen said. There is no reason for an heated debate or whatever. This is a forum about trading, isn't ?
Please explain me why from a calculated price of 1.700605, a real price of 1.70060 is "incorrect" ? If I am missing something I would like to understand it.
Hi Alain Verleyen, you are correct regarding your point. For a single calculation, it may not make much difference. However, as you do more calculations which involve rounding at each step, the final error will be magnified. Consider a martingale strategy, where each calculated lotsize is derived from the previous one (which was sent to the trading server as a rounded value). The issue we consider here is called "Propagation of errors". So, I think it would be more safe to use NormalizeDouble() in order to keep the intermediate errors as low as possible.
Second, there also exists a more technical point here. Using the function MathRound(number * power) / power with edge numbers, you will get either the upper rounded value sometimes, or the lower rounded value, the other times depending on the input. This inconsistency in rounding may not matter from a trading point of view, as you mentioned in your comment, as long as you get a final rounded value (either up or down), so the trading server will not complain. However, as stated by Mark Watkin, such inconsistency in rounding may introduce hard to detect bugs in the client code that uses the "CDouble" library.
By the way, using another variant of the above function like MathRound(number / point) * point with edge numbers, you get a rounded number (either up or down), or more interestingly you do not get an exact rounded number! (the result differs from the expected value by 1 Epsilon, but it is OK for trading functions)
The following script helps to demonstrate these issues, more clearly:
Therefore, it would be better to replace MathRound(number) with NormalizeDouble(number, 0) to avoid inconsistent results when arithmetic (mid-point) rounding is indicated.
The other good alternative for mid-point rounding: use MathRound() + apply half-epsilon correction.
(This was implemented in the MathRoundCorrect() function as posted before).
According to this wikipedia article, there many other rounding modes that serve different puposes. You are free to choose the one that fits your requirements. Best regards.
https://en.wikipedia.org/wiki/Rounding