mpmath now works with Python 3!
Fredrik Johansson
Python 3 and mpmath.runtests() passes.
---------------------------------------------------------------------------
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import mpmath
>>> mpmath.mpf(1)/3
mpf('0.33333333333333331')
>>> mpmath.quad(mpmath.sin, [0,mpmath.pi])
mpf('2.0')
>>> mpmath.runtests()
mpmath imported from c:\source\mp\trunk\mpmath
mpmath backend: python
mpmath mp class: <mpmath.ctx_mp.MPContext object at 0x00EEE830>
mpmath version: 0.17-svn
Python version: 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500
32 bit (Intel)]
test_basic_ops
add ok 0.0014477 s
add_misc ok 0.0005224 s
...
finished tests in 72.08 seconds
---------------------------------------------------------------------------
To avoid having two separate codebases, Python 2.4 compatibility had
to be dropped, so mpmath will require 2.5 or higher from now on.
I'm only aware of one remaining (minor) issue: many doctests won't
pass in Python 3 due to print statements and such in the doctests
themselves. This might obscure some real bugs exercised by the
doctests, of course. Does anyone know if there is a way to run 2to3 on
docstrings to save some trouble? It might be easy enough to fix them
by hand, though.
This is a major enough new feature that we probably should release a
version 0.17 almost immediately. Help testing would be very welcome
(both on Python 3 and on Python 2, to make sure the changes didn't
break anything). I haven't tested with gmpy yet.
Fredrik
Aaron S. Meurer
How do you avoid having two codebases? Do you automatically pass things through 2to3?
>
> I'm only aware of one remaining (minor) issue: many doctests won't
> pass in Python 3 due to print statements and such in the doctests
> themselves. This might obscure some real bugs exercised by the
> doctests, of course. Does anyone know if there is a way to run 2to3 on
> docstrings to save some trouble? It might be easy enough to fix them
> by hand, though.
Maybe you should just replace
>>> print whatever
stuff
with
>>> str(whatever)
stuff
Although I suspect being able to pass doctests through 2to3 would be useful for other reasons too (I don't know if it's possible or not).
Aaron Meurer
Fredrik Johansson
> How do you avoid having two codebases? Do you automatically pass things through 2to3?
After fixing the relative imports, it mostly came down to the following:
* writing print(x) instead of print x
* using list comprehensions instead of map
* inserting trivial aliases xrange = range, long = int, __bool__ =
__nonzero__, etc
Fredrik
Aaron S. Meurer
Aaron Meurer
casevh
On Jan 8, 4:17 pm, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:
gmpy, and with gmpy2. All tests pass successfully.
Performance with Python 3.x was consistently better that with 2.x.
Using gmpy, the improvement is almost 7%. Between 3.x and 2.7, the
difference is 14%. Have you seen similar improvements on other
platforms?
casevh
>
> Fredrik
Fredrik Johansson
> I tested 2.6, 2.7, 3.1, and 3.2 on 64-bit Linux without gmpy, with
> gmpy, and with gmpy2. All tests pass successfully.
Excellent!
> Performance with Python 3.x was consistently better that with 2.x.
> Using gmpy, the improvement is almost 7%. Between 3.x and 2.7, the
> difference is 14%. Have you seen similar improvements on other
> platforms?
Sounds great. I haven't done any profiling yet.
Fredrik
Vinzent Steinberg
Python 3 runs it in 25.35 s, Python 2 in 32.21 s on my machine.
Vinzent
On 9 Jan., 01:17, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:
Vinzent Steinberg
wrote:
>
> Python 3 runs it in 25.35 s, Python 2 in 32.21 s on my machine.
Python 2 needs 28.87 seconds. (Both ran without gmpy.)
Vinzent
Aaron S. Meurer
Aaron Meurer
> --
> You received this message because you are subscribed to the Google Groups "mpmath" group.
> To post to this group, send email to mpm...@googlegroups.com.
> To unsubscribe from this group, send email to mpmath+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mpmath?hl=en.
>
Fredrik Johansson
> Have you tried running the tests in the Python 3.2 release candidate. The final version is due for release in early February.
Not yet.
Fredrik
casevh
On Jan 9, 10:09 am, Fredrik Johansson <fredrik.johans...@gmail.com>
wrote:
>
> > Have you tried running the tests in the Python 3.2 release candidate. The final version is due for release in early February.
>
> Not yet.
>
> Fredrik
of 3.2. I tried some additional tests today and I did find an issue
with 3.2.
In issue 8188, a new unified hash function was added that guarantees
numerical values that compare equally also hash equally.
>>> 2**2000 == mpmath.mpf(1)*2**2000
True
>>> hash(2**2000) == hash(mpmath.mpf(1)*2**2000)
False
>>> hash(2**2000) == hash(gmpy.mpf(1)*2**2000)
True
>>> hash(2**2000) == hash(gmpy2.mpfr(1)*2**2000)
True
A description of the new hash algorithm can be found in:
http://svn.python.org/view/python/branches/py3k/Objects/object.c?view=markup
See also sys.hash_info
I won't have time to work on a patch for several days but I'll produce
one (unless someone beats me to it :) ).
There is another change to hashing in 3.2 that impacts the C API.
Prior to issue 9778, the value for hash on 64-bit Windows was
restricted to 32 bits. A new type (Py_hash_t) was defined that allows
for 64-bit hash values on 64-bit Windows. As long as the values in
sys.hash_info are used, this shouldn't impact Python code.
casevh
casevh
On Jan 9, 10:01 pm, casevh <cas...@gmail.com> wrote:
>
> I won't have time to work on a patch for several days but I'll produce
> one (unless someone beats me to it :) ).
>
need to work on a patch for mpq.
casevh