我有一个关于模的问题。该模运算另一个发现的一个数字相除的余数。我期待了0.5％结果0.1 = 0。但是，当我运行这个在PHP或.net我得到0.1。

I have a question about modulo. The modulo operation finds the remainder of division of one number by another. I was expecting that the result of 0.5 % 0.1 = 0. But when I run this in PHP or .net I get 0.1.

在code在PHP中我跑是：

The code in php I ran was:

var_dump(fmod(0.5, 0.1));

在.NET中我尝试了以下的结果：

In .net I tried the following for the outcome:

Console.WriteLine(0.5%0.1);

我也尝试了在线计算器 http://www.calculatorpro.com/modulo-calculator/ 。

所有这些3种方法给了我0.1的答案。

All these 3 methods gave me 0.1 as answer.

但是，当我键入这在谷歌我得到的结果我预期的http://www.google.nl/search?source=ig&hl=nl&q=0.5%20mod%200.1&meta=.

But when I type this in google I get the result I expected http://www.google.nl/search?source=ig&hl=nl&q=0.5%20mod%200.1&meta=.

这是在.NET / PHP的错误或谷歌是否知道正确的答案？任何人都可以解释为什么这些差异会出现？

Is this an bug in .net/php or does google know the right answer? Can anyone explain why these differences occur?

推荐答案

您在PHP中获得或数C＃或C ++或Python或什么，当你问0.1是双precision浮点数，这意味着它是一个有限的十进制 - 与53显著位，包括第1位 - 在基地2。实际上你会得到的是最近恰好重presentable号0.1，我认为这是正是0.1000000000000000055511151231257827021181583404541015625。

The number you get in PHP or C# or C++ or Python or whatever when you ask for 0.1 is a double-precision floating-point number, which means it's a finite "decimal" -- with 53 significant bits including the first 1-bit -- in base 2. In fact what you'll get is the nearest exactly-representable number to 0.1, which I think is exactly 0.1000000000000000055511151231257827021181583404541015625.

在另一方面，0.5的是的一个有限bicimal;你得到的价值，当你问这将是恰好为0.5。

On the other hand, 0.5 is a finite "bicimal"; the value you get when you ask for that will be exactly 0.5.

因此​​，0.5是只是一点点少于5次0.1，因此，0.5 MOD 0.1，其实是给予你的东西比0.1稍微少一点。事实上，我认为这是完全0.09999999999999997779553950749686919152736663818359375。

Therefore, 0.5 is just a little bit less than 5 times "0.1", and therefore "0.5 mod 0.1" actually gives you something a little bit less than 0.1. In fact, I think it's exactly 0.09999999999999997779553950749686919152736663818359375.

现在，当你问PHP或C＃或其他显示这个数字，它会显示数字部分数量有限。你真的不希望它显示了整个可怕的事情。 （试想一下：假设你只要求0.1将显示;你想要的许许多多位怪物，或者你想0.1这样想吗？）。而数量其实非常接近0.1;除非你要求超过15 precision正确的事情，显示数字仅仅是0.1。

Now, when you ask PHP or C# or whatever to display this number, it will display some limited number of digits. You don't really want it to display the whole ghastly thing. (Consider: suppose you just ask for 0.1 to be displayed; do you want an umpteen-digit monstrosity, or do you want "0.1"? Thought so.) And the number is in fact very close to 0.1; unless you ask for more than 15 digits of precision the correct thing to display is just "0.1".

注意（这是Python的，我碰巧有方便的）：

Observe (this is Python, which I happened to have handy):

>>> for n in range(10,20): print (("%%.%dg"%n)%(0.5%0.1))

0.1
0.1
0.1
0.1
0.1
0.1
0.09999999999999998
0.099999999999999978
0.0999999999999999778
0.0999999999999999778

所以：不是bug;浮点是不恰当的precision计算并不是真正的问题（有时是合适的，有时没有，这种事情是要明白它在做什么和你需要什么）;可能会或可能不会表明您会做的更好使用整数，这取决于你真正需要的是什么。

So: not a bug; not really a matter of floating-point being inappropriate for "precision calculations" (sometimes it's appropriate, sometimes not; the thing is to understand what it's doing and what you need); may or may not indicate that you'd have done better to use integers, depending on what your real need is.

有关更多有关这个东西可能比你要知道，看一看的每个计算机科学家应该知道浮点运算。

For much more about this stuff than you probably want to know, take a look at "What every computer scientist should know about floating-point arithmetic".

至于为什么谷歌的计算器给出0预期的答案，我不知道。也许他们正在使用的十进制算法 - 实基10号 - 尽量减少意外的惊喜。 （这通常比使用原生的浮点慢得多，但谷歌拥有的很多的CPU可用的，我敢打赌工作的搜索处理机器做的只有一小部分有什么用计算器。）

As for why Google's calculator gives the expected answer of 0, I don't know. Perhaps they're using decimal arithmetic -- real base-10 numbers -- to minimize unexpected surprises. (This is typically much slower than using native floating-point, but Google has a lot of CPU available and I bet only a tiny fraction of the work their search-handling machines do has anything to do with the calculator.)