Excel与C＃编号的差异
任何人都可以阐明为什么我可能会看到非常小的（10 ^ -08）数字差异，当在Excel中使用完全相同的数字与C＃？
我有一个公式，并使用相同的input。 在Excel中，我得到一个数字 – 在C＃中，我得到另一个数字。 差别很小。
我在C＃中使用双打，并进行划分。 我已经尝试使用小数没有太大的区别
编辑：这是驾驶我坚果 – 我花了整整一上午 – 任何想法？
不同之处在于c＃和excel中的MidPoint舍入规则不同。
尝试Math.Round(someNumber,precision,MidpointRounding.AwayFromZero);
有了这么小的差异（10 ^ -08，你说），我怀疑中间计算是造成这个问题。 请注意，双精度值是64位，但寄存器可以使用80位精度。 所以，如果你有一个代码序列，编译器将所有的中间计算都保存在寄存器上，那么实际上比在代码中的不同点上进行相同的计算要精确得多，强制中间结果保持在64位存储位置。
如果在Excel单元格中存储值作为计算的一部分，这也会导致将中间计算截断为64位精度。
你真的需要显示你的代码：同时显示（a）Excel的计算结果（是工作表公式还是你编程的单元格值）？（b）你正在做的C＃计算。 如果你这样做，那么我们应该能够更准确地帮助你。 但是，到目前为止所提供的信息，我们只能做出广泛的猜测。
迈克
这个话题也使我疯狂，以及=）。
几年前，我发现Excel的工作表=ROUND()函数产生与VBA的ROUND()函数不同的结果。 我还发现，VBA和MySQL版本4.x（不记得确切的版本;在5.x之前）使用完全相同的algorithm来轮换浮点数types。 他们似乎在使用“银行家四舍五入”的有缺陷的版本。 MySQL最终在未来的版本中改变了四舍五入，但有人指出VBA和MySQL 4.x实现ROUND的方式之间的相似之处可能在于它们都依赖于C编程语言（可能用于创buildVBA和MySQL）实现了Round。
VBA和MySQL 4.x都简单地实现了C用来实现四舍五入的function。 然而，许多当代编程语言因为各种原因select了自己的舍入方法， 有时候它会符合IEEE规范，有时会匹配他们认为用户期望的东西。 在VBA和MySQL 4.x的情况下，银行家四舍五入的错误版本从来没有被用户期待（因此你的失望），所以未来的语言实现了舍入的新版本或提供的替代品（如C＃中的decimaltypes）用户将能够产生预期的价值并对整个过程有更多的控制权。
你可以试着看这篇文章，参考VBA的四舍五入来进一步阐明这个问题： http : //www.vb-helper.com/howto_round_to_specified_digits.html
你确定你在Excel中看到了整个号码吗？
格式化为“常规”的数字将以〜12位数的精度显示（如果列的宽度不够12位，则显示更less）。 例如，如果将公式“= PI（）”放入具有“常规”格式（Excel中的默认值）的单元格中，并将列宽度足够，则会看到3.141592654。 请注意，如果列不够宽，则会看到更less的精度数字。
现在，使用自定义数字格式“0.00000000000000000”格式化单元格，您将看到3.14159265358979000（如果列足够宽）。
请注意，Excel实际上在内部存储具有超过15位精度的= PI（）的值。 您可以通过在单元格中input“=（PI（） – 3.14159265358979）”来看到这一点 – 确保在公式中包含括号。
现在，为了好玩，在单元格中input“= PI（） – 3.14159265358979”，你会看到你得到零。 在某些情况下，例如在结果几乎为零的地方添加或减去，Excel实际上会将结果转换为0.0（如果您不知道发生这种情况，可能会使您发疯）。