十进制与浮点数 [英] Decimal vs float

问题描述

我想知道为什么这个表达式有效：

I wonder why this expression works:

decimal.Decimal（" 5.5"）** 1024
十进制（1.353299876254915295189966576E + 758）


但是这个导致错误


5.5 ** 1024 <回扣（最近一次调用最后一次）：

文件"<互动输入>"，第1行，在？

溢出错误：（34，'结果太大了'）


另一个怪癖是下面的：

decimal.Decimal（5.5）

decimal.Decimal("5.5")**1024 Decimal("1.353299876254915295189966576E+758")

but this one causes an error

5.5**1024

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
OverflowError: (34, ''Result too large'')

Another quirk is the follwoing:
decimal.Decimal(5.5)

回溯（最近一次调用最后一次）：

....

TypeError：无法将float转换为小数。首先将浮动转换为

a string


如果翻译先生像他那样光滑，为什么他不转换

漂浮自己？这至多是一个由可能的舍入引起的警告

浮动错误。


而不是处理尴尬的包装器，我想知道文字是否

目前解释为浮点数未来不能解释为十进制

对象？


凯

Traceback (most recent call last):
....
TypeError: Cannot convert float to Decimal. First convert the float to
a string

If Mr. interpreter is as slick as he is why doesn''t he convert the
float by himself? This is at most a warning caused by possible rounding
errors of float.

Instead of dealing with awkward wrappers, I wonder if literals
currently interpreted as floats could not be interpreted as Decimal
objects in future?

Kay

推荐答案

Kay Schluehr写道：

Kay Schluehr wrote:

我想知道为什么这个表达式有效：

I wonder why this expression works:

decimal.Decimal（" 5.5"）** 1024
十进制（" 1.353299876254915295189966576E + 758"）


结果是十进制类型，可以有*非常高*值。

但是这个导致错误

5.5 ** 1024

Traceback（最近一次调用最后一次）：
文件"<交互式输入>"，第1行，在？
OverflowError：（34，''结果太大''）


因为结果是一个浮点数，其值是有限的d用你的硬件

（CPU）。

另一个怪癖是下面的：

decimal.Decimal（5.5）

decimal.Decimal("5.5")**1024
Decimal("1.353299876254915295189966576E+758")
The result is a Decimal type, which can have *very high* values.
but this one causes an error

5.5**1024

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
OverflowError: (34, ''Result too large'')
Because the result is a float, which values are limited by your hardware
(CPU).
Another quirk is the follwoing:

decimal.Decimal(5.5)

...
TypeError：无法将float转换为Decimal。首先将浮动转换为一个字符串

如果翻译先生像他一样光滑，为什么他不能自己转换浮动？这至多是浮动可能导致的舍入错误引起的警告。

Traceback (most recent call last):
...
TypeError: Cannot convert float to Decimal. First convert the float to
a string

If Mr. interpreter is as slick as he is why doesn''t he convert the
float by himself? This is at most a warning caused by possible rounding
errors of float.

浮点数总是不精确的，所以你不会想要它们作为一个

输入参数为精确的十进制类型。


因为如果你的漂亮的十进制类型会是这样的：


十进制（" 5.49999999999999999999999999999999999999999 999999999999999999999999"）

你也会抱怨，对吗？


如需更多启示，你可以先从PEP
http：//www.python .org / peps / pep-0327 .... t-construction

我不知道目前解释为浮点数的文字是否无法被解释，而不是处理尴尬的包装器将来作为Decimal
对象？

floating points are always imprecise, so you wouldn''t want them as an
input parameter for a precise Decimal type.

Because if your nice Decimal type would then look like this:

Decimal("5.499999999999999999999999999999999999999 999999999999999999999999")

you would complain too, right?

For more enlightenment, you can start with the PEP
http://www.python.org/peps/pep-0327....t-construction
Instead of dealing with awkward wrappers, I wonder if literals
currently interpreted as floats could not be interpreted as Decimal
objects in future?

不，因为软件十进制类型比

flo慢几个数量级点数类型，你的CPU有硬件支持。


如果你要求额外的Python十进制文字，比如


mydecimal = 5.5d

或者其他什么，这是一个不同的问题。我不知道是否有什么像这样的计划。 FWIW我不认为这是必要的。使用Decimal

构造函数也是显式的，我们不需要语法糖来获得
十进制文字。


- - Gerhard

No, because a software Decimal type is orders of magnitude slower than
floating point types, for which there is hardware support by your CPU.

If you''re asking for additional Python decimal literals like

mydecimal = 5.5d

or whatever, that''s a different question. I don''t know if anything like
this is planned. FWIW I don''t think it''s necessary. using the Decimal
constructor is explicit too and we don''t really need syntactic sugar for
decimal literals.

-- Gerhard

Kay Schluehr写道：

Kay Schluehr wrote:

我想知道为什么这个表达式有效：

I wonder why this expression works:

decimal.Decimal（" 5.5"）** 1024
Decimal（" 1.353299876254915295189966576E + 758"）

但是这个会导致错误

5.5 ** 1024
跟踪（最近一次呼叫最后一次）：
文件"< interactive input>"，第1行，在？<溢出错误：（34，结果太大）

因为Decimal类型可以表示比

浮点类型更大的值范围。你的第一个表达式得到一个Decimal结果，你的第二个表达式试图得到一个浮动结果。

另一个怪癖是下面的：

decimal.Decimal （5.5）

decimal.Decimal("5.5")**1024
Decimal("1.353299876254915295189966576E+758")

but this one causes an error

5.5**1024

