Commit graph

247 commits

Author SHA1 Message Date
Mark Dickinson
a36507c64c Issue #7767: Add new C-API function PyLong_AsLongLongAndOverflow, a
long long variant of PyLong_AsLongAndOverflow.  Patch by Case Van
Horsen.
2010-01-30 10:08:33 +00:00
Mark Dickinson
d3e323215c 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.
2010-01-02 14:45:40 +00:00
Mark Dickinson
4657283647 Issue #1811: Improve accuracy and consistency of true division for integers. 2009-12-27 14:55:57 +00:00
Mark Dickinson
e31d300664 Issue #7528: Backport PyLong_AsLongAndOverflow from py3k to trunk.
Thanks Case Van Horsen for the patch.
2009-12-21 11:21:25 +00:00
Mark Dickinson
8d87dc0c29 Issue #1087418: Small performance boost for bitwise operations on longs.
Initial patch by Gregory Smith;  some tweaks added.
2009-10-25 20:39:06 +00:00
Mark Dickinson
71adc9328d 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).
2009-09-28 16:52:40 +00:00
Mark Dickinson
40ee861c0a Silence MSVC compiler warnings. 2009-09-21 16:16:44 +00:00
Mark Dickinson
aa2adc828a Issue #6713: Improve performance of str(n) and repr(n) for integers n
(up to 3.1 times faster in tests), by special-casing base 10 in
_PyLong_Format.  (Backport of r74851 from py3k.)
2009-09-16 22:10:56 +00:00
Mark Dickinson
1f4fc097f6 Fix potential signed-overflow bug in _PyLong_Format; also fix
a couple of whitespace issues.
2009-09-13 11:56:13 +00:00
Mark Dickinson
752a2daf32 Remove redundant assignment 2009-09-06 20:51:37 +00:00
Mark Dickinson
d4b5c98fa6 Remove unnecessary use of context for long getters.
(Related to issue #5880).
2009-05-02 17:55:01 +00:00
Mark Dickinson
6736cf8d20 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.
2009-04-20 21:13:33 +00:00
Mark Dickinson
48e3fd240f sys.long_info attributes should be ints, not longs 2009-04-02 18:39:37 +00:00
Mark Dickinson
0b666bfdf9 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.
2009-03-23 18:25:13 +00:00
Mark Dickinson
efc82f7e8e Issue #4258: Use 30-bit digits for Python longs, on 64-bit platforms.
Backport of r70459.
2009-03-20 15:51:55 +00:00
Mark Dickinson
b646487687 Replace long with twodigits, to avoid depending
on sizeof(digit) < sizeof(long)
2009-02-25 20:29:50 +00:00
Mark Dickinson
bcf6b18eb7 A few more minor fixes in longobject.c 2009-02-15 15:48:39 +00:00
Mark Dickinson
2ffb26fb83 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.)
2009-02-15 10:13:41 +00:00
Mark Dickinson
4015f62e39 Issue #5175: PyLong_AsUnsignedLongLong now raises OverflowError for
negative arguments.  Previously, it raised TypeError.

Thanks Lisandro Dalcin.
2009-02-10 15:46:50 +00:00
Mark Dickinson
a0eae0398c Fix comment. 2009-01-26 21:40:08 +00:00
Mark Dickinson
6ffa4a2a7d Fix undefined behaviour (left shift of negative value) in long_hash. Also,
rewrap a line of length > 79, and update comments.
2009-01-26 21:36:30 +00:00
Mark Dickinson
1afe6ddd07 No need for carry to be type twodigits in _PyLong_AsByteArray; digit is large enough.
This change should silence a compiler warning on Windows.
2009-01-25 22:12:31 +00:00
Mark Dickinson
ff84aa87b4 Issue #4393: fix 3 classes of potential portability problems in longobject.c:
- fix some places where counters into ob_digit were declared as
   int instead of Py_ssize_t
 - add (twodigit) casts where necessary
 - fix code in _PyLong_AsByteArray that uses << on negative values
