summaryrefslogtreecommitdiffstats
path: root/Objects/longobject.c
Commit message (Collapse)AuthorAgeFilesLines
...
* More bug 460020. Disable a number of long optimizations for long subclasses.Tim Peters2001-09-111-18/+15
|
* SF bug #460020: bug or feature: unicode() and subclasses.Tim Peters2001-09-101-1/+20
| | | | | | | | | | | 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.
* long_true_divide: reliably force underflow to 0 when the denominatorTim Peters2001-09-061-0/+2
| | | | | | 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).
* Make the error msgs in our pow() implementations consistent.Tim Peters2001-09-051-3/+10
|
* Try to recover from that glibc's ldexp apparently doesn't set errno onTim Peters2001-09-051-2/+2
| | | | | overflow. Needs testing on Linux (test_long.py and test_long_future.py especially).
* Change long/long true division to return as many good bits as it can;Tim Peters2001-09-041-1/+32
| | | | e.g., (1L << 40000)/(1L << 40001) returns 0.5, not Inf or NaN or whatever.
* Move long_true_divide next to the other division routines (for clarity!).Tim Peters2001-09-041-6/+6
|
* Raise OverflowError when appropriate on long->float conversion. Most ofTim Peters2001-09-041-18/+19
| | | | | | | 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.
* Introduce new private API function _PyLong_AsScaledDouble. Not used yet,Tim Peters2001-09-041-0/+52
| | | | | | | | | | 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.
* New restriction on pow(x, y, z): If z is not None, x and y must be ofTim Peters2001-09-031-3/+8
| | | | | integer types, and y must be >= 0. See discussion at http://sf.net/tracker/index.php?func=detail&aid=457066&group_id=5470&atid=105470
* Add warning mode for classic division, almost exactly as specified inGuido van Rossum2001-08-311-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PEP 238. Changes: - add a new flag variable Py_DivisionWarningFlag, declared in pydebug.h, defined in object.c, set in main.c, and used in {int,long,float,complex}object.c. When this flag is set, the classic division operator issues a DeprecationWarning message. - add a new API PyRun_SimpleStringFlags() to match PyRun_SimpleString(). The main() function calls this so that commands run with -c can also benefit from -Dnew. - While I was at it, I changed the usage message in main() somewhat: alphabetized the options, split it in *four* parts to fit in under 512 bytes (not that I still believe this is necessary -- doc strings elsewhere are much longer), and perhaps most visibly, don't display the full list of options on each command line error. Instead, the full list is only displayed when -h is used, and otherwise a brief reminder of -h is displayed. When -h is used, write to stdout so that you can do `python -h | more'. Notes: - I don't want to use the -W option to control whether the classic division warning is issued or not, because the machinery to decide whether to display the warning or not is very expensive (it involves calling into the warnings.py module). You can use -Werror to turn the warnings into exceptions though. - The -Dnew option doesn't select future division for all of the program -- only for the __main__ module. I don't know if I'll ever change this -- it would require changes to the .pyc file magic number to do it right, and a more global notion of compiler flags. - You can usefully combine -Dwarn and -Dnew: this gives the __main__ module new division, and warns about classic division everywhere else.
* Ah, the joy of writing test cases...Guido van Rossum2001-08-301-1/+1
| | | | | long_subtype_new(): fix a typo (type->ob_size instead of tmp->ob_size).
* Make int, long and float subclassable.Guido van Rossum2001-08-291-2/+36
| | | | This uses a slightly wimpy and wasteful approach, but it works. :-)
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-0/+4
| | | | | | | | - Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled - check for Py_USING_UNICODE in all places that use Unicode functions - disables unicode literals, and the builtin functions - add the types.StringTypes list - remove Unicode literals from most tests.
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-11/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces: - A new operator // that means floor division (the kind of division where 1/2 is 0). - The "future division" statement ("from __future__ import division) which changes the meaning of the / operator to implement "true division" (where 1/2 is 0.5). - New overloadable operators __truediv__ and __floordiv__. - New slots in the PyNumberMethods struct for true and floor division, new abstract APIs for them, new opcodes, and so on. I emphasize that without the future division statement, the semantics of / will remain unchanged until Python 3.0. Not yet implemented are warnings (default off) when / is used with int or long arguments. This has been on display since 7/31 as SF patch #443474. Flames to /dev/null.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-20/+75
|
* 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.