summaryrefslogtreecommitdiffstats
path: root/Objects/floatobject.c
Commit message (Collapse)AuthorAgeFilesLines
* float_int(): Some systems raise an exception if a double is cast toTim Peters2002-11-211-14/+16
| | | | | | | | long but the double is too big to fit in a long. Prevent that. This closes some recent bug or patch on SF, but SF is down now so I can't say which. Bugfix candidate.
* Change int() so that passing a string, unicode, float or long argumentWalter Dörwald2002-11-191-11/+9
| | | | | | | 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
* Improve exception message raised by PyFloat_AsDouble if the object does notNeil Schemenauer2002-11-181-2/+6
| | | | have a nb_float slot. This matches what PyInt_AsLong does.
* Call me anal, but there was a particular phrase that was speading toGuido van Rossum2002-08-191-1/+1
| | | | | | | comments everywhere that bugged me: /* Foo is inlined */ instead of /* Inline Foo */. Somehow the "is inlined" phrase always confused me for half a second (thinking, "No it isn't" until I added the missing "here"). The new phrase is hopefully unambiguous.
* staticforward bites the dust.Jeremy Hylton2002-07-171-1/+1
| | | | | | | | | | | | | | | 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.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-2/+2
|
* clarify message when raising TypeError to indicate that float() acceptsSkip Montanaro2002-05-021-1/+1
| | | | strings or numbers
* SF bug 525705: [2.2] underflow raise OverflowException.Tim Peters2002-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | Another year in the quest to out-guess random C behavior. Added macros Py_ADJUST_ERANGE1(X) and Py_ADJUST_ERANGE2(X, Y). The latter is useful for functions with complex results. Two corrections to errno- after-libm-call are attempted: 1. If the platform set errno to ERANGE due to underflow, clear errno. Some unknown subset of libm versions and link options do this. It's allowed by C89, but I never figured anyone would do it. 2. If the platform did not set errno but overflow occurred, force errno to ERANGE. C89 required setting errno to ERANGE, but C99 doesn't. Some unknown subset of libm versions and link options do it the C99 way now. Bugfix candidate, but hold off until some Linux people actually try it, with and without -lieee. I'll send a help plea to Python-Dev.
* float_floor_div: An expression like 3.//1j crashed the interpreter, orTim Peters2001-12-111-9/+12
| | | | | | | delivered bizarre results. Check float_divmod for a Py_NotImplemented return and pass it along (instead of treating Py_NotImplemented as a 2-tuple). CONVERT_TO_DOUBLE: Added comments; this macro is obscure.
* float_int_div(): For clarity, move this closer to the other floatTim Peters2001-12-111-16/+16
| | | | division functions, and rename to float_floor_div.
* 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.
generated by cgit v0.12 at 2024-12-04 10:47:59 (GMT)