2009-01-24 15:27:44 +00:00
Mark Dickinson
1a707981c8 Issue #3439: add bit_length method to int and long.
Thanks Fredrik Johansson and Victor Stinner for code,
Raymond Hettinger for review.
2008-12-17 16:14:37 +00:00
Mark Dickinson
b646757e01 Issue #1481296: (again!) Make conversion of a float NaN to an int or
long raise ValueError instead of returning 0.  Also, change the error
message for conversion of an infinity to an integer, replacing 'long' by
'integer', so that it's appropriate for both long(float('inf')) and
int(float('inf')).
2008-08-04 21:30:09 +00:00
Neal Norwitz
e7d8be80ba Security patches from Apple: prevent int overflow when allocating memory 2008-07-31 17:17:14 +00:00
Robert Schuppenies
9be2ec109b Added additional __sizeof__ implementations and addressed comments made in
Issue3122.
2008-07-10 15:24:04 +00:00
Raymond Hettinger
9c437af4eb Revert 64424, 64438, and 64439. 2008-06-24 22:46:07 +00:00
Raymond Hettinger
e3ae655edf Make bin() implementation parallel oct() and hex() so that int/long subclasses can override or so that other classes can support. 2008-06-20 04:18:15 +00:00
Gregory P. Smith
dd96db63f6 This reverts r63675 based on the discussion in this thread:
http://mail.python.org/pipermail/python-dev/2008-June/079988.html

Python 2.6 should stick with PyString_* in its codebase.  The PyBytes_* names
in the spirit of 3.0 are available via a #define only.  See the email thread.
2008-06-09 04:58:54 +00:00
Georg Brandl
7a6de8b0f4 Some style nits. Also clarify in the docstrings what __sizeof__ does. 2008-06-01 16:42:16 +00:00
Robert Schuppenies
51df064767 Issue #2898: Added sys.getsizeof() to retrieve size of objects in bytes. 2008-06-01 16:16:17 +00:00
Eric Smith
dc13b79a38 Refactor and clean up str.format() code (and helpers) in advance of optimizations. 2008-05-30 18:10:04 +00:00
Christian Heimes
593daf545b Renamed PyString to PyBytes 2008-05-26 12:51:38 +00:00
Christian Heimes
6f34109384 I finally got the time to update and merge Mark's and my trunk-math branch. The patch is collaborated work of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and edge cases related to operations with NaN, INF, very small values and complex math.
The patch also adds acosh, asinh, atanh, log1p and copysign to all platforms. Finally it fixes differences between platforms like different results or exceptions for edge cases. Have fun :)
2008-04-18 23:13:07 +00:00
Mark Dickinson
27a632510e Fix for possible signed overflow: the behaviour of -LONG_MIN is
undefined in ANSI C.
2008-04-15 20:51:18 +00:00
Neal Norwitz
d183bdd6fb Revert r61969 which added casts to Py_CHARMASK to avoid compiler warnings.
Rather than sprinkle casts throughout the code, change Py_CHARMASK to
always cast it's result to an unsigned char.  This should ensure we
do the right thing when accessing an array with the result.
2008-03-28 04:58:51 +00:00
Neal Norwitz
231346e23f Fix warnings about using char as an array subscript. This is not portable
since char is signed on some platforms and unsigned on others.
2008-03-27 04:40:50 +00:00
Jeffrey Yasskin
5de250e823 Fix build on platforms that don't have intptr_t. Patch by Joseph Armbruster. 2008-03-18 01:09:59 +00:00
Eric Smith
9ff19b5434 Finished backporting PEP 3127, Integer Literal Support and Syntax.
Added 0b and 0o literals to tokenizer.
Modified PyOS_strtoul to support 0b and 0o inputs.
Modified PyLong_FromString to support guessing 0b and 0o inputs.
Renamed test_hexoct.py to test_int_literal.py and added binary tests.
Added upper and lower case 0b, 0O, and 0X tests to test_int_literal.py
2008-03-17 17:32:20 +00:00
Eric Smith
a9f7d62480 Backport of PEP 3101, Advanced String Formatting, from py3k.
Highlights:
 - Adding PyObject_Format.
 - Adding string.Format class.
 - Adding __format__ for str, unicode, int, long, float, datetime.
 - Adding builtin format.
 - Adding ''.format and u''.format.
 - str/unicode fixups for formatters.

