Re: [Python-ideas] Python Float Update
I'm going to show a few examples of how Decimals violate the fundamental laws of mathematics just as floats do.
Decimal is also uses sign and mantissa, except it's Base 10. I think Decimal should use numerators and denominators, because they are more accurate. That's why even Decimal defies the laws of mathematics. -Surya Subbarao
On 03/06/2015 23:18, u8y7541 The Awesome Person wrote:
Defying the laws of mathematics isn't a key issue here as practicality beats purity. Try beating the laws of the BDFL and the core devs and it's the Comfy Chair, terribly sorry and all that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Wed, Jun 03, 2015 at 03:18:51PM -0700, u8y7541 The Awesome Person wrote:
The decimal module is an implementation of the decimal floating point arithmetic based on the General Decimal Arithmetic Specification: http://speleotrove.com/decimal/decarith.html and IEEE standard 854-1987: www.cs.berkeley.edu/~ejr/projects/754/private/drafts/854-1987/dir.html The decimal module is not free to do whatever we want. It can only do what is specified by those standards. If you want to modify the decimal module to behave as you suggest, you are free to copy the module's source code and modify it. (It is open source, like all of Python.) This would be an interesting experiment for somebody to do. -- Steve
On Jun 4, 2015 8:12 AM, "Steven D'Aprano" <steve@pearwood.info> wrote:
The decimal module is not free to do whatever we want. It can only do what is specified by those standards.
That's not quite true. The class decimal.Decimal must obey those standards. We could easily add decimal32/64/128 types to the module for those different objects (and I think we probably should). For that matter, it wouldn't violate the standards to add decimal.PythonDecimal with some other behaviors. But I can't really think of any desirable behaviors that are mathematically possible to put there. There isn't going to be a decimal.NeverSurprisingDecimal class in there.
On Jun 4, 2015, at 08:21, David Mertz <mertz@gnosis.cx> wrote:
If we add decimal32/64/128 types, presumably they'd act like the types of the same names as specified in the same standards. Otherwise, that would be very surprising. Also, I'm not entirely sure we want to add those types to decimal in the stdlib. It would be a lot less work to implement them in terms of an existing C implementation (maybe using the native types if the exist, Intel's library if they don't). But I don't think that's necessarily desirable for the stdlib. Is this a big enough win to justify CPython being written in C11 instead of C90 (or, worse, sometimes one and sometimes the other, or a combination of the two), or to add a dependency on a library that isn't preinstalled on most systems and takes longer to build than all of current CPython 3.4? For a PyPI library, none of those things matter (in fact, a PyPI library could use C++ on platforms where the native types from the C++ TR exist but the C ones don't, or use Cython or CFFI or Boost::Python instead of native code, etc.), and the stdlib's decimal docs could just point to that PyPI library.
For that matter, it wouldn't violate the standards to add decimal.PythonDecimal with some other behaviors. But I can't really think of any desirable behaviors that are mathematically possible to put there.
I think it would still make sense to put it somewhere else. A module that declares that its behavior corresponds to a standard that adds a little bit of standard-irrelevant behavior is fine. For example, a conversion from Fraction to Decimal that worked "in the spirit of the standards" and documented that it wasn't specified by either standard. But adding a whole new class as complex as Decimal means half the module is now standard-irrelevant, which seems a lot more potentially confusing to me.
There isn't going to be a decimal.NeverSurprisingDecimal class in there.
Start with your favorite axioms for the integers and your favorite construction of the reals, then negate the successor axiom. Now you have a fully-consistent, never-surprising, easily-implementable real number type that follows all the usual mathematical laws over its entire set of values, {0}. :)
On 03/06/2015 23:18, u8y7541 The Awesome Person wrote:
Defying the laws of mathematics isn't a key issue here as practicality beats purity. Try beating the laws of the BDFL and the core devs and it's the Comfy Chair, terribly sorry and all that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On Wed, Jun 03, 2015 at 03:18:51PM -0700, u8y7541 The Awesome Person wrote:
The decimal module is an implementation of the decimal floating point arithmetic based on the General Decimal Arithmetic Specification: http://speleotrove.com/decimal/decarith.html and IEEE standard 854-1987: www.cs.berkeley.edu/~ejr/projects/754/private/drafts/854-1987/dir.html The decimal module is not free to do whatever we want. It can only do what is specified by those standards. If you want to modify the decimal module to behave as you suggest, you are free to copy the module's source code and modify it. (It is open source, like all of Python.) This would be an interesting experiment for somebody to do. -- Steve
On Jun 4, 2015 8:12 AM, "Steven D'Aprano" <steve@pearwood.info> wrote:
The decimal module is not free to do whatever we want. It can only do what is specified by those standards.
That's not quite true. The class decimal.Decimal must obey those standards. We could easily add decimal32/64/128 types to the module for those different objects (and I think we probably should). For that matter, it wouldn't violate the standards to add decimal.PythonDecimal with some other behaviors. But I can't really think of any desirable behaviors that are mathematically possible to put there. There isn't going to be a decimal.NeverSurprisingDecimal class in there.
On Jun 4, 2015, at 08:21, David Mertz <mertz@gnosis.cx> wrote:
If we add decimal32/64/128 types, presumably they'd act like the types of the same names as specified in the same standards. Otherwise, that would be very surprising. Also, I'm not entirely sure we want to add those types to decimal in the stdlib. It would be a lot less work to implement them in terms of an existing C implementation (maybe using the native types if the exist, Intel's library if they don't). But I don't think that's necessarily desirable for the stdlib. Is this a big enough win to justify CPython being written in C11 instead of C90 (or, worse, sometimes one and sometimes the other, or a combination of the two), or to add a dependency on a library that isn't preinstalled on most systems and takes longer to build than all of current CPython 3.4? For a PyPI library, none of those things matter (in fact, a PyPI library could use C++ on platforms where the native types from the C++ TR exist but the C ones don't, or use Cython or CFFI or Boost::Python instead of native code, etc.), and the stdlib's decimal docs could just point to that PyPI library.
For that matter, it wouldn't violate the standards to add decimal.PythonDecimal with some other behaviors. But I can't really think of any desirable behaviors that are mathematically possible to put there.
I think it would still make sense to put it somewhere else. A module that declares that its behavior corresponds to a standard that adds a little bit of standard-irrelevant behavior is fine. For example, a conversion from Fraction to Decimal that worked "in the spirit of the standards" and documented that it wasn't specified by either standard. But adding a whole new class as complex as Decimal means half the module is now standard-irrelevant, which seems a lot more potentially confusing to me.
There isn't going to be a decimal.NeverSurprisingDecimal class in there.
Start with your favorite axioms for the integers and your favorite construction of the reals, then negate the successor axiom. Now you have a fully-consistent, never-surprising, easily-implementable real number type that follows all the usual mathematical laws over its entire set of values, {0}. :)
participants (5)
-
Andrew Barnert -
David Mertz -
Mark Lawrence -
Steven D'Aprano -
u8y7541 The Awesome Person