summaryrefslogtreecommitdiffstats
path: root/Objects/floatobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Add additional coercion support for "self subtypes" to int, long,Guido van Rossum2001-09-191-0/+5
| | | | float (compare the recent checkin to complex). Added tests for these.
* Again perhaps the end of [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-121-1/+1
| | | | | Inhibited complex unary plus optimization when applied to a complex subtype. Added PyComplex_CheckExact macro. Some comments and minor code fiddling.
* More bug 460020: when F is a subclass of float, disable the unary plusTim Peters2001-09-111-2/+6
| | | | optimization (+F(whatever)).
* Replace a few places where X->ob_type was compared to &PyXXX_Type withGuido van Rossum2001-09-111-3/+3
| | | | calls to PyXXX_CheckExact(X).
* Better error msg for 3-arg pow with a float argument.Tim Peters2001-09-051-1/+1
|
* Rework the way we try to check for libm overflow, given that C99 no longerTim Peters2001-09-051-16/+1
| | | | | | | | | | | | | | | requires that errno ever get set, and it looks like glibc is already playing that game. New rules: + Never use HUGE_VAL. Use the new Py_HUGE_VAL instead. + Never believe errno. If overflow is the only thing you're interested in, use the new Py_OVERFLOWED(x) macro. If you're interested in any libm errors, use the new Py_SET_ERANGE_IF_OVERFLOW(x) macro, which attempts to set errno the way C89 said it worked. Unfortunately, none of these are reliable, but they work on Windows and I *expect* under glibc too.
* Make the error msgs in our pow() implementations consistent.Tim Peters2001-09-051-2/+2
|
* Raise OverflowError when appropriate on long->float conversion. Most ofTim Peters2001-09-041-5/+6
| | | | | | | 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.
* PEP 238 documented -Qwarn as warning only for classic int or longGuido van Rossum2001-09-041-1/+1
| | | | | division, and this makes sense. Add -Qwarnall to warn for all classic divisions, as required by the fixdiv.py tool.
* New restriction on pow(x, y, z): If z is not None, x and y must be ofTim Peters2001-09-031-15/+7
| | | | | 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/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix typo: double semicolons.Guido van Rossum2001-08-301-1/+1
|
* Make int, long and float subclassable.Guido van Rossum2001-08-291-5/+35
| | | | This uses a slightly wimpy and wasteful approach, but it works. :-)
* float_pow: Put *all* of the burden on the libm pow in normalTim Peters2001-08-231-45/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | cases. powu: Deleted. This started with a nonsensical error msg: >>> x = -1. >>> import sys >>> x**(-sys.maxint-1L) Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: negative number cannot be raised to a fractional power >>> The special-casing in float_pow was simply wrong in this case (there's not even anything peculiar about these inputs), and I don't see any point to it in *any* case: a decent libm pow should have worst-case error under 1 ULP, so in particular should deliver the exact result whenever the exact result is representable (else its error is at least 1 ULP). Thus our special fiddling for integral values "shouldn't" buy anything in accuracy, and, to the contrary, repeated multiplication is less accurate than a decent pow when the true result isn't exactly representable. So just letting pow() do its job here (we may not be able to trust libm x-platform in exceptional cases, but these are normal cases).
* 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-13/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-16/+54
|
* SF bug #444510: int() should guarantee truncation.Tim Peters2001-07-261-7/+13
| | | | It's guaranteed now, assuming the platform modf() works correctly.
* SF bug #422177: Results from .pyc differs from .pyTim Peters2001-05-081-0/+6
| | | | | | | | Store floats and doubles to full precision in marshal. Test that floats read from .pyc/.pyo closely match those read from .py. Declare PyFloat_AsString() in floatobject header file. Add new PyFloat_AsReprString() API function. Document the functions declared in floatobject.h.
* When 1.6 boosted the # of digits produced by repr(float), repr(complex)Tim Peters2001-03-111-1/+0
| | | | apparently forgot to play along. Make complex act like float.
* Avoid giving prototypes on Solaris.Martin v. Löwis2001-03-061-1/+1
|
* SF patch 103543 from tg@freebsd.org:Jeremy Hylton2001-02-011-1/+1
| | | | PyFPE_END_PROTECT() was called on undefined var
* Rich comparisons fall-out:Guido van Rossum2001-01-171-14/+1
| | | | | | - Get rid of float_cmp(). - Renamed Py_TPFLAGS_NEWSTYLENUMBER to Py_TPFLAGS_CHECKTYPES.
* Fix a silly bug in float_pow. Sorry Tim.Neil Schemenauer2001-01-081-1/+1
|
* Make float a new style number type.Neil Schemenauer2001-01-041-42/+108
|
* Ka-Ping Yee <ping@lfw.org>:Fred Drake2000-10-241-2/+2
| | | | | | 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-28/+35
| | | | | | | | | | 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.
* Rationalize use of limits.h, moving the inclusion to Python.h.Fred Drake2000-09-261-30/+0
| | | | | | | | Add definitions of INT_MAX and LONG_MAX to pyport.h. Remove includes of limits.h and conditional definitions of INT_MAX and LONG_MAX elsewhere. This closes SourceForge patch #101659 and bug #115323.
* Replace SIGFPE paranoia around strtod and atof. I don't believe theseTim Peters2000-09-251-0/+4
| | | | | fncs are allowed to raise SIGFPE (see the C std), but OK by me if people using --with-fpectl want to pay for checking anyway.
* Fix for SF bug 110624: float literals behave inconsistently.Tim Peters2000-09-231-16/+44
| | | | | | | | | | | | | | | | | | | | | | | | I fixed the specific complaint but left the (many) large issues untouched. See the (very long) bug report discussion for why: http://sourceforge.net/bugs/?func=detailbug&group_id=5470&bug_id=110624 Note that while I left the interface to the undocumented public API function PyFloat_FromString alone, its 2nd argument is useless. From a comment block in the code: RED_FLAG 22-Sep-2000 tim PyFloat_FromString's pend argument is braindead. Prior to this RED_FLAG, 1. If v was a regular string, *pend was set to point to its terminating null byte. That's useless (the caller can find that without any help from this function!). 2. If v was a Unicode string, or an object convertible to a character buffer, *pend was set to point into stack trash (the auto temp vector holding the character buffer). That was downright dangerous. Since we can't change the interface of a public API function, pend is still supported but now *officially* useless: if pend is not NULL, *pend is set to NULL.
* Fixed legit gripe from c.l.py that math.fmod docs aren't confusing enough.Tim Peters2000-09-161-1/+1
| | | | FRED, please check my monkey-see-monkey-do Tex fiddling!
* 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.
* PyFloat_FromString(): Move s_buffer[] up to the top-level functionBarry Warsaw2000-08-181-2/+1
| | | | | | scope. Previously, s_buffer[] was defined inside the PyUnicode_Check() scope, but referred to in the outer scope via assignment to s. This quiets an Insure portability warning.
* Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470.Tim Peters2000-08-151-38/+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.
* Clean up a warning on Win64. The downcast of the strlen size_tTrent Mick2000-08-121-1/+1
| | | | | return value to int is safe here because it previously checked that there will be no overflow.
* merge Include/my*.h into Include/pyport.hPeter Schneider-Kamp2000-07-311-1/+0
| | | | marked my*.h as obsolete
* Remove legacy use of __SC__; no longer needed now that ANSI source isFred Drake2000-07-091-5/+0
| | | | the standard for Python implementation.
* ANSI-fication of the sources.Fred Drake2000-07-091-70/+29
|
* Nuke all remaining occurrences of Py_PROTO and Py_FPROTO.Tim Peters2000-07-091-3/+3
|
* 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-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The common technique for printing out a pointer has been to cast to a long and use the "%lx" printf modifier. This is incorrect on Win64 where casting to a long truncates the pointer. The "%p" formatter should be used instead. The problem as stated by Tim: > Unfortunately, the C committee refused to define what %p conversion "looks > like" -- they explicitly allowed it to be implementation-defined. Older > versions of Microsoft C even stuck a colon in the middle of the address (in > the days of segment+offset addressing)! The result is that the hex value of a pointer will maybe/maybe not have a 0x prepended to it. Notes on the patch: There are two main classes of changes: - in the various repr() functions that print out pointers - debugging printf's in the various thread_*.h files (these are why the patch is large) Closes SourceForge patch #100505.
* This patch addresses two main issues: (1) There exist some non-fatalFred Drake2000-06-291-10/+11
| | | | | | | | | | | | | | | | | | | | errors in some of the hash algorithms. For exmaple, in float_hash and complex_hash a certain part of the value is not included in the hash calculation. See Tim's, Guido's, and my discussion of this on python-dev in May under the title "fix float_hash and complex_hash for 64-bit *nix" (2) The hash algorithms that use pointers (e.g. func_hash, code_hash) are universally not correct on Win64 (they assume that sizeof(long) == sizeof(void*)) As well, this patch significantly cleans up the hash code. It adds the two function _Py_HashDouble and _PyHash_VoidPtr that the various hashing routine are changed to use. These help maintain the hash function invariant: (a==b) => (hash(a)==hash(b))) I have added Lib/test/test_hash.py and Lib/test/output/test_hash to test this for some cases.
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-031-8/+6
| | | | | | | | | | 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.)
* Marc-Andre's third try at this bulk patch seems to work (except thatGuido van Rossum2000-04-051-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Many changes for Unicode, by Marc-Andre Lemburg.Guido van Rossum2000-03-101-8/+15
|
* The rest of the changes by Trent Mick and Dale Nagata for warning-freeGuido van Rossum2000-01-201-1/+1
| | | | compilation on NT Alpha. Mostly added casts etc.
* Implement the other easy thing: repr() of a float now uses %.17g,Guido van Rossum1999-12-231-6/+43
| | | | while str() uses %.12g as before.
* Mainlining the string_methods branch. See branch revision logBarry Warsaw1999-10-121-0/+51
| | | | messages for specific changes.
* Tim Peters writes:Guido van Rossum1999-05-061-7/+19
| | | | | | | | | | 1. Fixes float divmod so that the quotient it returns is always an integral value. 2. Fixes float % and float divmod so that the remainder always gets the right sign (the current code uses a "are the signs different?" test that doesn't work half the time <wink> when the product of the divisor and the remainder underflows to 0).
generated by cgit v0.12 at 2024-12-28 12:22:25 (GMT)