nirinA raseliarison [EMAIL PROTECTED] added the comment:
pure Python codes are posted to ASPN:
http://code.activestate.com/recipes/576391/
http://code.activestate.com/recipes/576393/
i also rewrote the patch so that they don't
use the high_word/low_word macros anymore.
Added file:
nirinA raseliarison [EMAIL PROTECTED] added the comment:
i wrote pure Python equivalent of the patch and will
post it to the ASPN cookbook as suggested. i'm wondering
if i have to upload the code here too, or just the link
will suffice?
Raymond Hettinger:
Can you also implement blending of
Mark Dickinson [EMAIL PROTECTED] added the comment:
I'm +1 on making gamma() be the true gamma function and not carrying
over this brain-damage to Python.
+1 from me, too.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
nirinA raseliarison [EMAIL PROTECTED] added the comment:
ouch!
i was asleep, at 3AM, when i edited the issue
and didn't really know what i was doing.
i just see that i removed, instead of edited the
mathmodule.diff and didn't check after.
so here it is again, with the url for original code
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Can you also implement blending of approximations: (1-t)*f1(x) + t*f2
(x)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
Daniel Stutzbach [EMAIL PROTECTED] added the comment:
On Fri, Jul 25, 2008 at 1:37 PM, Raymond Hettinger
[EMAIL PROTECTED]wrote:
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Can you also implement blending of approximations: (1-t)*f1(x) + t*f2
(x)
Is this necessary? Are the
Changes by nirinA raseliarison [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10954/mathmodule.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
Changes by nirinA raseliarison [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10973/pymath.c.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
Changes by nirinA raseliarison [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10974/mathmodule.c.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
Changes by nirinA raseliarison [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10975/pymath.h.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
Changes by nirinA raseliarison [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10976/test_math.py.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
nirinA raseliarison [EMAIL PROTECTED] added the comment:
Mark Dickinson :
So a full patch for this should touch at least Python/pymath.c,
Modules/mathmodule.c, configure.in, Lib/test/test_math.py, and
Doc/Library/math.rst.
here are patches for Python/pymath.c, Modules/mathmodule.c,
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Why isn't tgamma() simply named gamma()? The t prefix does nothing for
me except raise questions.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
Daniel Stutzbach [EMAIL PROTECTED] added the comment:
I think he just carried the names over from C, where:
tgamma() is the true gamma function
lgamma() is the log of the gamma function
and gamma() might be tgamma() or lgamma() depending on which C library
you use (sigh).
I'm +1 on making
nirinA raseliarison [EMAIL PROTECTED] added the comment:
and this is the header.
it is stolen from glibc.
Added file: http://bugs.python.org/file10955/math_private.h
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
Mark Dickinson [EMAIL PROTECTED] added the comment:
Thanks for the patch! I probably won't get to this properly until after
2.6 final, but it won't get lost. It seems like there's pretty good
support for adding these functions.
By the way, there's already a setup in Python 2.6 (ad 3.0) for
Daniel Stutzbach [EMAIL PROTECTED] added the comment:
On Mon, Jul 21, 2008 at 5:34 PM, Raymond Hettinger
[EMAIL PROTECTED] wrote:
There are several different approximations to choose from. Each of
them has their own implications for speed and accuracy.
FWIW, the current patch dynamically
Raymond Hettinger [EMAIL PROTECTED] added the comment:
It would be nice if we knew the error bounds for each of the
approximation methods. Do we know how the coefficients were generated?
When switching from one method to another, it might be nice to have a
range where the results slowly blend
New submission from Terry J. Reedy [EMAIL PROTECTED]:
From Py3000 list: in C99 standard math library, but need code when not
yet in particular implementation.
Dickinson: open and assign to me
Stutzbach: I suggest using the versions from newlib's libm. They contain
extensive comments
Changes by Daniel Stutzbach [EMAIL PROTECTED]:
--
nosy: +stutzbach
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3366
___
___
Python-bugs-list mailing
20 matches
Mail list logo
