关于有理数（PEP 239 / PEP 240） [英] About Rational Number (PEP 239/PEP 240)
问题描述
实际上我很惊讶，看到Python拒绝使用
分数/有理数。然而，当我阅读PEP时，我知道
究竟为什么提案被拒绝：人们将分数与
整数进行比较，而与浮点数相比应该更公平。 br />
参数：
- 当我使用/的结果作为序列索引时，它通常是一个
错误不应该通过使程序为某些数据工作来隐藏它，因为它会破坏其他数据。
----在Python 3中（和2 w / __future__），/运算符总是
返回浮点数，浮点数作为序列索引无效，即使浮点数的
值是完整的。由于在两个整数上使用/
运算符创建了分数，因此分数的行为应该模仿
float。所以把小数类型作为序列索引应该总是被认为是错误（异常），这是一种与浮点数一致的行为。
因此，上面指定的参数变为无效，在至少在
Python 3.
- （这假设它们的类型相同）Int本身就是一个很好的类型，
不是与理性混合在一起。事物是一个整数
应该可以表达为关于它的类型的陈述。许多操作
需要整理并且不接受理性。对于不同类型的人来说，考虑一下这是很自然的。
----我同意，不应该和理性混在一起。但花车
可以。这个论点是我说大多数人用理性与整数进行比较的主要原因。许多需要投注的操作
且不接受理性也不接受花车。
其他参数：
- 慢：在分数中做加法和减法肯定是昂贵的，
但是除了浮点数之外，分数（最重的算术运算）是非常小的b / b
。它是b / b
显然做两个整数乘法和切换分子 -
分母比单个浮动分割要快得多。
- 记忆强化：要表示1/3到无限精度，需要两个 -
整数空间（理论上，2个字节）。有一些数字
难以用分数来表示，是的，但一般来说这些数字
可以使用两个长空间（可变宽度长度）来表示。并且
只要准确度不重要，就可以创建
a方法，将当前分数的损失近似为
可接受的长度无论如何，现在大多数计算机都充满了巨大的内存，为什么还要担心这么小的问题。
- Rational必须将自己呈现为十进制浮点数，否则就会
令人困惑：好的书面代码不会混淆。
编写好代码的编程人员总是使用''后面的'
场景''号码，他们不会将之前的''字符串'号码转换回计算中。并且可以创建一个约定来表示单行输出中的
分数（例如*用于乘法，/用于
除法，它们在纸质数学中不存在）这将完全消除用户的任何混淆（充分了解
惯例，大多数以前从未使用过电脑的人经常试图
使用x和：表示mult和div），即使小数
数字输出到前台UI。
I''m very surprised actually, to see that Python rejected the use of
fractional/rational numbers. However, when I read the PEP, I know
exactly why the proposal was rejected: People compared fractions with
integers, while it should be more fairly compared to floats.
Arguments against:
- When I use the result of / as a sequence index, it''s usually an
error which should not be hidden by making the program working for
some data, since it will break for other data.
----In Python 3 (and 2 w/ __future__), the / operator would always
return floats, and floats is invalid as sequence index, even if the
value of the float is whole. Since fractions is created with the /
operator on two integers, the behavior of fractions should mimics
float. So putting fractional type as sequence index should always be
considered as error (exception), a behavior consistent with floats.
Thus, the arguments specified above has turned invalid, at least in
Python 3.
- (this assumes the same type for them:) Int is a good type in itself,
not to be mixed with rationals. The fact that something is an integer
should be expressible as a statement about its type. Many operations
require ints and don''t accept rationals. It''s natural to think about
them as about different types.
----I agree, ints shouldn''t be mixed with rationals. But floats
could. This argument is the main reason why I said most people
compared rational with integers. Many operations that requires ints
and don''t accept rationals also don''t accept floats.
Other arguments:
- Slow: Doing addition and subtraction in fractions sure is expensive,
but doing division (the heaviest arithmetic operation) is extremely
fast in fractional numbers compared to in floating numbers. It is
clear that doing two integer multiplication and switching numerator-
denominator is much faster than doing a single float division.
- Memory Intensive: To represent 1/3 to infinite accuracy requires two-
integer-space (theoretically, 2 bytes). There are some numbers that
are hard to represent in fractions, yes, but in general those numbers
could be represented using two-long-space (variable-width longs). And
whenever accuracy isn''t that important, it could be possible to create
a method that would lossily approximate the current fraction to an
acceptable length. Anyway, most computers nowadays is packed with
gigantic memory, why bother with such a small issue.
- Rationals must present themselves as decimal floats or it''ll be
confusing: There will be no confusion in a good written code.
Progammers that writes good code would always use the ''behind-the-
scene'' number, they wouldn''t convert a previously ''string''ed number
back into calculation. And a convention can be created to represent a
fraction in a single line output (like * for multiplication, / for
division, they don''t exist in paper maths) that would completely
eliminate any confusion of the user (well informed about the
convention, most people that never used computer before often tried to
use x and : to represent mult and div), even when the fractional
number is outputted to the foreground UI.
推荐答案
12月15日下午2:00，Lie< Lie.1 ... @ gmail.comwrote：
On Dec 15, 2:00 pm, Lie <Lie.1...@gmail.comwrote:
我是实际上非常惊讶，看到Python拒绝使用
分数/有理数。然而，当我阅读PEP时，我知道
究竟为什么提案被拒绝：人们将分数与
整数进行比较，而与浮点数相比应该更公平。
I''m very surprised actually, to see that Python rejected the use of
fractional/rational numbers. However, when I read the PEP, I know
exactly why the proposal was rejected: People compared fractions with
integers, while it should be more fairly compared to floats.
相当蹩脚的推理，不是吗？
我使用gmpy模块中的理由非常
成功。
以下所有这些论点都很愚蠢。
Pretty lame reasoning, isn''t it?
I use the rationals from the gmpy module very
successfully.
All these arguments that follow are just silly.
>
参数：
- 当我使用/作为序列索引的结果时，它通常是一个
错误，不应该通过制作来隐藏这个程序用于
一些数据，因为它会破坏其他数据。
----在Python 3中（和2 w / __future__），/运算符会总是
返回浮点数，并且浮点数作为序列索引无效，即使浮点数的
值是完整的。由于在两个整数上使用/
运算符创建了分数，因此分数的行为应该模仿
float。所以把小数类型作为序列索引应该总是被认为是错误（异常），这是一种与浮点数一致的行为。
因此，上面指定的参数变为无效，在至少在
Python 3.
- （这假设它们的类型相同）Int本身就是一个很好的类型，
不是与理性混合在一起。事物是一个整数
应该可以表达为关于它的类型的陈述。许多操作
需要整理并且不接受理性。对于不同类型的人来说，考虑一下这是很自然的。
----我同意，不应该和理性混在一起。但花车
可以。这个论点是我说大多数人用理性与整数进行比较的主要原因。许多需要投注的操作
且不接受理性也不接受花车。
其他参数：
- 慢：在分数中做加法和减法肯定是昂贵的，
但是除了浮点数之外，分数（最重的算术运算）是非常小的b / b
。它是b / b
显然做两个整数乘法和切换分子 -
分母比单个浮动分割要快得多。
- 记忆强化：要表示1/3到无限精度，需要两个 -
整数空间（理论上，2个字节）。有一些数字
难以用分数来表示，是的，但一般来说这些数字
可以使用两个长空间（可变宽度长度）来表示。并且
只要准确度不重要，就可以创建
a方法，将当前分数的损失近似为
可接受的长度无论如何，现在大多数计算机都充满了巨大的内存，为什么还要担心这么小的问题。
- Rational必须将自己呈现为十进制浮点数，否则就会
令人困惑：好的书面代码不会混淆。
编写好代码的编程人员总是使用''后面的'
场景''号码，他们不会将之前的''字符串'号码转换回计算中。并且可以创建一个约定来表示单行输出中的
分数（例如*用于乘法，/用于
除法，它们在纸质数学中不存在）这将完全消除用户的任何混淆（充分了解
惯例，大多数以前从未使用过电脑的人经常试图
使用x和：表示mult和div），即使小数
数被输出到前台UI。
>
Arguments against:
- When I use the result of / as a sequence index, it''s usually an
error which should not be hidden by making the program working for
some data, since it will break for other data.
----In Python 3 (and 2 w/ __future__), the / operator would always
return floats, and floats is invalid as sequence index, even if the
value of the float is whole. Since fractions is created with the /
operator on two integers, the behavior of fractions should mimics
float. So putting fractional type as sequence index should always be
considered as error (exception), a behavior consistent with floats.
Thus, the arguments specified above has turned invalid, at least in
Python 3.
- (this assumes the same type for them:) Int is a good type in itself,
not to be mixed with rationals. The fact that something is an integer
should be expressible as a statement about its type. Many operations
require ints and don''t accept rationals. It''s natural to think about
them as about different types.
----I agree, ints shouldn''t be mixed with rationals. But floats
could. This argument is the main reason why I said most people
compared rational with integers. Many operations that requires ints
and don''t accept rationals also don''t accept floats.
Other arguments:
- Slow: Doing addition and subtraction in fractions sure is expensive,
but doing division (the heaviest arithmetic operation) is extremely
fast in fractional numbers compared to in floating numbers. It is
clear that doing two integer multiplication and switching numerator-
denominator is much faster than doing a single float division.
- Memory Intensive: To represent 1/3 to infinite accuracy requires two-
integer-space (theoretically, 2 bytes). There are some numbers that
are hard to represent in fractions, yes, but in general those numbers
could be represented using two-long-space (variable-width longs). And
whenever accuracy isn''t that important, it could be possible to create
a method that would lossily approximate the current fraction to an
acceptable length. Anyway, most computers nowadays is packed with
gigantic memory, why bother with such a small issue.
- Rationals must present themselves as decimal floats or it''ll be
confusing: There will be no confusion in a good written code.
Progammers that writes good code would always use the ''behind-the-
scene'' number, they wouldn''t convert a previously ''string''ed number
back into calculation. And a convention can be created to represent a
fraction in a single line output (like * for multiplication, / for
division, they don''t exist in paper maths) that would completely
eliminate any confusion of the user (well informed about the
convention, most people that never used computer before often tried to
use x and : to represent mult and div), even when the fractional
number is outputted to the foreground UI.
< cont。>
使用小数数据类型的最简单实现可能是
添加一个新运算符。一些科学计算器提供了一个特殊的
运算符来表示一个分数（有点像我b
中的小L的形状）我坚信他们的内部计算可能是
使用分数，即使使用常规除法，只有当
计算器使用分数时遇到困难（如计算sin / cos /
tan函数）或屏幕不够宽，无法代表
分数会不会使用常规分区。
Python实现的复数，为什么不是分数？
随机漫步到这里：
实际上，我的愿景不仅仅是分数，而且还有根源
数（平方根，立方根等） ），有可能
实现一种类型，其中一个数字由一个根数乘以一个
乘数加上一个变量[a + b * root（c，d） ）]。但我猜这个
会非常复杂，它需要嵌套，可能非常慢
如果实现不好。只要没有调用str（），使用它的优点就是运行速度快得多。这实际上
反映了我做纸质数学的方式，我保存了有损操作
（浮点除法，根，三角函数）直到
$结束b $ b计算（我不是原教旨主义者，所以有时候妥协是在这里和那里完成
）。
<cont.>
The easiest implementation of using fractional datatype is probably to
add a new operator. Some scientific calculators provide a special
operator to signify a fraction (somewhat on the shape of a small L in
mine) and I strongly believe that their internal calculation probably
used fractions even when regular division is used, only when the
calculator have difficulties using fraction (like calculating sin/cos/
tan function) or the screen is not wide enough to represent the
fraction would it use regular division.
Python implemented complex numbers, why not fractions?
Random ramble past here:
Actually, my vision would be not only fractions, but also rooted
number (square root, cube root, etc), it could be possible to
implement a type where a number consist of a rooted number times a
multiplier plus a variable [a + b * root(c, d)]. But I guess this
would be extremely complex and it requires nesting, probably very slow
if implementation isn''t good. The advantage of using such is much
faster operations, as long as str() is not called. This actually
reflects my way of doing paper math, I save the lossy operations
(float division, root, trigonometric function) until the very end of
calculation (I''m not fundamentalist though, so compromise sometimes is
done here and there).
12月15日， 2007 10:05 PM，Lie< Li ****** @ gmail.comwrote：
On Dec 15, 2007 10:05 PM, Lie <Li******@gmail.comwrote:
随机漫步过去：
实际上，我的愿景不仅仅是分数，而且还有根据
数（平方根，立方根等），有可能实现一个类型数字由一个带根的数字乘以一个
乘数加上一个变量[a + b * root（c，d）]。但我猜这个
会非常复杂，它需要嵌套，可能非常慢
如果实现不好。只要没有调用str（），使用它的优点就是运行速度快得多。这实际上
反映了我做纸质数学的方式，我保存了有损操作
（浮点除法，根，三角函数）直到
$结束b $ b计算（虽然我不是原教旨主义者，所以有时候妥协是在这里和那里完成的
）。
Random ramble past here:
Actually, my vision would be not only fractions, but also rooted
number (square root, cube root, etc), it could be possible to
implement a type where a number consist of a rooted number times a
multiplier plus a variable [a + b * root(c, d)]. But I guess this
would be extremely complex and it requires nesting, probably very slow
if implementation isn''t good. The advantage of using such is much
faster operations, as long as str() is not called. This actually
reflects my way of doing paper math, I save the lossy operations
(float division, root, trigonometric function) until the very end of
calculation (I''m not fundamentalist though, so compromise sometimes is
done here and there).
您正在寻找计算机代数系统。试着用心：
http://code.google.com/p/ sympy /
Fredrik
You''re looking for a computer algebra system. Try sympy:
http://code.google.com/p/sympy/
Fredrik
这篇关于关于有理数（PEP 239 / PEP 240）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
