Dear PyPy developers, I have found two bugs while trying to run mpmath on pypy-1.2. This is with the Windows binary: Python 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0] on win32 My system is an HP 530, Intel Celeron M 520 @ 1.60 GHz, 1024 MB RAM running Windows XP. The first bug is an incompatibility with CPython. In CPython, builtin float functions accept arbitrary objects as long as they have a __float__ method. Consider the following code: class x(object): def __float__(self): return 1.0 class y(object): def __complex__(self): return 1.0j round(x()) import math; math.log(x()) import cmath; cmath.log(x()) import cmath; cmath.log(y()) CPython 2.6 gives: 1.0 0.0 0j 1.5707963267948966j CPython 2.5 gives: 1.0 0.0 0j TypeError: a float is required PyPy gives: TypeError: expected float, got x object TypeError: expected float, got x object 0j 1.5707963267948966j Presumably PyPy should do the same thing as 2.6 here. Secondly, there is an error somewhere in the long multiplication code: C:\pypy12>pypy Python 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0] on win32 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``no random bugs in random, after all''
import mpmath mpmath.runtests() mpmath imported from C:\pypy12\lib-python\2.5.2\mpmath mpmath backend: python mpmath mp class: <mpmath.ctx_mp.MPContext object at 0x0000001a> mpmath version: 0.15-svn Python version: 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0]
[...] test_functions2 agm ok 0.0446171 s airy ok 0.1957078 s appellf1 ok 1.1814778 s bessel ok 0.6132425 s coulomb ok 0.4926749 s e1 ok 0.0109151 s ei ok 0.0346402 s elliptic_integrals ok 0.2575911 s erf ok 0.3858091 s exp_integrals ok 0.0715859 s RPython traceback: File "implement_4.c", line 35008, in opcode_impl_for_mul__AccessDirect_star_2 File "implement_9.c", line 47885, in __mm_mul_W_LongObject_W_LongObject File "implement_13.c", line 3727, in _k_lopsided_mul File "implement_9.c", line 38027, in _k_mul Fatal RPython error: AssertionError The test that triggers the failure is "from mpmath import expint; expint('1.01', '1e-1000')". For your convenience, I have tracked down the precise numbers. Since they have several hundred digits, I put them in an attachment. Thank you for your hard work! Fredrik
(Note: Trying a second time, since the mail does not seem to have arrived on the first try. Sorry if it's a duplicate.) Dear PyPy developers, I have found two bugs while trying to run mpmath on pypy-1.2. This is with the Windows binary: Python 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0] on win32 My system is an HP 530, Intel Celeron M 520 @ 1.60 GHz, 1024 MB RAM running Windows XP. The first bug is an incompatibility with CPython. In CPython, builtin float functions accept arbitrary objects as long as they have a __float__ method. Consider the following code: class x(object): def __float__(self): return 1.0 class y(object): def __complex__(self): return 1.0j round(x()) import math; math.log(x()) import cmath; cmath.log(x()) import cmath; cmath.log(y()) CPython 2.6 gives: 1.0 0.0 0j 1.5707963267948966j CPython 2.5 gives: 1.0 0.0 0j TypeError: a float is required PyPy gives: TypeError: expected float, got x object TypeError: expected float, got x object 0j 1.5707963267948966j Presumably PyPy should do the same thing as 2.6 here. Secondly, there is an error somewhere in the long multiplication code: C:\pypy12>pypy Python 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0] on win32 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``no random bugs in random, after all''
import mpmath mpmath.runtests() mpmath imported from C:\pypy12\lib-python\2.5.2\mpmath mpmath backend: python mpmath mp class: <mpmath.ctx_mp.MPContext object at 0x0000001a> mpmath version: 0.15-svn Python version: 2.5.2 (72130, Mar 12 2010, 12:25:40) [PyPy 1.2.0]
[...] test_functions2 agm ok 0.0446171 s airy ok 0.1957078 s appellf1 ok 1.1814778 s bessel ok 0.6132425 s coulomb ok 0.4926749 s e1 ok 0.0109151 s ei ok 0.0346402 s elliptic_integrals ok 0.2575911 s erf ok 0.3858091 s exp_integrals ok 0.0715859 s RPython traceback: File "implement_4.c", line 35008, in opcode_impl_for_mul__AccessDirect_star_2 File "implement_9.c", line 47885, in __mm_mul_W_LongObject_W_LongObject File "implement_13.c", line 3727, in _k_lopsided_mul File "implement_9.c", line 38027, in _k_mul Fatal RPython error: AssertionError The test that triggers the failure is "from mpmath import expint; expint('1.01', '1e-1000')". For your convenience, I have tracked down the precise numbers. Since they have several hundred digits, I put them in an attachment. Thank you for your hard work! Fredrik
On Fri, Mar 12, 2010 at 8:00 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi Fredrik,
On Fri, Mar 12, 2010 at 10:01:52PM +0100, Fredrik Johansson wrote:
I have found two bugs while trying to run mpmath on pypy-1.2.
Thank you a lot for the precise bug reports :-) We will fix it.
Actually I fixed the one about fatal rpython assertion. There is also a problem, which seems to be windows only that I can't reproduce. (you need mpmath for that). from mpmath import fp for i in range(1000): fp.zeta(0.5+37235j)
Hi Maciek, hi Fredrik, On Fri, Mar 12, 2010 at 11:23:24PM -0700, Maciej Fijalkowski wrote:
Actually I fixed the one about fatal rpython assertion. There is also a problem, which seems to be windows only that I can't reproduce.
from mpmath import fp for i in range(1000): fp.zeta(0.5+37235j)
I fixed this in r72263. The issue was hard to pinpoint because it was caused by a fast-path malloc: on the slow path (i.e. rarely), it would call random C code without saving the XMM registers. That's wrong: there is -- on Windows only? -- a path through that C code that trashes the XMM registers. A bientot, Armin.
On Tue, Mar 16, 2010 at 10:01 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Maciek, hi Fredrik,
On Fri, Mar 12, 2010 at 11:23:24PM -0700, Maciej Fijalkowski wrote:
Actually I fixed the one about fatal rpython assertion. There is also a problem, which seems to be windows only that I can't reproduce.
from mpmath import fp for i in range(1000): fp.zeta(0.5+37235j)
I fixed this in r72263. The issue was hard to pinpoint because it was caused by a fast-path malloc: on the slow path (i.e. rarely), it would call random C code without saving the XMM registers. That's wrong: there is -- on Windows only? -- a path through that C code that trashes the XMM registers.
A bientot,
Armin.
Thank you! Fredrik
participants (3)
-
Armin Rigo -
Fredrik Johansson -
Maciej Fijalkowski