I think that all these faults above are beyond the scope of practical use of this solution to accelerate rounding of positive integers, because few people need precision at the 16-digit level. And these bugs arise from all sorts of overflows at the dots levels of the compiler itself.
A100: Floor(), ceil(), round() are there for that purpose - so there are no questions
I'm not forbidding you to use them. You are welcome to use them. I will use them myself. But if I create an algorithm where speed is important, I will use this rounding variant taking into account all the nuances of this method. I think it would be useful for other programmers to know about the existence of this alternative. The discussion is exactly what we need to know about the nuances of this rounding method. Thank you all very much for that. Am I not right?
DBL_MIN andDBL_EPSILON don't work - too small. Perhaps it makes sense to leave 0.999999999999999999 (16 nines - the maximum number of digits after the decimal point in double)
So, DBL_EPSILON is 16 decimal places:2.2204460492503131e-016.
In your case, you actually get one, as the difference is only 1e-16, which is 2 times less than epsilon.
So DBL_EPSILON is 16 decimal places:2.2204460492503131e-016
And in your case you actually get one, as the difference is only 1e-16, which is 2 times less than epsilon.
Yeah, I get that, but it doesn't work. Turns out it doesn't work with 16 nines either (strange, it seemed to work before). It only works with 15 nines.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
Yes, but if:
then it's fine.
A100:
I don't get it. What's the problem?
It remains to be seen if it will be OK for any number x
Of course it won't...
After all, if this happens:
then, the questions are neither for me nor for this idea.
What's the problem?
see my previous post
then, the questions are neither for me, nor for this idea.
I think that all these faults above are beyond the scope of practical use of this solution to accelerate rounding of positive integers, because few people need precision at the 16-digit level. And these bugs arise from all sorts of overflows at the dots levels of the compiler itself.
Floor(), ceil(), round() are there for that purpose - so there are no questions
I'm not forbidding you to use them. You are welcome to use them. I will use them myself. But if I create an algorithm where speed is important, I will use this rounding variant taking into account all the nuances of this method. I think it would be useful for other programmers to know about the existence of this alternative. The discussion is exactly what we need to know about the nuances of this rounding method. Thank you all very much for that. Am I not right?
DBL_MIN andDBL_EPSILON don't work - too small. Perhaps it makes sense to leave 0.999999999999999999 (16 nines - the maximum number of digits after the decimal point in double)
So, DBL_EPSILON is 16 decimal places:2.2204460492503131e-016.
In your case, you actually get one, as the difference is only 1e-16, which is 2 times less than epsilon.
So DBL_EPSILON is 16 decimal places:2.2204460492503131e-016
And in your case you actually get one, as the difference is only 1e-16, which is 2 times less than epsilon.
Yeah, I get that, but it doesn't work. Turns out it doesn't work with 16 nines either (strange, it seemed to work before). It only works with 15 nines.