Python中出现意外的浮点表示 [英] Unexpected floating-point representations in Python

问题描述

你好，我在Python中使用一个字典来存储一些城市，如下所示：

  population = {' ：17.8伊斯坦布尔：13.3，卡拉奇：13.0，孟买：12.5} 
  

现在，如果我使用命令打印人口，我得到结果：

  {'卡拉奇'：13.0，'上海'：17.800000000000001，'伊斯坦堡'：13.300000000000001，'mumbai'：12.5} 
  

而如果我使用命令 print population ['Shanghai'] 我得到初始输入 17.8 。

我的问题是，如果 17.8 和 13.3 分别变成 17.800000000000001 和 13.300000000000001 所有信息如何产生？为什么它存储在那里，因为我的初始输入表示我不需要额外的信息，至少在我所知道的。

解决方案

这在Python 3.1中已经改变了。从新功能页面：

Python现在使用David Gay的算法来找到不更改其值的最短
浮点表示。这个
应该有助于缓解二进制浮点
点数之间的一些混乱。

这个意义很容易被看到，像$ code> 1.1 其中
在二进制浮点中没有完全相同的值。由于
没有精确的等价物，所以像$ float（'1.1'）这样的表达式计算为
最接近的可表示值，即 0x1.199999999999ap + 0 在十六进制
或 1.100000000000000088817841970012523233890533447265625 十进制。
最接近的值仍然在随后的浮点
计算中使用。

新增数字是如何显示的。以前，Python使用了
简单的方法。 repr（1.1）的值被计算为格式（1.1，
'.17g'）评估为'1.1000000000000001'。
的优点是使用17位数字，它依赖于IEEE-754保证来确保
eval（repr（1.1））将往返完全符合其原始价值。
缺点是许多人发现输出是混淆
（将二进制浮点
表示的内在限制误认为是Python本身的一个问题）。

repr（1.1）的新算法更智能，并返回'1.1'。
有效地，它搜索所有等效的字符串表示（一个
，存储与相同的底层浮点值），并返回
最短表示。

新算法在可能的情况下往往会发出更清晰的表示，而
却不会改变底层值。所以，仍然是
，即 1.1 + 2.2！= 3.3 即使表示可能会建议
否则。

新算法取决于底层
浮点实现中的某些功能。如果没有找到所需的功能，
将继续使用旧的算法。此外，文本pickle
协议通过使用旧的
算法确保跨平台的可移植性。

（由Eric Smith和Mark Dickinson提供; a href =http://bugs.python.org/issue1580 =nofollow> issue 1580 ）

Hello I am using a dictionary in Python storing some cities and their population like that:

population = { 'Shanghai' : 17.8, 'Istanbul' : 13.3, 'Karachi' : 13.0, 'mumbai' : 12.5 }

Now if I use the command print population, I get the result:

{'Karachi': 13.0, 'Shanghai': 17.800000000000001, 'Istanbul': 13.300000000000001, 'mumbai': 12.5}

whereas if I use the command print population['Shanghai'] I get the initial input of 17.8.

My question to you is how does the 17.8 and the 13.3 turned into 17.800000000000001 and 13.300000000000001 respectively? How was all that information produced? And why is it stored there, since my initial input denotes that I do not need that extra information, at least as far as I know.

解决方案

This has been changed in Python 3.1. From the what's new page:

Python now uses David Gay’s algorithm for finding the shortest floating point representation that doesn’t change its value. This should help mitigate some of the confusion surrounding binary floating point numbers.

The significance is easily seen with a number like 1.1 which does not have an exact equivalent in binary floating point. Since there is no exact equivalent, an expression like float('1.1') evaluates to the nearest representable value which is 0x1.199999999999ap+0 in hex or 1.100000000000000088817841970012523233890533447265625 in decimal. That nearest value was and still is used in subsequent floating point calculations.

What is new is how the number gets displayed. Formerly, Python used a simple approach. The value of repr(1.1) was computed as format(1.1, '.17g') which evaluated to '1.1000000000000001'. The advantage of using 17 digits was that it relied on IEEE-754 guarantees to assure that eval(repr(1.1)) would round-trip exactly to its original value. The disadvantage is that many people found the output to be confusing (mistaking intrinsic limitations of binary floating point representation as being a problem with Python itself).

The new algorithm for repr(1.1) is smarter and returns '1.1'. Effectively, it searches all equivalent string representations (ones that get stored with the same underlying float value) and returns the shortest representation.

The new algorithm tends to emit cleaner representations when possible, but it does not change the underlying values. So, it is still the case that 1.1 + 2.2 != 3.3 even though the representations may suggest otherwise.

The new algorithm depends on certain features in the underlying floating point implementation. If the required features are not found, the old algorithm will continue to be used. Also, the text pickle protocols assure cross-platform portability by using the old algorithm.

(Contributed by Eric Smith and Mark Dickinson; issue 1580)

这篇关于Python中出现意外的浮点表示的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！