The files in Objects/stringlib that implement PEP 3101 (stringdefs.h,
unicodedefs.h, formatter.h, string_format.h) are identical in trunk
and py3k.  Any changes from here on should be made to trunk, and
changes will propogate to py3k).
2008-02-17 19:46:49 +00:00
Eric Smith
5e527ebee1 Added PyNumber_ToBase and supporting routines _PyInt_Format and
_PyLong_Format.  In longobject.c, changed long_format to
_PyLong_Format.  In intobject.c, changed uses of PyOS_snprintf to
_PyInt_Format instead.

_PyLong_Format is similar to py3k's routine of the same name, except
it has 2 additional parameters: addL and newstyle.  addL was existing
in long_format, and controls adding the trailing "L".  This is
unneeded in py3k.  newstyle is used to control whether octal prepends
"0" (the pre-2.6 style), or "0o" (the 3.0 sytle).

PyNumber_ToBase is needed for PEP 3127 (Integer Literal Support and
Syntax) and PEP 3101 (Advanced String Formatting).

This changeset does not need merging into py3k.
2008-02-10 01:36:53 +00:00
Christian Heimes
7f39c9fcbb Backport of several functions from Python 3.0 to 2.6 including PyUnicode_FromString, PyUnicode_Format and PyLong_From/AsSsize_t. The functions are partly required for the backport of the bytearray type and _fileio module. They should also make it easier to port C to 3.0.
First chapter of the Python 3.0 io framework back port: _fileio
The next step depends on a working bytearray type which itself depends on a backport of the nwe buffer API.
2008-01-25 12:18:43 +00:00
Christian Heimes
4956d2b889 Silence Coverity false alerts with CIDs #172, #183, #184 2008-01-18 19:12:56 +00:00
Jeffrey Yasskin
9871d8fe22 Continue rolling back pep-3141 changes that changed behavior from 2.5. This
round included:
 * Revert round to its 2.6 behavior (half away from 0).
 * Because round, floor, and ceil always return float again, it's no
   longer necessary to have them delegate to __xxx___, so I've ripped
   that out of their implementations and the Real ABC. This also helps
   in implementing types that work in both 2.6 and 3.0: you return int
   from the __xxx__ methods, and let it get enabled by the version
   upgrade.
 * Make pow(-1, .5) raise a ValueError again.
2008-01-05 08:47:13 +00:00
Jeffrey Yasskin
737c73f96f Make math.{floor,ceil}({int,long}) return float again for backwards
compatibility after r59671 made them return integral types.
2008-01-04 08:01:23 +00:00
Christian Heimes
8267d1dfe5 Bug #1481296: Fixed long(float('nan'))!=0L. 2008-01-04 00:37:34 +00:00
Jeffrey Yasskin
2f3c16be73 Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (just
the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361,
r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new
documentation. The only significant difference is that round(x) returns a float
to preserve backward-compatibility. See http://bugs.python.org/issue1689.
2008-01-03 02:21:52 +00:00
Christian Heimes
e93237dfcc #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and Py_REFCNT. Macros for b/w compatibility are available. 2007-12-19 02:37:44 +00:00
Facundo Batista
d544df7ddd Issue #1772851. Alters long.__hash__ from being *almost* completely
predictable to being completely predictable.  The value of hash(n)
is unchanged for any n that's small enough to be representable as an
int, and also unchanged for the vast majority of long integers n of
reasonable size.
2007-09-19 15:10:06 +00:00