Commit Graph

256 Commits

Author SHA1 Message Date
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
Martin v. Löwis 6819210b9e PEP 3123: Provide forward compatibility with Python 3.0, while keeping
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
2007-07-21 06:55:02 +00:00
Kristján Valur Jónsson f030394de3 Fix problems in x64 build that were discovered by the testsuite:
- Reenable modules on x64 that had been disabled aeons ago for Itanium.
- Cleared up confusion about compilers for 64 bit windows.  There is only Itanium and x64.  Added macros MS_WINI64 and MS_WINX64 for those rare cases where it matters, such as the disabling of modules above.
- Set target platform (_WIN32_WINNT and WINVER) to 0x0501 (XP) for x64, and 0x0400 (NT 4.0) otherwise, which are the targeted minimum platforms.
- Fixed thread_nt.h.  The emulated InterlockedCompareExchange function didn´t work on x64, probaby due to the lack of a "volatile" specifier.  Anyway, win95 is no longer a target platform.
- Itertools module used wrong constant to check for overflow in count()
- PyInt_AsSsize_t couldn't deal with attribute error when accessing the __long__ member.
- PyLong_FromSsize_t() incorrectly specified that the operand were unsigned.

With these changes, the x64 passes the testsuite, for those modules present.
2007-05-03 20:27:03 +00:00
Georg Brandl c02e13122b Add some missing NULL checks which trigger crashes on low-memory conditions.
Found by Victor Stinner. Will backport when 2.5 branch is unfrozen.
2007-04-11 17:16:24 +00:00
Georg Brandl 00cd818dea Patch #1638879: don't accept strings with embedded NUL bytes in long(). 2007-03-06 18:41:12 +00:00
Neal Norwitz ee3a1b5244 Variation of patch # 1624059 to speed up checking if an object is a subclass
of some of the common builtin types.

Use a bit in tp_flags for each common builtin type.  Check the bit
to determine if any instance is a subclass of these common types.
The check avoids a function call and O(n) search of the base classes.
The check is done in the various Py*_Check macros rather than calling
PyType_IsSubtype().

