Commit Graph

146 Commits

Author SHA1 Message Date
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
Tim Peters 40c397dd56 long_invert(): tiny speed and space optimization. 2001-09-11 23:24:22 +00:00
Tim Peters 69c2de3ad6 More bug 460020. Disable a number of long optimizations for long subclasses. 2001-09-11 22:31:33 +00:00
Tim Peters 64b5ce3a69 SF bug #460020: bug or feature: unicode() and subclasses.
Given an immutable type M, and an instance I of a subclass of M, the
constructor call M(I) was just returning I as-is; but it should return a
new instance of M.  This fixes it for M in {int, long}.  Strings, floats
and tuples remain to be done.
Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily
distinguish between "is" and "is a" (i.e., only an int passes
PyInt_CheckExact, while any sublass of int passes PyInt_Check).
Added private API function _PyLong_Copy.
2001-09-10 20:52:51 +00:00
Tim Peters e56ed9ba15 long_true_divide: reliably force underflow to 0 when the denominator
has more bits than the numerator than can be counted in a C int (yes,
that's unlikely, and no, I'm not adding a test case with a 2 gigabit
long).
2001-09-06 21:59:14 +00:00
Tim Peters 4c483c4d8e Make the error msgs in our pow() implementations consistent. 2001-09-05 06:24:58 +00:00
Tim Peters 57f282a2a0 Try to recover from that glibc's ldexp apparently doesn't set errno on
overflow.  Needs testing on Linux (test_long.py and test_long_future.py
especially).
2001-09-05 05:38:10 +00:00
Tim Peters e2a600099d Change long/long true division to return as many good bits as it can;
e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.
2001-09-04 06:17:36 +00:00
Tim Peters 20dab9f168 Move long_true_divide next to the other division routines (for clarity!). 2001-09-04 05:31:47 +00:00
Tim Peters 9fffa3eea3 Raise OverflowError when appropriate on long->float conversion. Most of
the fiddling is simply due to that no caller of PyLong_AsDouble ever
checked for failure (so that's fixing old bugs).  PyLong_AsDouble is much
faster for big inputs now too, but that's more of a happy consequence
than a design goal.
2001-09-04 05:14:19 +00:00
Tim Peters a1c1b0f468 Introduce new private API function _PyLong_AsScaledDouble. Not used yet,
but will be the foundation for Good Things:
+ Speed PyLong_AsDouble.
+ Give PyLong_AsDouble the ability to detect overflow.
+ Make true division of long/long nearly as accurate as possible (no
  spurious infinities or NaNs).
+ Return non-insane results from math.log and math.log10 when passing a
  long that can't be approximated by a double better than HUGE_VAL.
2001-09-04 02:50:49 +00:00