summaryrefslogtreecommitdiffstats
path: root/Objects/floatobject.c
Commit message (Collapse)AuthorAgeFilesLines
* PyFloat_AsStringEx(): This function takes an output char* but doesn'tTim Peters2001-11-281-8/+24
| | | | | | | pass the buffer length. Stop using it. It should be deprecated, but too late in the release cycle to do that now. New static format_float() does the same thing but requires passing the buffer length too. Use it instead.
* PyFloat_FromString(): Conversion of sprintf() to PyOS_snprintf() forBarry Warsaw2001-11-281-2/+4
| | | | buffer overrun avoidance.
* float_divmod(): the code wasn't sick enough to stop the MS optimizerTim Peters2001-11-011-1/+1
| | | | | from optimizing away mod's sign adjustment when mod == 0; so it got the intended result only in the debug build.
* SF bug #477221: abs and divmod act oddly with -0.0Tim Peters2001-11-011-9/+26
| | | | | | | Try to ensure that divmod(-0.0, 1.0) -> (-0.0, +0.0) across platforms. It always did on Windows, and still does. It didn't on Linux. Alas, there's no platform-independent way to write a test case for this. Bugfix candidate.
* float_abs() again: Guido pointed out that this could screw up in theTim Peters2001-11-011-6/+1
| | | | | | presence of NaNs. So pass the issue on to the platform libm fabs(); after all, fabs() is a std C function because you can't implement it correctly in portable C89.
* SF bug #477221: abs and divmod act oddly with -0.0.Tim Peters2001-11-011-9/+11
| | | | | | Partial fix. float_abs(): ensure abs(-0.0) returns +0.0. Bugfix candidate.
* SF patch #474590 -- RISC OS supportGuido van Rossum2001-10-241-0/+7
|
* Enable GC for new-style instances. This touches lots of files, sinceGuido van Rossum2001-10-051-2/+6
| | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
generated by cgit v0.12 at 2024-11-22 09:53:39 (GMT)