Are you aware that Python's int type is already effectively arbitrary precision?
>>> 23**100
14886191506363039393791556586559754231987119653801368686576988209222433278539331352152390143277346804233476592179447310859520222529876001
>>> type(23**100)
<class 'int'>
For the suggestion of "quad": this has come up a couple of times in the past, but there are many things that would need to be discussed:
- Is it actually useful or necessary?
- Is it useful enough to warrant being included in the standard library, rather than provided by 3rd party libraries (gmpy, mpmath, ...).
- Would it be better to provide an arbitrary-precision binary floating-point type? What would this provide that the existing arbitrary-precision decimal floating-point type (in the decimal module) doesn't already provide.
- What would the impact be on the rest of the core code and the standard library: how many modules would need to be adapted to work with the new floating-point type, and how much work would that be?
- What would the format be? You suggest matching "long double" in C, but that may not be the best plan: long double isn't consistent across even mainstream platforms. On Windows it's just the same as "double"; on OS X and most (all?) flavours of Linux it's the ancient x87 80-bit format. On some PPC machines it's a double-double format. IMO, the only sane format for something called "quad" would be the IEEE 754 standard binary128 format, but there's almost no hardware support for that format (excluding IBM zSeries). So we'd have to maintain (or borrow) a software implementation, which would be a *lot* of work. (I don't know of good free non-GPL implementations already in existence.)
I'm personally a strong -1 on adding a quad type to the Python core language: I don't think the extra complication is worth it. But if you want to take this further, I'd suggest taking it to the python-ideas mailing list: https://mail.python.org/mailman/listinfo/python-ideas.
I'm going to close the issue here: adding quad is too big a proposed change for a tracker issue; I'm sure lots of people would weigh in on a python-ideas discussion.
|