| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Probably should be backported.
|
| |
|
| |
|
|
|
|
| |
This fixes a problem that math.sqrt(-1) doesn't raise math.error.
|
| |
|
|
|
|
|
|
| |
* Py_BuildValue("(OOO)",a,b,c) --> PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a) --> PyTuple_New(0)
* Py_BuildValue("O", a) --> Py_INCREF(a)
|
|
|
|
|
|
|
| |
Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.
|
| |
|
|
|
|
|
|
| |
for Py_Main().
Thanks to Kalle Svensson and Skip Montanaro for the patches.
|
| |
|
|
|
|
| |
feature request 426539.
|
|
|
|
| |
instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
system:
SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES.
Work aroudn a bug in the SCO UnixWare atan2() implementation.
|
|
|
|
| |
minimizes roundoff error.
|
|
|
|
|
|
| |
getting Infs, NaNs, or nonsense in 2.1 and before; in yesterday's CVS we
were getting OverflowError; but these functions always make good sense
for positive arguments, no matter how large).
|
|
|
|
| |
Repaired the ldexp docstring (said the name of the func was "ldexp_doc").
|
|
|
|
|
|
| |
Peter Schneider-Kamp.
Clarified some docstrings in the spirit of the patch; left out the
degrees() and radians() functions (see the patch comments on SF).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
libm result is 0). Cautiously add a few libm exception test cases:
1. That exp(-huge) returns 0 without exception.
2. That exp(+huge) triggers OverflowError.
3. That sqrt(-1) raises ValueError specifically (apparently under glibc linked
with -lieee, it was raising OverflowError due to an accident of the way
mathmodule.c's CHECK() macro happened to deal with Infs and NaNs under gcc).
|
|
|
|
| |
FRED, please check my monkey-see-monkey-do Tex fiddling!
|
|
|
|
| |
This should match the situation in the 1.6b1 tree.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Py_FatalError() from module initialization functions. The importing
mechanism already checks for PyErr_Occurred() after module importation
and it Does The Right Thing.
Unfortunately, the following either were not compiled or tested by the
regression suite, due to issues with my development platform:
almodule.c
cdmodule.c
mpzmodule.c
puremodule.c
timingmodule.c
|
|
|
|
| |
(and yes, "Currintly" also counts <0.5 wink>)
|
|
|
|
| |
marked my*.h as obsolete
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and a couple of functions that were missed in the previous batches. Not
terribly tested, but very carefully scrutinized, three times.
All these were found by the little findkrc.py that I posted to python-dev,
which means there might be more lurking. Cases such as this:
long
func(a, b)
long a;
long b; /* flagword */
{
and other cases where the last ; in the argument list isn't followed by a
newline and an opening curly bracket. Regexps to catch all are welcome, of
course ;)
|
| |
|
|
|
|
|
|
|
| |
Revise math_1(), math_2(), stub-generating macros, and function tables to
use PyArg_ParseTuple() and properly provide the function name for error
message generation.
Fix pow() docstring for MPW 3.1; had said "power" instead of "pow".
|
|
|
|
| |
Reported on c.l.py by Kirill Simonov.
|
| |
|
| |
|
|
|
|
|
|
| |
that before) in the previous patch has one problem; rint() is not in
the C math library on all platforms (e.g. not for VC++). Make it
conditional on HAVE_RINT.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix overflow bug in ldexp(x, exp). The 'exp' argument maps to a C int for the
math library call [double ldexp(double, int)], however the 'd'
PyArg_ParseTuple formatter was used to yield a double, which was subsequently
cast to an int. This could overflow.
[GvR: mysteriously, on Solaris 2.7, ldexp(1, 2147483647) returns Inf
while ldexp(1, 2147483646) raises OverflowError; this seems a bug in
the math library (it also takes a real long time to compute the
Inf outcome). Does this point to a bug in the CHECK() macro? It
should have discovered that the result was outside the HUGE_VAL range.]
|
| |
|
| |
|
|
|
|
| |
on BeOS or Windows.
|
| |
|
| |
|
|
|
|
|
| |
Two new modules fpectl and fpetest.
Surround various and sundry f.p. operations with PyFPE_*_PROTECT macros.
|
|
|
|
| |
substituted the appropriate PyArg_Parse calls. Retested. All appears well.
|
|
|
|
| |
Watch it, Barry! :-)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|