All the bits are set in tp_flags when the type is declared
in the Objects/*object.c files because PyType_Ready() is not called
for all the types.  Should PyType_Ready() be called for all types?
If so and the change is made, the changes to the Objects/*object.c files
can be reverted (remove setting the tp_flags).  Objects/typeobject.c
would also have to be modified to add conditions
for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
2007-02-25 19:44:48 +00:00
Armin Rigo 7ccbca93a2 Forward-port of r52136,52138: a review of overflow-detecting code.
* unified the way intobject, longobject and mystrtoul handle
  values around -sys.maxint-1.

* in general, trying to entierely avoid overflows in any computation
  involving signed ints or longs is extremely involved.  Fixed a few
  simple cases where a compiler might be too clever (but that's all
  guesswork).

* more overflow checks against bad data in marshal.c.

* 2.5 specific: fixed a number of places that were still confusing int
  and Py_ssize_t.  Some of them could potentially have caused
  "real-world" breakage.

* list.pop(x): fixing overflow issues on x was messy.  I just reverted
  to PyArg_ParseTuple("n"), which does the right thing.  (An obscure
  test was trying to give a Decimal to list.pop()... doesn't make
  sense any more IMHO)

* trying to write a few tests...
2006-10-04 12:17:45 +00:00
Neal Norwitz 8a87f5d37e Patch #1538606, Patch to fix __index__() clipping.
I modified this patch some by fixing style, some error checking, and adding
XXX comments.  This patch requires review and some changes are to be expected.
I'm checking in now to get the greatest possible review and establish a
baseline for moving forward.  I don't want this to hold up release if possible.
2006-08-12 17:03:09 +00:00
Neal Norwitz c09efa8444 Move the initialization of size_a down below the check for a being NULL.
Reported by Klocwork #106
2006-07-23 07:53:14 +00:00
Neal Norwitz ef02b9e144 a & b were dereffed above, so they are known to be valid pointers.
z is known to be NULL, nothing to DECREF.

Reported by Klockwork, #107.
2006-07-16 02:00:32 +00:00
Tim Peters 9faa3eda6b PyLong_FromString(): Continued fraction analysis (explained in
a new comment) suggests there are almost certainly large input
integers in all non-binary input bases for which one Python digit
too few is initally allocated to hold the final result.  Instead
of assert-failing when that happens, allocate more space.  Alas,
I estimate it would take a few days to find a specific such case,
so this isn't backed up by a new test (not to mention that such
a case may take hours to run, since conversion time is quadratic
in the number of digits, and preliminary attempts suggested that
the smallest such inputs contain at least a million digits).
2006-05-30 15:53:34 +00:00
Tim Peters d89fc22dc6 Patch #1494387: SVN longobject.c compiler warnings
The SIGCHECK macro defined here has always been bizarre, but
it apparently causes compiler warnings on "Sun Studio 11".
I believe the warnings are bogus, but it doesn't hurt to make
the macro definition saner.

Bugfix candidate (but I'm not going to bother).
2006-05-25 22:28:46 +00:00
Bob Ippolito a85bf202ac Faster path for PyLong_FromLongLong, using PyLong_FromLong algorithm 2006-05-25 18:20:23 +00:00
Tim Peters da53afa1b0 A new table to help string->integer conversion was added yesterday to
both mystrtoul.c and longobject.c.  Share the table instead.  Also
cut its size by 64 entries (they had been used for an inscrutable
trick originally, but the code no longer tries to use that trick).
2006-05-25 17:34:03 +00:00
Tim Peters 696cf43b58 Heavily fiddled variant of patch #1442927: PyLong_FromString optimization.
``long(str, base)`` is now up to 6x faster for non-power-of-2 bases.  The
largest speedup is for inputs with about 1000 decimal digits.  Conversion
from non-power-of-2 bases remains quadratic-time in the number of input
digits (it was and remains linear-time for bases 2, 4, 8, 16 and 32).

Speedups at various lengths for decimal inputs, comparing 2.4.3 with
current trunk.  Note that it's actually a bit slower for 1-digit strings:

  len  speedup
 ----  -------
   1     -4.5%
   2      4.6%
   3      8.3%
   4     12.7%
   5     16.9%
   6     28.6%
   7     35.5%
   8     44.3%
   9     46.6%
  10     55.3%
  11     65.7%
  12     77.7%
  13     73.4%
  14     75.3%
  15     85.2%
  16    103.0%
  17     95.1%
  18    112.8%
  19    117.9%
  20    128.3%
  30    174.5%
  40    209.3%
  50    236.3%
  60    254.3%
  70    262.9%
  80    295.8%
  90    297.3%
 100    324.5%
 200    374.6%
 300    403.1%
 400    391.1%
 500    388.7%
 600    440.6%
 700    468.7%
 800    498.0%
 900    507.2%
1000    501.2%
2000    450.2%
3000    463.2%
4000    452.5%
5000    440.6%
6000    439.6%
7000    424.8%
8000    418.1%
9000    417.7%
2006-05-24 21:10:40 +00:00
Neal Norwitz c6a989ac3a Fix problems found by Coverity.
longobject.c: also fix an ssize_t problem
  <a> could have been NULL, so hoist the size calc to not use <a>.

_ssl.c: under fail: self is DECREF'd, but it would have been NULL.

_elementtree.c: delete self if there was an error.

_csv.c: I'm not sure if lineterminator could have been anything other than
a string.  However, other string method calls are checked, so check this
one too.
2006-05-10 06:57:58 +00:00
Skip Montanaro 429433b30b C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in a couple places 2006-04-18 00:35:43 +00:00
Thomas Wouters 9cb28bea04 Fix int() and long() to repr() their argument when formatting the exception,
to avoid confusing situations like:

>>> int("")
ValueError: invalid literal for int():
>>> int("2\n\n2")
ValueError: invalid literal for int(): 2

2

Also report the base used, to avoid:

ValueError: invalid literal for int(): 2

They now report:

>>> int("")
ValueError: invalid literal for int() with base 10: ''
>>> int("2\n\n2")
ValueError: invalid literal for int() with base 10: '2\n\n2'
>>> int("2", 2)
ValueError: invalid literal for int() with base 2: '2'

(Reporting the base could be avoided when base is 10, which is the default,
but hrm.) Another effect of these changes is that the errormessage can be
longer; before, it was cut off at about 250 characters. Now, it can be up to
four times as long, as the unrepr'ed string is cut off at 200 characters,
instead.

No tests were added or changed, since testing for exact errormsgs is (pardon
the pun) somewhat errorprone, and I consider not testing the exact text
preferable. The actually changed code is tested frequent enough in the
test_builtin test as it is (120 runs for each of ints and longs.)
2006-04-11 23:50:33 +00:00
Anthony Baxter 377be11ee1 More C++-compliance. Note especially listobject.c - to get C++ to accept the
PyTypeObject structures, I had to make prototypes for the functions, and
move the structure definition ahead of the functions. I'd dearly like a better
way to do this - to change this would make for a massive set of changes to
the codebase.

There's still some warnings - this is purely to get rid of errors first.
2006-04-11 06:54:30 +00:00
Martin v. Löwis 0bc2ab9a20 Patch #837242: id() for large ptr should return a long. 2006-04-10 20:28:17 +00:00
Martin v. Löwis c48c8db110 Add PY_SSIZE_T_MIN, as suggested by Ralf W. Grosse-Kunstleve. 2006-04-05 18:21:17 +00:00
Georg Brandl 347b30042b Remove unnecessary casts in type object initializers. 2006-03-30 11:57:00 +00:00
Armin Rigo 12bec1b985 fix a comment. 2006-03-28 19:27:56 +00:00
Guido van Rossum 38fff8c4e4 Checking in the code for PEP 357.
This was mostly written by Travis Oliphant.
I've inspected it all; Neal Norwitz and MvL have also looked at it
(in an earlier incarnation).
2006-03-07 18:50:55 +00:00
Hye-Shik Chang 4af5c8cee4 SF #1444030: Fix several potential defects found by Coverity.
(reviewed by Neal Norwitz)
2006-03-07 15:39:21 +00:00
Martin v. Löwis 15e62742fa Revert backwards-incompatible const changes. 2006-02-27 16:46:16 +00:00
Martin v. Löwis 18e165558b Merge ssize_t branch. 2006-02-15 17:27:45 +00:00
Thomas Wouters 553489ab1d As discussed on python-dev, silence three gcc-4.0.x warnings, using assert()
to protect against actual uninitialized usage.

Objects/longobject.c: In function ‘PyLong_AsDouble’:
Objects/longobject.c:655: warning: ‘e’ may be used uninitialized in this function

Objects/longobject.c: In function ‘long_true_divide’:
Objects/longobject.c:2263: warning: ‘aexp’ may be used uninitialized in this function
Objects/longobject.c:2263: warning: ‘bexp’ may be used uninitialized in this function
2006-02-01 21:32:04 +00:00
Jeremy Hylton af68c874a6 Add const to several API functions that take char *.
In C++, it's an error to pass a string literal to a char* function
without a const_cast().  Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.

I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc.  Predictably, there were a large set of functions that
needed to be fixed as a result of these changes.  The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].

One cast was required as a result of the changes:  A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
2005-12-10 18:50:16 +00:00
Tim Peters de7990b8af SF bug #1238681: freed pointer is used in longobject.c:long_pow().
In addition, long_pow() skipped a necessary (albeit extremely unlikely
to trigger) error check when converting an int modulus to long.

Alas, I was unable to write a test case that crashed due to either
cause.

Bugfix candidate.
2005-07-17 23:45:23 +00:00
Raymond Hettinger 3296e696db SF bug #1224347: int/long unification and hex()
Hex longs now print with lowercase letters like their int counterparts.
2005-06-29 23:29:56 +00:00
Brett Cannon c3647ac93e Make subclasses of int, long, complex, float, and unicode perform type
conversion using the proper magic slot (e.g., __int__()).  Also move conversion
code out of PyNumber_*() functions in the C API into the nb_* function.

Applied patch #1109424.  Thanks Walter Doewald.
2005-04-26 03:45:26 +00:00
Martin v. Löwis 6ce7ed23d0 Revert previous checkin on getargs 'L' code. Try to convert all
numbers in PyLong_AsLongLong, and update test suite accordingly.
Backported to 2.4.
2005-03-03 12:26:35 +00:00
Martin v. Löwis 729d47db09 Patch #1024670: Support int objects in PyLong_AsUnsignedLong[Mask]. 2004-09-20 06:17:46 +00:00
Tim Peters cd97da3b1d long_pow(): Fix more instances of leaks in error cases.
Bugfix candidate -- although long_pow() is so different now I doubt a
patch would apply to 2.3.
2004-08-30 02:58:59 +00:00
Tim Peters 47e52ee0c5 SF patch 936813: fast modular exponentiation
This checkin is adapted from part 2 (of 3) of Trevor Perrin's patch set.

BACKWARD INCOMPATIBILITY:  SHIFT must now be divisible by 5.  AFAIK,
nobody will care.  long_pow() could be complicated to worm around that,
if necessary.

long_pow():
  - BUGFIX:  This leaked the base and power when the power was negative
    (and so the computation delegated to float pow).
  - Instead of doing right-to-left exponentiation, do left-to-right.  This
    is more efficient for small bases, which is the common case.
  - In addition, if the exponent is large (more than FIVEARY_CUTOFF
    digits), precompute [a**i % c for i in range(32)], and go left to
    right 5 bits at a time.
l_divmod():
  - The signature changed so that callers who don't want the quotient,
    or don't want the remainder, can pass NULL in the slot they don't
    want.  This saves them from having to declare a vrbl for unwanted
    stuff, and remembering to decref it.
long_mod(), long_div(), long_classic_div():
  - Adjust to new l_divmod() signature, and simplified as a result.
2004-08-30 02:44:38 +00:00
Tim Peters 0973b99e1c SF patch 936813: fast modular exponentiation
This checkin is adapted from part 1 (of 3) of Trevor Perrin's patch set.

x_mul()
  - sped a little by optimizing the C
  - sped a lot (~2X) if it's doing a square; note that long_pow() squares
    often
k_mul()
  - more cache-friendly now if it's doing a square
KARATSUBA_CUTOFF
  - boosted; gradeschool mult is quicker now, and it may have been too low
    for many platforms anyway
KARATSUBA_SQUARE_CUTOFF
  - new
  - since x_mul is a lot faster at squaring now, the point at which
    Karatsuba pays for squaring is much higher than for general mult
2004-08-29 22:16:50 +00:00
Raymond Hettinger f466793fcc SF patch 703666: Several objects don't decref tmp on failure in subtype_new
Submitted By: Christopher A. Craig

Fillin some missing decrefs.
2003-06-28 20:04:25 +00:00
Tim Peters c7bc0b98e7 SF patch 730594: assert from longobject.c, line 1215.
Some version of gcc in the "RTEMS port running on the Coldfire (m5200)
processor" generates bad code for a loop in long_from_binary_base(),
comparing the wrong half of an int to a short.  The patch changes the
decl of the short temp to be an int temp instead.  This "simplifies"
the code enough that gcc no longer blows it.
2003-05-05 20:39:43 +00:00
Jeremy Hylton fc61f9a36e Silence compiler warnings in VC 7. 2003-05-01 21:31:53 +00:00
Thomas Heller a4ea603b05 SF # 595026: support for masks in getargs.c.
New functions:
  unsigned long PyInt_AsUnsignedLongMask(PyObject *);
  unsigned PY_LONG_LONG) PyInt_AsUnsignedLongLongMask(PyObject *);
  unsigned long PyLong_AsUnsignedLongMask(PyObject *);
  unsigned PY_LONG_LONG) PyLong_AsUnsignedLongLongMask(PyObject *);

New and changed format codes:

b unsigned char 0..UCHAR_MAX
B unsigned char none **
h unsigned short 0..USHRT_MAX
H unsigned short none **
i int INT_MIN..INT_MAX
I * unsigned int 0..UINT_MAX
l long LONG_MIN..LONG_MAX
k * unsigned long none
L long long LLONG_MIN..LLONG_MAX
K * unsigned long long none

Notes:

* New format codes.

** Changed from previous "range-and-a-half" to "none"; the
range-and-a-half checking wasn't particularly useful.

New test test_getargs2.py, to verify all this.
2003-04-17 18:55:45 +00:00
Martin v. Löwis b9a0f91218 Rename LONG_LONG to PY_LONG_LONG. Fixes #710285. 2003-03-29 10:06:18 +00:00
Neal Norwitz d5a65a77cf Fix SF bug #689659, 64-bit int and long hash keys incompatible
On a 64-bit machine, a dictionary could contain duplicate int/long keys
if the value was > 2**32.
2003-02-23 23:11:41 +00:00
Guido van Rossum 004a65c9b1 _PyLong_Sign(): remove an assert that needed a variable ndigits that
wasn't used outside the assert (and hence caused a compiler warning
about an unused variable in NDEBUG mode).  The assert wasn't very
useful any more.

_PyLong_NumBits(): moved the calculation of ndigits after asserting
that v != NULL.
2003-02-03 15:28:19 +00:00
Tim Peters 1a3b19a6e9 long_from_binary_base(): Sped this a little by computing the # of bits
needed outside the first loop.
2003-02-02 17:33:53 +00:00
Tim Peters efb9625b81 Tightened a too-generous assert. 2003-02-02 08:05:32 +00:00
Tim Peters bf2674be0e long(string, base) now takes time linear in len(string) when base is a
power of 2.  Enabled the tail end of test_long() in pickletester.py
because it no longer takes forever when run from test_pickle.py.
2003-02-02 07:51:32 +00:00
Tim Peters ee1a53cbb1 cPickle.c: Full support for the new LONG1 and LONG4. Added comments.
Assorted code cleanups; e.g., sizeof(char) is 1 by definition, so there's
no need to do things like multiply by sizeof(char) in hairy malloc
arguments.  Fixed an undetected-overflow bug in readline_file().

longobject.c:  Fixed a really stupid bug in the new _PyLong_NumBits.

pickle.py:  Fixed stupid bug in save_long():  When proto is 2, it
wrote LONG1 or LONG4, but forgot to return then -- it went on to
append the proto 1 LONG opcode too.
Fixed equally stupid cancelling bugs in load_long1() and
load_long4():  they *returned* the unpickled long instead of pushing
it on the stack.  The return values were ignored.  Tests passed
before only because save_long() pickled the long twice.

Fixed bugs in encode_long().

Noted that decode_long() is quadratic-time despite our hopes,
because long(string, 16) is still quadratic-time in len(string).
It's hex() that's linear-time.  I don't know a way to make decode_long()
linear-time in Python, short of maybe transforming the 256's-complement
bytes into marshal's funky internal format, and letting marshal decode
that.  It would be more valuable to make long(string, 16) linear time.

pickletester.py:  Added a global "protocols" vector so tests can try
all the protocols in a sane way.  Changed test_ints() and test_unicode()
to do so.  Added a new test_long(), but the tail end of it is disabled
because it "takes forever" under pickle.py (but runs very quickly under
cPickle:  cPickle proto 2 for longs is linear-time).
2003-02-02 02:57:53 +00:00
Tim Peters 08a1d9cafc Squash compiler wng about signed/unsigned comparison mismatch. 2003-01-31 21:45:13 +00:00
Tim Peters 5b8132ffa3 _PyLong_NumBits(): The definition of this was too specific to the quirky
needs of pickling longs.  Backed off to a definition that's much easier
to understand.  The pickler will have to work a little harder, but other
uses are more likely to be correct <0.5 wink>.

_PyLong_Sign():  New teensy function to characterize a long, as to <0, ==0,
or >0.
2003-01-31 15:52:05 +00:00
Guido van Rossum 5d9113d8be Implement appropriate __getnewargs__ for all immutable subclassable builtin
types.  The special handling for these can now be removed from save_newobj().
Add some testing for this.

Also add support for setting the 'fast' flag on the Python Pickler class,
which suppresses use of the memo.
2003-01-29 17:58:45 +00:00
Tim Peters baefd9e552 Added new private API function _PyLong_NumBits. This will be used at the
start for the C implemention of new pickle LONG1 and LONG4 opcodes (the
linear-time way to pickle a long is to call _PyLong_AsByteArray, but
the caller has no idea how big an array to allocate, and correct
calculation is a bit subtle).
2003-01-28 20:37:45 +00:00
Neil Schemenauer 0df295889c Consolidate the int and long sequence repeat code. Before the change,
integers checked for integer overflow but longs did not.
2002-12-30 20:19:02 +00:00
Walter Dörwald f171540ab8 Change int() so that passing a string, unicode, float or long argument
that is outside the integer range no longer raises OverflowError, but
returns a long object instead.

This fixes SF bug http://www.python.org/sf/635115
2002-11-19 20:49:15 +00:00
Walter Dörwald 07e147667c Make int("...") return a long if an int would overflow.
Also remove the 512 character limitation for int(u"...") and long(u"...").

This closes SF bug #629989.
2002-11-06 16:15:14 +00:00
Skip Montanaro d581d7792b replace thread state objects' ticker and checkinterval fields with two
globals, _Py_Ticker and _Py_CheckInterval.  This also implements Jeremy's
shortcut in Py_AddPendingCall that zeroes out _Py_Ticker.  This allows the
test in the main loop to only test a single value.

The gory details are at

    http://python.org/sf/602191
2002-09-03 20:10:45 +00:00
Tim Peters 0d2d87d202 long_format(), long_lshift(): Someone on c.l.py is trying to boost
SHIFT and MASK, and widen digit.  One problem is that code of the form

    digit << small_integer

implicitly assumes that the result fits in an int or unsigned int
(platform-dependent, but "int sized" in any case), since digit is
promoted "just" to int or unsigned via the usual integer promotions.
But if digit is typedef'ed as unsigned int, this loses information.
The cure for this is just to cast digit to twodigits first.
2002-08-20 19:00:22 +00:00
Tim Peters e417de0e56 Illustrating by example one good reason not to trust a proof <wink>. 2002-08-15 20:10:45 +00:00
Tim Peters ab86c2be24 k_mul() comments: In honor of Dijkstra, made the proof that "t3 fits"
rigorous instead of hoping for testing not to turn up counterexamples.
Call me heretical, but despite that I'm wholly confident in the proof,
and have done it two different ways now, I still put more faith in
testing ...
2002-08-15 20:06:00 +00:00
Tim Peters 9973d74b2d long_mul(): Simplified exit code. In particular, k_mul() returns a
normalized result, so no point to normalizing it again.  The number
of test+branches was also excessive.
2002-08-15 19:41:06 +00:00
Tim Peters 48d52c0fcc k_mul() comments: Simplified the simplified explanation of why ah*bh and
al*bl "always fit":  it's actually trivial given what came before.
2002-08-14 17:07:32 +00:00
Tim Peters 8e966ee49a k_mul() comments: Explained why there's always enough room to subtract
ah*bh and al*bl.  This is much easier than explaining why that's true
for (ah+al)*(bh+bl), and follows directly from the simple part of the
(ah+al)*(bh+bl) explanation.
2002-08-14 16:36:23 +00:00
Tim Peters cba6e96929 Fixed error in new comment. 2002-08-13 20:42:00 +00:00
Tim Peters d6974a54ab k_mul(): The fix for (ah+al)*(bh+bl) spilling 1 bit beyond the allocated
space is no longer needed, so removed the code.  It was only possible when
a degenerate (ah->ob_size == 0) split happened, but after that fix went
in I added k_lopsided_mul(), which saves the body of k_mul() from seeing
a degenerate split.  So this removes code, and adds a honking long comment
block explaining why spilling out of bounds isn't possible anymore.  Note:
ff we end up spilling out of bounds anyway <wink>, an assert in v_iadd()
is certain to trigger.
2002-08-13 20:37:51 +00:00
Guido van Rossum d8c8048f5e Fix comment for PyLong_AsUnsignedLong() to say that the return value
is an *unsigned* long.
2002-08-13 00:24:58 +00:00
Tim Peters 1203403743 k_lopsided_mul(): This allocated more space for bslice than necessary. 2002-08-12 22:10:00 +00:00
Tim Peters 6000464d08 Added new function k_lopsided_mul(), which is much more efficient than
k_mul() when inputs have vastly different sizes, and a little more
efficient when they're close to a factor of 2 out of whack.

I consider this done now, although I'll set up some more correctness
tests to run overnight.
2002-08-12 22:01:34 +00:00
Tim Peters 547607c4bf k_mul(): Moved an assert down. In a debug build, interrupting a
multiply via Ctrl+C could cause a NULL-pointer dereference due to
the assert.
2002-08-12 19:43:49 +00:00
Tim Peters 70b041bbe7 k_mul(): Heh -- I checked in two fixes for the last problem. Only keep
the good one <wink>.  Also checked in a test-aid by mistake.
2002-08-12 19:38:01 +00:00
Tim Peters d8b2173ef9 k_mul(): White-box testing turned up that (ah+al)*(bh+bl) can, in rare
cases, overflow the allocated result object by 1 bit.  In such cases,
it would have been brought back into range if we subtracted al*bl and
ah*bh from it first, but I don't want to do that because it hurts cache
behavior.  Instead we just ignore the excess bit when it appears -- in
effect, this is forcing unsigned mod BASE**(asize + bsize) arithmetic
in a case where that doesn't happen all by itself.
2002-08-12 19:30:26 +00:00
Tim Peters 115c888b97 x_mul(): Made life easier for C optimizers in the "grade school"
algorithm.  MSVC 6 wasn't impressed <wink>.

Something odd:  the x_mul algorithm appears to get substantially worse
than quadratic time as the inputs grow larger:

bits in each input   x_mul time   k_mul time
------------------   ----------   ----------
             15360         0.01         0.00
             30720         0.04         0.01
             61440         0.16         0.04
            122880         0.64         0.14
            245760         2.56         0.40
            491520        10.76         1.23
            983040        71.28         3.69
           1966080       459.31        11.07

That is, x_mul is perfectly quadratic-time until a little burp at
2.56->10.76, and after that goes to hell in a hurry.  Under Karatsuba,
doubling the input size "should take" 3 times longer instead of 4, and
that remains the case throughout this range.  I conclude that my "be nice
to the cache" reworkings of k_mul() are paying.
2002-08-12 18:25:43 +00:00
Tim Peters d64c1def7c k_mul() and long_mul(): I'm confident that the Karatsuba algorithm is
correct now, so added some final comments, did some cleanup, and enabled
it for all long-int multiplies.  The KARAT envar no longer matters,
although I left some #if 0'ed code in there for my own use (temporary).
k_mul() is still much slower than x_mul() if the inputs have very
differenent sizes, and that still needs to be addressed.
2002-08-12 17:36:03 +00:00
Tim Peters 738eda742c k_mul: Rearranged computation for better cache use. Ignored overflow
(it's possible, but should be harmless -- this requires more thought,
and allocating enough space in advance to prevent it requires exactly
as much thought, to know exactly how much that is -- the end result
certainly fits in the allocated space -- hmm, but that's really all
the thought it needs!  borrows/carries out of the high digits really
are harmless).
2002-08-12 15:08:20 +00:00
Tim Peters 44121a6bc9 x_mul(): This failed to normalize its result.
k_mul():  This didn't allocate enough result space when one input had
more than twice as many bits as the other.  This was partly hidden by
that x_mul() didn't normalize its result.

The Karatsuba recurrence is pretty much hosed if the inputs aren't
roughly the same size.  If one has at least twice as many bits as the
other, we get a degenerate case where the "high half" of the smaller
input is 0.  Added a special case for that, for speed, but despite that
it helped, this can still be much slower than the "grade school" method.
It seems to take a really wild imbalance to trigger that; e.g., a
2**22-bit input times a 1000-bit input on my box runs about twice as slow
under k_mul than under x_mul.  This still needs to be addressed.

I'm also not sure that allocating a->ob_size + b->ob_size digits is
enough, given that this is computing k = (ah+al)*(bh+bl) instead of
k = (ah-al)*(bl-bh); i.e., it's certainly enough for the final result,
but it's vaguely possible that adding in the "artificially" large k may
overflow that temporarily.  If so, an assert will trigger in the debug
build, but we'll probably compute the right result anyway(!).
2002-08-12 06:17:58 +00:00
Tim Peters 877a212678 Introduced helper functions v_iadd and v_isub, for in-place digit-vector
addition and subtraction.  Reworked the tail end of k_mul() to use them.
This saves oodles of one-shot longobject allocations (this is a triply-
recursive routine, so saving one allocation in the body saves 3**n
allocations at depth n; we actually save 2 allocations in the body).
2002-08-12 05:09:36 +00:00
Tim Peters fc07e56844 k_mul(): Repaired another typo in another comment. 2002-08-12 02:54:10 +00:00
Tim Peters 18c15b9bbd k_mul(): Repaired typo in comment. 2002-08-12 02:43:58 +00:00
Tim Peters 5af4e6c739 Cautious introduction of a patch that started from
SF 560379:  Karatsuba multiplication.
Lots of things were changed from that.  This needs a lot more testing,
for correctness and speed, the latter especially when bit lengths are
unbalanced.  For now, the Karatsuba code gets invoked if and only if
envar KARAT exists.
2002-08-12 02:31:19 +00:00
Jeremy Hylton 938ace69a0 staticforward bites the dust.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure.  Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers.  (In
fact, we expect that the compilers are all fixed eight years later.)

I'm leaving staticforward and statichere defined in object.h as
static.  This is only for backwards compatibility with C extensions
that might still use it.

XXX I haven't updated the documentation.
2002-07-17 16:30:39 +00:00
Guido van Rossum b6d29b7856 Undef MIN and MAX before defining them, to avoid warnings on certain
platforms.
2002-07-13 14:31:51 +00:00
Martin v. Löwis 14f8b4cfcb Patch #568124: Add doc string macros. 2002-06-13 20:33:02 +00:00
Jeremy Hylton c4ad0bcbe5 Clarify return value of PyLong_AsLongLong().
The function is documented to return -1 on error.  If res was < 0, it
returned res.  It wasn't clear that the invariant was res < 0 iff res
== -1.
2002-04-23 20:01:20 +00:00
Neil Schemenauer aa769ae468 PyObject_Del can now be used as a function designator. 2002-04-12 02:44:10 +00:00
Martin v. Löwis c8bb9eba31 Patch #494047: removes 64-bit ?: to cope on plan9. 2002-03-09 12:02:59 +00:00
Tim Peters 5329cdb3ce _PyLong_Copy(): was creating a copy of the absolute value, but should
copy the sign too.  Added a test to test_descr to ensure that it does.

Bugfix candidate.
2002-03-02 04:18:04 +00:00
Martin v. Löwis a5854c24a2 Patch #508038: Do not use a type as a variable name. 2002-02-16 23:39:10 +00:00
Tim Peters 6f97e493e1 long_true_divide(): decref its converted arguments. test_long_future.py
run in an infinite loop no longer grows.  Thanks to Neal Norwitz for
determining that test leaked!
2001-11-04 23:09:40 +00:00
Guido van Rossum 9475a2310d Enable GC for new-style instances. This touches lots of files, since
many types were subclassable but had a xxx_dealloc function that
called PyObject_DEL(self) directly instead of deferring to
self->ob_type->tp_free(self).  It is permissible to set tp_free in the
type object directly to _PyObject_Del, for non-GC types, or to
_PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
so I'm fearing that our pystone rating is going down again.  I'm not
sure if doing something like

void xxx_dealloc(PyObject *self)
{
	if (PyXxxCheckExact(self))
		PyObject_DEL(self);
	else
		self->ob_type->tp_free(self);
}

is any faster than always calling the else branch, so I haven't
attempted that -- however those types whose own dealloc is fancier
(int, float, unicode) do use this pattern.
2001-10-05 20:51:39 +00:00
Tim Peters d38b1c74f3 SF [#466125] PyLong_AsLongLong works for any integer.
Generalize PyLong_AsLongLong to accept int arguments too.  The real point
is so that PyArg_ParseTuple's 'L' code does too.  That code was
undocumented (AFAICT), so documented it.
2001-09-30 05:09:37 +00:00
Guido van Rossum 1952e388ca Add additional coercion support for "self subtypes" to int, long,
float (compare the recent checkin to complex).  Added tests for these.
2001-09-19 01:25:16 +00:00
Guido van Rossum 7e35d57c0c A fix for SF bug #461546 (bug in long_mul).
Both int and long multiplication are changed to be more careful in
their assumptions about when one of the arguments is a sequence: the
assumption that at least one of the arguments must be an int (or long,
respectively) is still held, but the assumption that these don't smell
like sequences is no longer true: a subtype of int or long may well
have a sequence-repeat thingie!
2001-09-15 03:14:32 +00:00
Skip Montanaro bafedecc06 based upon a suggestion in c.l.py, this slight expansion of the
OverflowError message seems reasonable.
2001-09-13 19:05:30 +00:00