types. Added a new API function, PyUnicode_TransformDecimalToASCII(),
which transforms non-ASCII decimal digits in a Unicode string to their
ASCII equivalents.
(instances of int, float, complex, decimal.Decimal and
fractions.Fraction) that makes it easy to maintain the invariant that
hash(x) == hash(y) whenever x and y have equal value.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r79843 | mark.dickinson | 2010-04-06 17:46:09 +0100 (Tue, 06 Apr 2010) | 4 lines
Issue #8259: Get rid of 'outrageous left shift count' error when
left-shifting an integer by more than 2**31 on a 64-bit machine. Also
convert shift counts to a Py_ssize_t instead of a C long.
........
r79844 | mark.dickinson | 2010-04-06 17:47:55 +0100 (Tue, 06 Apr 2010) | 1 line
Misc/NEWS entry for r79843.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77842 | mark.dickinson | 2010-01-30 10:08:33 +0000 (Sat, 30 Jan 2010) | 4 lines
Issue #7767: Add new C-API function PyLong_AsLongLongAndOverflow, a
long long variant of PyLong_AsLongAndOverflow. Patch by Case Van
Horsen.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77234 | mark.dickinson | 2010-01-02 14:45:40 +0000 (Sat, 02 Jan 2010) | 7 lines
Refactor some longobject internals: PyLong_AsDouble and _PyLong_AsScaledDouble
(the latter renamed to _PyLong_Frexp) now use the same core code. The
exponent produced by _PyLong_Frexp now has type Py_ssize_t instead of the
previously used int, and no longer needs scaling by PyLong_SHIFT. This
frees the math module from having to know anything about the PyLong
implementation. This closes issue #5576.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r75110 | mark.dickinson | 2009-09-28 17:52:40 +0100 (Mon, 28 Sep 2009) | 9 lines
Style/consistency/nano-optimization nit: replace occurrences of
(high_bits << PyLong_SHIFT) + low_bits with
(high_bits << PyLong_SHIFT) | low_bits
in Objects/longobject.c. Motivation:
- shouldn't unnecessarily mix bit ops with arithmetic ops (style)
- this pattern should be spelt the same way thoughout (consistency)
- it's very very very slightly faster: no need to worry about
carries to the high digit (nano-optimization).
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r72202 | mark.dickinson | 2009-05-02 18:55:01 +0100 (Sat, 02 May 2009) | 3 lines
Remove unnecessary use of context for long getters.
(Related to issue #5880).
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r71772 | mark.dickinson | 2009-04-20 22:13:33 +0100 (Mon, 20 Apr 2009) | 5 lines
Issue #3166: Make long -> float (and int -> float) conversions
correctly rounded, using round-half-to-even. This ensures that the
value of float(n) doesn't depend on whether we're using 15-bit digits
or 30-bit digits for Python longs.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r70542 | mark.dickinson | 2009-03-23 18:25:13 +0000 (Mon, 23 Mar 2009) | 14 lines
Issue #5512: speed up the long division algorithm for Python longs.
The basic algorithm remains the same; the most significant speedups
come from the following three changes:
(1) normalize by shifting instead of multiplying and dividing
(2) the old algorithm usually did an unnecessary extra iteration of
the outer loop; remove this. As a special case, this means that
long divisions with a single-digit result run twice as fast as
before.
(3) make inner loop much tighter.
Various benchmarks show speedups of between 50% and 150% for long
integer divisions and modulo operations.
........
- new configure option --enable-big-digits
- new structseq sys.int_info giving information about the internal format
By default, 30-bit digits are enabled on 64-bit machines but
disabled on 32-bit machines.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r69634 | mark.dickinson | 2009-02-15 10:13:41 +0000 (Sun, 15 Feb 2009) | 6 lines
Issue #5260: Various portability and standards compliance fixes, optimizations
and cleanups in Objects/longobject.c. The most significant change is that
longs now use less memory: average savings are 2 bytes per long on 32-bit
systems and 6 bytes per long on 64-bit systems. (This memory saving already
exists in py3k.)
........