Is it ok to have rounding errors when rounding to integers?

4 次查看（过去 30 天）
Andreas Brinch Nielsen
编辑： dpb 2017-1-20
Run the following:
round(100000,-5)
In my opinion it should return 100000 exactly, but it returns 100000+eps(100000). Do you think this is a bug, or is it an expected round off error because of floating point arithmetic?

请先登录，再回答此问题。

采纳的回答

dpb
dpb 2017-1-19
编辑：dpb 2017-1-20
Does appear to be a "quality of implementation" issue. Hadn't ever used it w/ the negative optional argument but looks like does have some artifacts, not clear quite where this one would come from. Since it's builtin function can't see implementation but that's what it looks like happens...altho for this input the "deadahead"
>> fix(100000/1E5)*1E5
ans =
100000
>>
works so not sure what must be going on internally.
Looks to me to be worth a bug report.
A workaround I'm sure you've already thought of is to wrap the call in another round...
>> round(round(100000,-5))
ans =
100000
>>

更多回答（3 个）

John D'Errico
John D'Errico 2017-1-19
编辑：John D'Errico 2017-1-19
In general, you cannot represent numbers (that have digits to the right of the decimal point) exactly in floating point arithmetic. So when you use round in this form, you are rounding to the 5th decimal place to the right of the decimal point.
The problem is, only you know that the result should be an integer, because it was an integer before the "round" operation.
round(100000,-5) == 100000
ans =
logical
0
sprintf('%0.55f',round(100000,-5))
ans =
100000.0000000000145519152283668518066406250000000000000000000
What happened is round (with a second operand) works by scaling the number, then performing a round, and then scaling back. But it depends on how the code was written internally, and we don't see the code for round.
This works:
x = 100000;
round(x*10^5)/10^5 == x
ans =
logical
1
But this fails:
round(x/10^-5)*10^-5 == x
ans =
logical
0
My guess is that for negative second argument, this is what they do. However, it would be better to do different operations, depending on whether the second argument is positive or negative.
  6 个评论
显示 4更早的评论
Andreas Brinch Nielsen
Andreas Brinch Nielsen 2017-1-20
Floating point numbers do not have problems representing integer numbers. Of course, when you start doing operations on them, these can introduce inaccuracies (as in this example), but at least in this example I would say that it is because of a bad implementation.
dpb
dpb 2017-1-20
"Floating point numbers do not have problems representing integer numbers." up to the length of the number of digits representable by the chosen precision, of course. That's roughly 15 decimal digits for double.

请先登录，再进行评论。

Guillaume
Guillaume 2017-1-19
In my opinion it's a bug that you should report to Mathworks.
It's ironical that round produces a less rounded number than you started with.
Andreas Brinch Nielsen
I wrote a bug report to Mathworks before posting this question, but they started arguing that it was expected behavior, and I just wanted other opinions. Thanks all.
  1 个评论
dpb
dpb 2017-1-20
I'd refer back to the function description in the documentation as to its definition of what is expected output. (If it were my report as I've harped on the issue there is no actual language specification for years, I'd ask what the internal language design document says about it :) )

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Logical 的更多信息

标签

产品

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by