Permalink
Cannot retrieve contributors at this time
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| PEP: 228 | |
| Title: Reworking Python's Numeric Model | |
| Version: $Revision$ | |
| Last-Modified: $Date$ | |
| Author: moshez@zadka.site.co.il (Moshe Zadka), guido@python.org (Guido van Rossum) | |
| Status: Withdrawn | |
| Type: Standards Track | |
| Content-Type: text/x-rst | |
| Created: 04-Nov-2000 | |
| Post-History: | |
| Withdrawal | |
| ========== | |
| This PEP has been withdrawn in favor of :pep:`3141`. | |
| Abstract | |
| ======== | |
| Today, Python's numerical model is similar to the C numeric model: | |
| there are several unrelated numerical types, and when operations | |
| between numerical types are requested, coercions happen. While | |
| the C rationale for the numerical model is that it is very similar | |
| to what happens at the hardware level, that rationale does not | |
| apply to Python. So, while it is acceptable to C programmers that | |
| ``2/3 == 0``, it is surprising to many Python programmers. | |
| NOTE: in the light of recent discussions in the newsgroup, the | |
| motivation in this PEP (and details) need to be extended. | |
| Rationale | |
| ========= | |
| In usability studies, one of the least usable aspect of Python was | |
| the fact that integer division returns the floor of the division. | |
| This makes it hard to program correctly, requiring casts to | |
| ``float()`` in various parts through the code. Python's numerical | |
| model stems from C, while a model that might be easier to work with | |
| can be based on the mathematical understanding of numbers. | |
| Other Numerical Models | |
| ====================== | |
| Perl's numerical model is that there is one type of numbers -- | |
| floating point numbers. While it is consistent and superficially | |
| non-surprising, it tends to have subtle gotchas. One of these is | |
| that printing numbers is very tricky, and requires correct | |
| rounding. In Perl, there is also a mode where all numbers are | |
| integers. This mode also has its share of problems, which arise | |
| from the fact that there is not even an approximate way of | |
| dividing numbers and getting meaningful answers. | |
| Suggested Interface For Python's Numerical Model | |
| ================================================ | |
| While coercion rules will remain for add-on types and classes, the | |
| built in type system will have exactly one Python type -- a | |
| number. There are several things which can be considered "number | |
| methods": | |
| 1. ``isnatural()`` | |
| 2. ``isintegral()`` | |
| 3. ``isrational()`` | |
| 4. ``isreal()`` | |
| 5. ``iscomplex()`` | |
| 6. ``isexact()`` | |
| Obviously, a number which answers true to a question from 1 to 5, will | |
| also answer true to any following question. If ``isexact()`` is not true, | |
| then any answer might be wrong. | |
| (But not horribly wrong: it's close to the truth.) | |
| Now, there is two thing the models promises for the field operations | |
| (``+``, ``-``, ``/``, ``*``): | |
| - If both operands satisfy ``isexact()``, the result satisfies | |
| ``isexact()``. | |
| - All field rules are true, except that for not-``isexact()`` numbers, | |
| they might be only approximately true. | |
| One consequence of these two rules is that all exact calculations | |
| are done as (complex) rationals: since the field laws must hold, | |
| then :: | |
| (a/b)*b == a | |
| must hold. | |
| There is built-in function, ``inexact()`` which takes a number | |
| and returns an inexact number which is a good approximation. | |
| Inexact numbers must be as least as accurate as if they were | |
| using IEEE-754. | |
| Several of the classical Python functions will return exact numbers | |
| even when given inexact numbers: e.g, ``int()``. | |
| Coercion | |
| ======== | |
| The number type does not define ``nb_coerce`` | |
| Any numeric operation slot, when receiving something other then ``PyNumber``, | |
| refuses to implement it. | |
| Inexact Operations | |
| ================== | |
| The functions in the ``math`` module will be allowed to return | |
| inexact results for exact values. However, they will never return | |
| a non-real number. The functions in the ``cmath`` module are also | |
| allowed to return an inexact result for an exact argument, and are | |
| furthermore allowed to return a complex result for a real | |
| argument. | |
| Numerical Python Issues | |
| ======================= | |
| People who use Numerical Python do so for high-performance vector | |
| operations. Therefore, NumPy should keep its hardware based | |
| numeric model. | |
| Unresolved Issues | |
| ================= | |
| Which number literals will be exact, and which inexact? | |
| How do we deal with IEEE 754 operations? (probably, isnan/isinf should | |
| be methods) | |
| On 64-bit machines, comparisons between ints and floats may be | |
| broken when the comparison involves conversion to float. Ditto | |
| for comparisons between longs and floats. This can be dealt with | |
| by avoiding the conversion to float. (Due to Andrew Koenig.) | |
| Copyright | |
| ========= | |
| This document has been placed in the public domain. | |
| .. | |
| Local Variables: | |
| mode: indented-text | |
| indent-tabs-mode: nil | |
| End: |