summaryrefslogtreecommitdiffstats
path: root/Objects/longobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Python.h: Don't attempt to redefine NDEBUG if it's already defined.Tim Peters2001-07-151-1/+0
| | | | Others: Remove redundant includes of assert.h.
* long_format: Simplify the overly elaborate base-is-a-power-of-2 code.Tim Peters2001-07-151-28/+16
|
* divrem1 & long_format: found a clean way to factor divrem1 so thatTim Peters2001-07-141-28/+54
| | | | | long_format can reuse a scratch area for its repeated divisions (instead of malloc/free for every digit produced); speeds str(long)/repr(long).
* long_format(): Simplify new code a bit.Tim Peters2001-07-141-5/+8
|
* long_format(): Easy speedup for output bases that aren't a power of 2 (inTim Peters2001-07-131-9/+26
| | | | | | | particular, str(long) and repr(long) use base 10, and that gets a factor of 4 speedup). Another factor of 2 can be gotten by refactoring divrem1 to support in-place division, but that started getting messy so I'm leaving that out.
* On long to the negative long power, let float handle it instead ofGuido van Rossum2001-07-121-8/+7
| | | | | | raising an error. This was one of the two issues that the VPython folks were particularly problematic for their students. (The other one was integer division...) This implements (my) SF patch #440487.
* PyLong_{As, From}VoidPtr: cleanup, replacing assumptions in comments withTim Peters2001-06-161-15/+23
| | | | #if/#error constructs.
* Change IS_LITTLE_ENDIAN macro -- a little faster now.Tim Peters2001-06-141-1/+1
|
* _PyLong_AsByteArray: simplify the logic for dealing with the most-Tim Peters2001-06-141-11/+13
| | | | significant digits sign bits. Again no change in semantics.
* PyLong_From{Unsigned,}Long: count the # of digits first, so no more spaceTim Peters2001-06-141-21/+41
| | | | | | is allocated than needed (used to allocate 80 bytes of digit space no matter how small the long input). This also runs faster, at least on 32- bit boxes.
* _PyLong_FromByteArray: changed decl of "carry" to match "thisbyte". NoTim Peters2001-06-131-1/+1
| | | | | semantic change, but a bit clearer and may help a really stupid compiler avoid pointless runtime length conversions.
* _PyLong_AsByteArray: Don't do the "delicate overflow" check unless it'sTim Peters2001-06-131-9/+18
| | | | truly needed; usually saves a little time, but no change in semantics.
* _PyLong_AsByteArray: added assert that the input is normalized. This isTim Peters2001-06-131-1/+5
| | | | outside the function's control, but is crucial to correct operation.
* PyLong_As{Unsigned,}LongLong: fiddled final result casting.Tim Peters2001-06-131-2/+2
|
* longobject.c:Tim Peters2001-06-131-126/+41
| | | | | | | | | | | Replaced PyLong_{As,From}{Unsigned,}LongLong guts with calls to _PyLong_{As,From}ByteArray. _testcapimodule.c: Added strong tests of PyLong_{As,From}{Unsigned,}LongLong. Fixes SF bug #432552 PyLong_AsLongLong() problems. Possible bugfix candidate, but the fix relies on code added to longobject to support the new q/Q structmodule format codes.
* _PyLong_{As,From}ByteArray: Minor code rearrangement aimed at improvingTim Peters2001-06-121-11/+14
| | | | clarity. Should have no effect visible to callers.
* Added q/Q standard (x-platform 8-byte ints) mode in struct module.Tim Peters2001-06-121-6/+19
| | | | | | | | | | | | | | This completes the q/Q project. longobject.c _PyLong_AsByteArray: The original code had a gross bug: the most-significant Python digit doesn't necessarily have SHIFT significant bits, and you really need to count how many copies of the sign bit it has else spurious overflow errors result. test_struct.py: This now does exhaustive std q/Q testing at, and on both sides of, all relevant power-of-2 boundaries, both positive and negative. NEWS: Added brief dict news while I was at it.
* Two new private longobject API functions,Tim Peters2001-06-111-0/+213
| | | | | | | | | | _PyLong_FromByteArray _PyLong_AsByteArray Untested and probably buggy -- they compile OK, but nothing calls them yet. Will soon be called by the struct module, to implement x-platform 'q' and 'Q'. If other people have uses for them, we could move them into the public API. See longobject.h for usage details.
* Rich comparisons fall-out:Guido van Rossum2001-01-171-17/+1
| | | | | | - Get rid of long_cmp(). - Renamed Py_TPFLAGS_NEWSTYLENUMBER to Py_TPFLAGS_CHECKTYPES.
* Make long a new style number type. Sequence repeat is now done hereNeil Schemenauer2001-01-041-76/+262
| | | | now as well.
* Ka-Ping Yee <ping@lfw.org>:Fred Drake2000-10-241-4/+4
| | | | | | Changes to error messages to increase consistency & clarity. This (mostly) closes SourceForge patch #101839.
* SF bug 115831 and Ping's SF patch 101751, 0.0**-2.0 returns inf rather thanTim Peters2000-10-061-2/+6
| | | | | | | | | | raise ValueError. Checked in the patch as far as it went, but also changed all of ints, longs and floats to raise ZeroDivisionError instead when raising 0 to a negative number. This is what 754-inspired stds require, as the "true result" is an infinity obtained from finite operands, i.e. it's a singularity. Also changed float pow to not be so timid about using its square-and-multiply algorithm. Note that what math.pow does is unrelated to what builtin pow does, and will still vary by platform.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-011-9/+0
| | | | This should match the situation in the 1.6b1 tree.
* Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470.Tim Peters2000-08-151-1/+1
| | | | | | | | | | | This was a misleading bug -- the true "bug" was that hash(x) gave an error return when x is an infinity. Fixed that. Added new Py_IS_INFINITY macro to pyport.h. Rearranged code to reduce growing duplication in hashing of float and complex numbers, pushing Trent's earlier stab at that to a logical conclusion. Fixed exceedingly rare bug where hashing of floats could return -1 even if there wasn't an error (didn't waste time trying to construct a test case, it was simply obvious from the code that it *could* happen). Improved complex hash so that hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore.
* merge Include/my*.h into Include/pyport.hPeter Schneider-Kamp2000-07-311-1/+0
| | | | marked my*.h as obsolete
* Cray J90 fixes for long ints.Tim Peters2000-07-081-5/+8
| | | | | | | | | | | | | | | | This was a convenient excuse to create the pyport.h file recently discussed! Please use new Py_ARITHMETIC_RIGHT_SHIFT when right-shifting a signed int and you *need* sign-extension. This is #define'd in pyport.h, keying off new config symbol SIGNED_RIGHT_SHIFT_ZERO_FILLS. If you're running on a platform that needs that symbol #define'd, the std tests never would have worked for you (in particular, at least test_long would have failed). The autoconfig stuff got added to Python after my Unix days, so I don't know how that works. Would someone please look into doing & testing an auto-config of the SIGNED_RIGHT_SHIFT_ZERO_FILLS symbol? It needs to be defined if & only if, e.g., (-1) >> 3 is not -1.
* The tail end of x_sub implicitly assumed that an unsigned shortTim Peters2000-07-081-0/+1
| | | | contains 16 bits. Not true on Cray J90.
* Got RID of redundant coercions in longobject.c (as spotted by GregTim Peters2000-07-081-6/+3
| | | | | | | Stein -- thanks!). Incidentally removed all the Py_PROTO macros from object.h, as they prevented my editor from magically finding the definitions of the "coercion", "cmpfunc" and "reprfunc" typedefs that were being redundantly applied in longobject.c.
* Some cleanup of longs in prepartion for Cray J90 fixes: gotTim Peters2000-07-071-241/+105
| | | | | rid of Py_PROTO, switched to ANSI function decls, and did some minor fiddling.
* Change copyright notice - 2nd try.Guido van Rossum2000-06-301-6/+0
|
* Change copyright notice.Guido van Rossum2000-06-301-22/+7
|
* Trent Mick <trentm@ActiveState.com>:Fred Drake2000-06-011-2/+2
| | | | | | | This patch correct bounds checking in PyLong_FromLongLong. Currently, it does not check properly for negative values when checking to see if the incoming value fits in a long or unsigned long. This results in possible silent truncation of the value for very large negative values.
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-031-1/+1
| | | | | | | | | | For more comments, read the patches@python.org archives. For documentation read the comments in mymalloc.h and objimpl.h. (This is not exactly what Vladimir posted to the patches list; I've made a few changes, and Vladimir sent me a fix in private email for a problem that only occurs in debug mode. I'm also holding back on his change to main.c, which seems unnecessary to me.)
* Simple optimization by Christian Tismer, who gives credit to LennyGuido van Rossum2000-04-101-0/+9
| | | | | Kneler for reporting this issue: long_mult() is faster when the smaller argument is on the left. Swap the arguments accordingly.
* Marc-Andre's third try at this bulk patch seems to work (except thatGuido van Rossum2000-04-051-7/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | his copy of test_contains.py seems to be broken -- the lines he deleted were already absent). Checkin messages: New Unicode support for int(), float(), complex() and long(). - new APIs PyInt_FromUnicode() and PyLong_FromUnicode() - added support for Unicode to PyFloat_FromString() - new encoding API PyUnicode_EncodeDecimal() which converts Unicode to a decimal char* string (used in the above new APIs) - shortcuts for calls like int(<int object>) and float(<float obj>) - tests for all of the above Unicode compares and contains checks: - comparing Unicode and non-string types now works; TypeErrors are masked, all other errors such as ValueError during Unicode coercion are passed through (note that PyUnicode_Compare does not implement the masking -- PyObject_Compare does this) - contains now works for non-string types too; TypeErrors are masked and 0 returned; all other errors are passed through Better testing support for the standard codecs. Misc minor enhancements, such as an alias dbcs for the mbcs codec. Changes: - PyLong_FromString() now applies the same error checks as does PyInt_FromString(): trailing garbage is reported as error and not longer silently ignored. The only characters which may be trailing the digits are 'L' and 'l' -- these are still silently ignored. - string.ato?() now directly interface to int(), long() and float(). The error strings are now a little different, but the type still remains the same. These functions are now ready to get declared obsolete ;-) - PyNumber_Int() now also does a check for embedded NULL chars in the input string; PyNumber_Long() already did this (and still does) Followed by: Looks like I've gone a step too far there... (and test_contains.py seem to have a bug too). I've changed back to reporting all errors in PyUnicode_Contains() and added a few more test cases to test_contains.py (plus corrected the join() NameError).
* long_format(): Now takes a third parameter, addL; iff true, aFred Drake1999-12-231-9/+19
| | | | | | | | | | | | | | | trailing 'L' is appended to the representation, otherwise not. All existing call sites are modified to pass true for addL. Remove incorrect statement about external use of this function from elsewhere; it's static! long_str(): Handler for the tp_str slot in the type object. Identical to long_repr(), but passes false as the addL parameter of long_format().
* Fix PR#66. Solution: add error checking around l_divmod() calls inGuido van Rossum1999-10-111-4/+18
| | | | long_pow().
* Patch by Tim Peters fixing PR#89:Guido van Rossum1999-09-271-0/+5
| | | | long(+/- infinity) returns nonsense.
* PyLong_FromString(): Nailed a small memory leak. In the str==startBarry Warsaw1999-01-271-0/+1
| | | | | test, we forgot that z is still pointing to a real live object. DECREF() it before returning.
* Changes for long file support by Steve Clift.Guido van Rossum1999-01-061-18/+0
| | | | (Really: moved a bunch of defs to longobject.h.)
* Remove unreachable code. (Sjoerd)Guido van Rossum1998-10-091-8/+0
|
* Patches from Greg Stein to support 'P' format in struct module'sGuido van Rossum1998-09-181-0/+55
| | | | | native format, as void* (translated to Python int or long). Also adds PyLong_FromVoidPtr and PyLong_AsVoidPtr to longobject.c.
* Undo victim of careless global substitute ("long long_hash" wasGuido van Rossum1998-09-131-1/+1
| | | | | changed to "LONG_LONG_hash" in the list of forward decls). Discovered by Jason Harper.
* Patch by Mark Hammond to support 64-bit ints on MS platforms.Guido van Rossum1998-08-251-22/+22
| | | | | | The MS compiler doesn't call it 'long long', it uses __int64, so a new #define, LONG_LONG, has been added and all occurrences of 'long long' are replaced with it.
* Two patches by Jason Harper:Guido van Rossum1998-08-111-37/+96
| | | | | | - Faster conversion to string for binary bases: linear instead of quadratic! - Allocate smaller result for certain masking ops, e.g. (1L<<30000) & 1.
* Changes for BeOS, QNX and long long, by Chris Herborth.Guido van Rossum1998-08-041-0/+192
|
* Fix a potential problem in PyLong_FromString(): could fall through theGuido van Rossum1998-08-041-0/+2
| | | | for loop with z==NULL but continue to reference z later.
* Add check in long-to-int conversion for at least one digit.Guido van Rossum1998-06-221-0/+7
|
* Subject: Buglet in PyLong_AsLongGuido van Rossum1998-05-261-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From: "Tim Peters" <tim_one@email.msn.com> To: "Guido van Rossum" <guido@CNRI.Reston.VA.US> Date: Sat, 23 May 1998 21:45:53 -0400 Guido, the overflow checking in PyLong_AsLong is off a little: 1) If the C in use sign-extends right shifts on signed longs, there's a spurious overflow error when converting the most-negative int: Python 1.5.1 (#0, Apr 13 1998, 20:22:04) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> x = -1L << 31 >>> x -2147483648L >>> int(x) Traceback (innermost last): File "<stdin>", line 1, in ? OverflowError: long int too long to convert >>> 2) If C does not sign-extend, some genuine overflows won't be caught. The attached should repair both, and, because I installed a new disk and a C compiler today, it's even been compiled this time <wink>. Python 1.5.1 (#0, May 23 1998, 20:24:58) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> x = -1L << 31 >>> x -2147483648L >>> int(x) -2147483648 >>> int(-x) Traceback (innermost last): File "<stdin>", line 1, in ? OverflowError: long int too long to convert >>> int(-x-1) 2147483647 >>> int(x-1) Traceback (innermost last): File "<stdin>", line 1, in ? OverflowError: long int too long to convert >>> end-casing-ly y'rs - tim
* Make new gcc -Wall happyGuido van Rossum1998-04-101-1/+1
|
generated by cgit v0.12 at 2025-03-04 18:52:57 (GMT)