Traceback (most recent call last):
File "<interactive input>", line 1, in ?
OverflowError: (34, ''Result too large'')
Because the Decimal type can represent a larger range of values than the
float type. Your first expression give a Decimal result, your second
attempts to give a float result.
Another quirk is the follwoing:

decimal.Decimal(5.5)

Traceback（最近一次调用最后一次）：
...
TypeError：无法将float转换为Decimal。首先将浮动转换为一个字符串

如果翻译先生像他一样光滑，为什么他不能自己转换浮动？这至多是浮动可能导致的舍入错误引起的警告。

Traceback (most recent call last):
...
TypeError: Cannot convert float to Decimal. First convert the float to
a string

If Mr. interpreter is as slick as he is why doesn''t he convert the
float by himself? This is at most a warning caused by possible rounding
errors of float.

实际上，正如文档所说："这是一个明确的

提醒转换的详细信息（包括表示

错误）"""。否则你会得到numpties使用像

十进制（0.1）这样的结构，然后问为什么结果与

十进制（0.10000000000000001）（或类似的东西）相同）。谁需要它？

当然不是翻译先生或他的朋友。

我不知道文字目前是否被解释为尴尬包装浮动在将来不能被解释为十进制对象？

Indeed, as the documentation says: """This serves as an explicit
reminder of the details of the conversion (including representation
error)""". Otherwise you would get numpties using constructions like
Decimal(0.1) and then asking why the result was the same as
Decimal("0.10000000000000001") (or something similar). Who needs it?
Certainly not Mr. interpreter, or his c.l.py friends.
Instead of dealing with awkward wrappers, I wonder if literals
currently interpreted as floats could not be interpreted as Decimal
objects in future?

这将是解释器行为的一个非常大的变化，

和遗憾的是，它没有考虑到十进制的需要

指定计算发生的上下文。你需要

能够指定精度，舍入和许多其他值使你完全指定你的计算
。你会用什么作为

默认上下文？


问候

史蒂夫

-

Steve Holden [phone] [phone]

Holden Web LLC www.holdenweb.com

PyCon TX 2006 www.python.org/pycon/

That would be a very large change in the behaviour of the interpreter,
and unfortunately it doesn''t take account of the need in decimal to
specify the context in which a calculation takes place.You need to be
able to specify precision, rounding and a number of other values to make
your computations completely specified. What would you use as the
default context?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Steve Holden写道：

Steve Holden wrote:

如果翻译先生像他一样光滑，为什么他不自己转换
浮动？这至多是浮动可能导致的舍入错误引起的警告。

If Mr. interpreter is as slick as he is why doesn''t he convert the
float by himself? This is at most a warning caused by possible rounding
errors of float.

实际上，正如文档所说："这是一个明确的
提醒转换细节（包括表示错误）否则，您将使用诸如十进制（0.1）之类的结构获得numpties，然后询问为什么结果与十进制（0.10000000000000001）（或类似的东西）相同。谁需要呢？
当然不是解释先生或他的朋友。

Indeed, as the documentation says: """This serves as an explicit
reminder of the details of the conversion (including representation
error)""". Otherwise you would get numpties using constructions like
Decimal(0.1) and then asking why the result was the same as
Decimal("0.10000000000000001") (or something similar). Who needs it?
Certainly not Mr. interpreter, or his c.l.py friends.

花车的字符串似乎可以像

错误消息告诉：

The stringification of floats seems to work accurately just like the
error message tells:

Decimal（str（0.1））
十进制（ 0.1）


这很有趣。如果我们定义


def f（）：

print str（1.1）


并反汇编函数，我们得到：


dis.dis（f）

2 0 LOAD_GLOBAL 0（str）

3 LOAD_CONST 1（1.1000000000000001） ＃

呵呵？

6 CALL_FUNCTION 1

9 PRINT_ITEM

10 PRINT_NEWLINE

11 LOAD_CONST 0（无）

14 RETURN_VALUE


但是当我们拨打f时，我们会收到

f（）

Decimal(str(0.1)) Decimal("0.1")

This is interesting. If we define

def f():
print str(1.1)

and disassemble the function, we get:

dis.dis(f)
2 0 LOAD_GLOBAL 0 (str)
3 LOAD_CONST 1 (1.1000000000000001) #
huh?
6 CALL_FUNCTION 1
9 PRINT_ITEM
10 PRINT_NEWLINE
11 LOAD_CONST 0 (None)
14 RETURN_VALUE

But when we call f, we receive
f()

1.1


解释器先生似乎有更高的认识水平:)

我不知道是不是处理尴尬的包装，我想知道文字
目前被解释为浮点数未来不能被解释为十进制对象？

1.1

Mr. Interpreter seems to have a higher level of awareness :)
Instead of dealing with awkward wrappers, I wonder if literals
currently interpreted as floats could not be interpreted as Decimal
objects in future?

这将是解释器行为的一个非常大的变化，不幸的是它没有考虑十进制的需要来指定wh中的上下文计算发生了。

That would be a very large change in the behaviour of the interpreter,
and unfortunately it doesn''t take account of the need in decimal to
specify the context in which a calculation takes place.

我不认为这是一个很大的障碍。在当前的实现中，

编译器必须从NUMBER令牌生成一个十进制对象，而不是浮点对象的
。计算的上下文仍然是十进制的

模块对象及其属性。为什么要改变？


凯

I don''t see this as a big obstacle. With the current implementation the
compiler has to generate a decimal object from a NUMBER token instead
of a float object. The context of a calculation is still the decimal
module object and it''s attributes. Why should it be changed?

Kay

这篇关于十进制与浮点数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！