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