aleaxit / gmpy Goto Github PK

In pysymbolicext.c, function factor_using_pollard_rho has variables k, l,
c, and i are of type int.  This limits the number of test cycles since int
variables will wrap around to zero when doubling from 2^30 to 2^31 to 2^32.
 Using mpz_t variables corrects the problem.

From http://www.aleax.it/gmpy.html, "Early tests have shown that supporting
Python 2's "in-place operation" functionality (by making MPZ, MPF and MPQ
Python objects mutable) would offer a substantial performance boost."

How much work would it be to add a mutable integer type? E.g. for mpmath,
this could potentially speed up series evaluation, using some strategy like
the following (note that this is fully backwards compatible):

try:
    MUTABLE = gmpy.mutable_mpz
except:
    MUTABLE = gmpy.mpz

def exp(x, prec):
    s = MUTABLE(1<<prec)
    t = MUTABLE(s)
    k = 1
    while t:
        t *= x
        t >>= prec
        t //= k
        s += t
        k += 1
    return gmpy.mpz(s)

(Not as fast as writing the same code in C with mutable GMP numbers, but if
it could speed up Python-implemented algorithms...)

What steps will reproduce the problem?
1. Run program gmpy_test.py in a 64-bit environment.  

Method test_string_keys creates mpz objects from strings and uses them as
dictionary keys.  

Method test_long_keys does the same thing except the strings are cast to
longs when creating the mpz objects.  

Method test_int_keys uses ints (rather than longs or strings).

What is the expected output? What do you see instead?
Output should have only "get ok" and "set ok" lines.  There should not be
any "get error" or "set error" lines.

What version of the product are you using? On what operating system?
gmpy-1.02 on a 64-bit gentoo system

Please provide any additional information below.
Creating mpz objects from strings and longs (with certain values) creates
objects that cause exceptions when used as dictionary keys.  Creating mpz
objects using the same values (cast as ints) works fine.

Attached file gmpy_testv1-02.out shows the output.

Looking at gmpy.c, the hash functions all return longs.  In a 32-bit
environment, ints and longs are both 32 bits wide.  In a 64-bit
environment, ints are 32 bits wide and longs are 64 bits wide.  It seems
that python expects 32 bit ints for hash keys.

Attached patch file patch.64bit.txt changes the return types for the hash
functions from long to int.  Using gmpy built with this patch fixes the key
errors (as shown in attached file gmpy_test.v1-02-fix.out).

gmpy 1.04 (and possibly 1.05) use the functions anynum2mpz, anynum2mpq, and
anynum2mpf to convert to convert arguments to the desired type. This can
generate results such as "mpz(1) + 1.2" returning 2. I'd like to change the
logic as follows:

anyint2mpz replaces anynum2mpz and only converts integer objects to an mpz.
Currently only recognizes int, long, and valid strings.

anyrational2mpq replaces anynum2mpq and converts integer and rational
objects to an mpq. Currently only recognizes int, long, and valid strings.
I will add support for Python 3.x Fraction type.

anyreal2mpf replaces anynum2mpf and converts all number types to an mpf. It
does recognize the Decimal type and I will add support for Fraction.

This will change some exceptions from ValueError to TypeError and break
some mixed-type expressions.

With this logic, mpz + float will generate a TypeError. The alternative
would be to have mpz + float return an mpf. I would rather make such
conversion explicit.

Opinions?

long2mpz becomes faster reading two digits at a time, each digit having
SHIFT=15 digits. 
On a computer with Debian, Pentium M 1.60GHz the tests in mpmath run 1%
faster with this patch.

In gmpy 1.11

>>> print mpq(3,1)
3/1

while in gmpy 1.0.3
>>> print mpq(3,1)
3

Why has this been changed? The latter is shorter and behaves as Fraction
>>> from fractions import Fraction
>>> print Fraction(3,1)
3

and as in Sage
sage: R.<x> = QQ[]
sage: 3*x + 2/3
3*x + 2/3
(not 3/1*x + 2/3)

I would like to suggest to go back to this form, or at least to allow
it setting an environment parameter.

Mario

In the attached patch there is mpz_bitcount, which is an optimized version 
of bit_length which accepts only mpz; in mpmath bitcount has almost always
mpz as argument, so this provides some speedup. Another speedup
comes optimizing input processing in mpmath_normalize.
In issue 94 in http://groups.google.com/group/mpmath-issues
there is a patch to libmpf.py to be used with this patch.
The speedup in runtests is 5% on my Athlon XP 2600.

Importing the decimal module significantly slows down gmpy startup. Can
this be avoided?

The summary says it all.
I'm developing for Sympy which uses gmpy.
I installed gmpy1.14 using 'sudo python setup.py install' on the source.
import gmpy works fine. But as all tests do not pass, some code in sympy uses 
gmpy and crashes with a segmentation fault.

python test/gmpy_test.py returned with 1437 passed and 44 failed.
Although It either hided a segfault or there wasn't any.

What seems to be the problem ?

Did I install GMPY or GMP incorrectly ?

I can't run the gmpy 1.03 installer for Windows Python 2.6. It crashes with
"This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem."

The installer for 2.5 works fine.

OS Name:                   Microsoft Windows XP Professional
OS Version:                5.1.2600 Service Pack 3 Build 2600
OS Configuration:          Standalone Workstation
OS Build Type:             Uniprocessor Free
System Manufacturer:       Hewlett-Packard
System Model:              HP 530 Notebook PC
System type:               X86-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: x86 Family 6 Model 22 Stepping 1
GenuineIntel ~1596 Mhz

qmpy does not work on Python 2.7 in Ubuntu 10.10

What steps will reproduce the problem?

    >>> a = gmpy2.xmpz(0b1000)
    >>> b = a.copy()
    >>> c = a.copy()
    >>> a[1::2] = 1
    >>> b[1::2] = True
    >>> c[1::2] = gmpy2.xmpz(0b11)
    >>> a == b
    False
    >>> a == c
    False
    >>> map(bin, [a, b, c])
    ['0b10', '0b1010', '0b1010']

What is the expected output?

    >>> a = numpy.array([0,0,0,1],dtype=numpy.bool)
    >>> b = a.copy()
    >>> c = a.copy()
    >>> a[1::2] = 1
    >>> b[1::2] = True
    >>> c[1::2] = [1,1]
    >>> all(a == b and all(a == c)
    True
    >>> to_bin = lambda arr: ''.join("01"[d] for d in arr[::-1])
    >>> map(to_bin, [a, b, c])
    ['1010', '1010', '1010']

Or

    >>> a = [0,0,0,1]
    >>> b = a[:]
    >>> c = a[:]
    >>> a[1::2] = 1
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: must assign iterable to extended slice
    >>> b[1::2] = True
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: must assign iterable to extended slice
    >>> c[1::2] = [1,1]
    >>> to_bin(c)
    '1010'

What version of the product are you using? On what operating system?

r312

Please provide any additional information below.

gmpy.mpz(3) + float('inf') will crash.

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import gmpy
>>> gmpy.version()
'1.03'
>>> import pickle
>>> pickle.dumps(gmpy.mpz(3))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python25\lib\pickle.py", line 1366, in dumps
    Pickler(file, protocol).dump(obj)
  File "C:\Python25\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Python25\lib\pickle.py", line 313, in save
    (t.__name__, obj))
pickle.PicklingError: Can't pickle 'mpz' object: mpz(3)

In the attached file there is a patch to optimize a bit _mpmath_normalize
and _mpmath_create.
On my Athlon XP 2600 and Athlon 64 X2 3800 runtests is 1.5 - 2 % faster.

Hi,

I've been using gmpy 1.01 for quite a long time (thanks!). In that version, 
mpq(0.999)+0.1 yields mpq(1099,1000). In gmpy 1.14 (which I just tried out 
now), mpq(0.999)+0.1 yields mpf('1.09900000000000000553e0'), which was 
surprising to me. mpq(0.999)+mpq(0.1) still yields mpq(1099,1000). I tried to 
find the change responsible for this; I can see in changes.txt that there have 
been some alterations to number conversion rules, but I don't see specific 
mention of this one. Did I miss it somewhere?

Thanks!
Chris

Where is the readme or manual ??

What steps will reproduce the problem?

1. svn checkout http://gmpy.googlecode.com/svn/trunk/ gmpy
2. python gmpy/test/gmpy_test_mpf.py

I would expect something ending with 'Test passed' (hopefully) or a report of 
failed tests.

Instead the python interpreter badly fails because of a floating point 
exception *in the 
interpreter*.

% python gmpy/test/gmpy_test_mpf.py
Unit tests for gmpy 1.02 release candidate (mpf functionality)
    running on Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)]

Testing gmpy 1.02 (GMP 4.2.2) with default caching (20, 20, -2..11)
[1]    9923 floating point exception  python gmpy/test/gmpy_test_mpf.py

Then it appears the usual OS window informing that process Python has crashed 
and asking 
whether I want to inform apple.

I'm using 

Mac OS X Leopard 10.5.2
Darwin Kernel Version 9.2.2: Tue Mar  4 21:17:34 PST 2008; root:xnu-
1228.4.31~1/RELEASE_I386 i386

Default Python 2.5
% python --version
Python 2.5.1

gmp 4.2.2 (make checked and working)

gmpy 1.02 RC

The rest of gmpy works (passes all the test excepted the one on mpf).

This is on cygwin using the gmp provided by the cygwin package manager. I
installed gmpy from sources, not a pre-built package.


Unit tests for gmpy 1.03
    on Python 2.5.1 (r251:54863, May 18 2007, 16:56:43) 
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)]
Testing gmpy 1.03 (GMP 4.2.3), default caching (20, 20, -2..11)
gmpy_test_cvr 300 tests, 0 failures
gmpy_test_rnd  26 tests, 0 failures
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpf.py", line ?, in
gmpy_test_mpf.__test__.format
Failed example:
    _g.mpf(3.4)
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpf.__test__.format[19]>", line 1, in <module>
        _g.mpf(3.4)
    ValueError: invalid digits
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpf.py", line ?, in
gmpy_test_mpf.__test__.format
Failed example:
    print _g.mpf(3.4)
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpf.__test__.format[20]>", line 1, in <module>
        print _g.mpf(3.4)
    ValueError: invalid digits
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpf.py", line ?, in
gmpy_test_mpf.__test__.format
Failed example:
    for i in range(11,99):
        assert str(_g.mpf(i/10.0))==str(i/10.0)
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpf.__test__.format[21]>", line 2, in <module>
        assert str(_g.mpf(i/10.0))==str(i/10.0)
    ValueError: invalid digits
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpf.py", line ?, in
gmpy_test_mpf.__test__.format
Failed example:
    _g.fdigits(2.2e5, 0, 6, -10, 10)
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpf.__test__.format[30]>", line 1, in <module>
        _g.fdigits(2.2e5, 0, 6, -10, 10)
    TypeError: argument can not be converted to mpf
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpf.py", line ?, in
gmpy_test_mpf.__test__.format
Failed example:
    _g.digits(_g.mpf(23.45))
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpf.__test__.format[32]>", line 1, in <module>
        _g.digits(_g.mpf(23.45))
    ValueError: invalid digits
**********************************************************************
1 items had failures:
   5 of  34 in gmpy_test_mpf.__test__.format
***Test Failed*** 5 failures.
gmpy_test_mpf 155 tests, 5 failures
**********************************************************************
1 items had failures:
   5 of  34 in gmpy_test_mpf.__test__.format
***Test Failed*** 5 failures.
gmpy_test_mpq 264 tests, 0 failures
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpz.py", line ?, in
gmpy_test_mpz.__test__.number
Failed example:
    f=_g.mpf(3.3)
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpz.__test__.number[65]>", line 1, in <module>
        f=_g.mpf(3.3)
    ValueError: invalid digits
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_mpz.py", line ?, in
gmpy_test_mpz.__test__.number
Failed example:
    f.setprec(-1)
Expected:
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ValueError: n must be >=0
Got:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_mpz.__test__.number[66]>", line 1, in <module>
        f.setprec(-1)
    NameError: name 'f' is not defined
**********************************************************************
2 items had failures:
   5 of  34 in gmpy_test_mpf.__test__.format
   4 of 144 in gmpy_test_mpz.__test__.number
***Test Failed*** 9 failures.
gmpy_test_mpz 402 tests, 4 failures
**********************************************************************
File "/home/somestuff/gmpy/gmpy-1.03/test/gmpy_test_dec.py", line ?, in
gmpy_test_dec.__test__.elemop
Failed example:
    coerce(d, _g.mpf(1.0))
Exception raised:
    Traceback (most recent call last):
      File "/tmp/python.6884/usr/lib/python2.5/doctest.py", line 1212, in __run
        compileflags, 1) in test.globs
      File "<doctest gmpy_test_dec.__test__.elemop[14]>", line 1, in <module>
        coerce(d, _g.mpf(1.0))
    ValueError: invalid digits
**********************************************************************
3 items had failures:
   1 of  15 in gmpy_test_dec.__test__.elemop
   5 of  34 in gmpy_test_mpf.__test__.format
   4 of 144 in gmpy_test_mpz.__test__.number
***Test Failed*** 10 failures.
gmpy_test_dec  16 tests, 1 failures
7 items had no tests:
    gmpy_test_cvr._test
    gmpy_test_dec._test
    gmpy_test_mpf._test
    gmpy_test_mpq._test
    gmpy_test_mpz._memsize
    gmpy_test_mpz._test
    gmpy_test_rnd._test
29 items passed all tests:
   6 tests in gmpy_test_cvr
  22 tests in gmpy_test_cvr.__test__.infinity
  12 tests in gmpy_test_cvr.__test__.misc_stuff
 260 tests in gmpy_test_cvr.__test__.user_errors
   1 tests in gmpy_test_dec
   1 tests in gmpy_test_mpf
  32 tests in gmpy_test_mpf.__test__.binio
  33 tests in gmpy_test_mpf.__test__.cmpr
  49 tests in gmpy_test_mpf.__test__.elemop
   6 tests in gmpy_test_mpf.__test__.newdiv
   2 tests in gmpy_test_mpq
  26 tests in gmpy_test_mpq.__test__.binio
  62 tests in gmpy_test_mpq.__test__.cmpr
  66 tests in gmpy_test_mpq.__test__.elemop
  54 tests in gmpy_test_mpq.__test__.format
  12 tests in gmpy_test_mpq.__test__.newdiv
  18 tests in gmpy_test_mpq.__test__.power
  24 tests in gmpy_test_mpq.__test__.qdiv
   4 tests in gmpy_test_mpz
  36 tests in gmpy_test_mpz.__test__.binio
  62 tests in gmpy_test_mpz.__test__.bitops
  48 tests in gmpy_test_mpz.__test__.cmpr
  42 tests in gmpy_test_mpz.__test__.elemop
  36 tests in gmpy_test_mpz.__test__.format
  14 tests in gmpy_test_mpz.__test__.index
  12 tests in gmpy_test_mpz.__test__.newdiv
   4 tests in gmpy_test_mpz.factorize
   1 tests in gmpy_test_rnd
  25 tests in gmpy_test_rnd.__test__.rand
**********************************************************************
3 items had failures:
   1 of  15 in gmpy_test_dec.__test__.elemop
   5 of  34 in gmpy_test_mpf.__test__.format
   4 of 144 in gmpy_test_mpz.__test__.number
1163 tests in 39 items.
1153 passed and 10 failed.
***Test Failed*** 10 failures.

Hi,

could you please setup a mailinglist for gmpy to discuss the development?

Thanks,
Ondrej

I would like the following functions for scaled integer (i.e. floating
point implementation) operations in gmpy:

man, exp = trim(man, exp, prec=0, rounding='f')
man, exp = add(xman, xexp, yman, yexp, prec=0, rounding='f')
man, exp = div(xman, xexp, yman, yexp, prec, rounding='f')
man, exp = sqrt(man, exp, prec, rounding='f')

These are essentially the same as the internal mpmath functions normalize
(or from_man_exp), mpf_add, mpf_div, mpf_sqrt. However, they don't require
signs as separate components, they don't require handling of infinities,
and they don't require data to be packaged in a specific way (numbers are
passed as direct arguments).

As such I think these functions would be useful even for non-mpmath uses
and could be exposed publicly. Particularly so for trim (which can be used
to round an integer to a given number of bits, or factor an integer into
its odd and power-of-two parts); and add can be used to compute x+y*2^n
without creating a temporary object.

These functions, with the signatures written as above, would be a little
less efficient for mpmath than the functions discussed in issue 22. They
would, however, be a much cleaner fit for gmpy (less dependent on mpmath
specifics). Further (and the reason I'm suggesting this), I'm experimenting
with a different representation in mpmath that should make the functions
with signatures exactly as above just as efficient, and possibly make
mpmath with the gmpy backend even a little bit faster.

What steps will reproduce the problem?
1. Install gmpy on Mac OS 10.5
2. Start Python interpreter
3. import gmpy

What is the expected output? What do you see instead?
I get the following traceback:

Python 2.5.2 |EPD 2.5.2001| (r252:60911, Jul 22 2008, 07:21:23) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gmpy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError:
dlopen(/Library/Frameworks/Python.framework/Versions/2.5.2001/lib/python2.5/site
-packages/gmpy.so,
2): Symbol not found: ___gmp_version
  Referenced from:
/Library/Frameworks/Python.framework/Versions/2.5.2001/lib/python2.5/site-packag
es/gmpy.so
  Expected in: dynamic lookup

What version of the product are you using? On what operating system?
Mac OS 10.5.5, Enthought Python 2.5.2, GMP 4.2.3 ('make check' passed),
gmpy trunk (r38).

Please provide any additional information below.
Same problem with GMP 4.2.2 installed via MacPorts.
Compiling and installing gmpy gave no errors, only the import fails.

In the attached file there is a patch for bit_length; bit_length
is going to be added to Python, see http://bugs.python.org/issue3439

Using in mpmath 
bitcount = gmpy.bit_length
runtests becomes 3% faster on my Pentium 1.6GHz

What steps will reproduce the problem?

Running the attached python program demonstrates gmpy.mpz() producing
incorrect values for integer inputs near 2**32.

Using version 1.0.2 on 64-bit gentoo with AMD64 X2 processor


Old environment:  32-bit gentoo on AMD Athlon XP
New environment:  64-bit gentoo on AMD64 X2

In the old environment, gmpy.mpz() works correctly.  In the new environment
it produces incorrect results for integer values near 2**32, i.e. 4294967296.

Specifically for values from 2**32 - 2 to 2**32 + 9, gmpy.mpz( ) subtracts
2**32 from the value and produces results of -2 to +9.

Integer values below 2**32-2 and above 2**32+9 are processed correctly.

Using longs, rather than ints, produces correct results.

Running the test suite with a fresh Python 3.2.2 install (from CPython's 3.2 
branch) produces the following test failures:

$ python3 gmpy_test.py 
Unit tests for gmpy 1.14
    on Python 3.2.2+ (3.2:9ef20fbd340f, Oct 15 2011, 21:22:07) 
[GCC 4.5.2]
Testing gmpy 1.14 (GMP 5.0.1), default caching (100, 128)
gmpy_test_cvr 148 tests, 0 failures
**********************************************************************
File "/home/antoine/gmpy-1.14/test3/gmpy_test_rnd.py", line ?, in 
gmpy_test_rnd.__test__.rand
Failed example:
    for i in range(3):
        print(float(r('floa')))
Expected:
    0.44833278656
    0.547296524048
    0.895370483398
Got:
    0.4483327865600586
    0.5472965240478516
    0.8953704833984375
**********************************************************************
1 items had failures:
   1 of  25 in gmpy_test_rnd.__test__.rand
***Test Failed*** 1 failures.
gmpy_test_rnd  26 tests, 1 failures
**********************************************************************
1 items had failures:
   1 of  25 in gmpy_test_rnd.__test__.rand
***Test Failed*** 1 failures.
gmpy_test_mpf 340 tests, 0 failures
**********************************************************************
File "/home/antoine/gmpy-1.14/test3/gmpy_test_mpq.py", line ?, in 
gmpy_test_mpq.__test__.power
Failed example:
    print(float(_g.mpf('0.2')**2))
Expected:
    0.04
Got:
    0.039999999999999994
**********************************************************************
2 items had failures:
   2 of  18 in gmpy_test_mpq.__test__.power
   1 of  25 in gmpy_test_rnd.__test__.rand
***Test Failed*** 3 failures.
gmpy_test_mpq 276 tests, 2 failures
**********************************************************************
2 items had failures:
   2 of  18 in gmpy_test_mpq.__test__.power
   1 of  25 in gmpy_test_rnd.__test__.rand
***Test Failed*** 3 failures.
gmpy_test_mpz 690 tests, 0 failures
**********************************************************************
2 items had failures:
   2 of  18 in gmpy_test_mpq.__test__.power
   1 of  25 in gmpy_test_rnd.__test__.rand
***Test Failed*** 3 failures.
gmpy_test_dec  24 tests, 0 failures
7 items had no tests:
    gmpy_test_cvr._test
    gmpy_test_dec._test
    gmpy_test_mpf._test
    gmpy_test_mpq._test
    gmpy_test_mpz._memsize
    gmpy_test_mpz._test
    gmpy_test_rnd._test
33 items passed all tests:
   4 tests in gmpy_test_cvr
  11 tests in gmpy_test_cvr.__test__.infinity
   7 tests in gmpy_test_cvr.__test__.misc_stuff
 126 tests in gmpy_test_cvr.__test__.user_errors
   1 tests in gmpy_test_dec
   8 tests in gmpy_test_dec.__test__.compat
  15 tests in gmpy_test_dec.__test__.elemop
   2 tests in gmpy_test_mpf
  60 tests in gmpy_test_mpf.__test__.binio
  84 tests in gmpy_test_mpf.__test__.cmpr
 116 tests in gmpy_test_mpf.__test__.elemop
  70 tests in gmpy_test_mpf.__test__.format
   8 tests in gmpy_test_mpf.__test__.newdiv
   2 tests in gmpy_test_mpq
  18 tests in gmpy_test_mpq.__test__.binio
  40 tests in gmpy_test_mpq.__test__.cmpr
  30 tests in gmpy_test_mpq.__test__.compat
  90 tests in gmpy_test_mpq.__test__.elemop
  54 tests in gmpy_test_mpq.__test__.format
  24 tests in gmpy_test_mpq.__test__.qdiv
   4 tests in gmpy_test_mpz
  36 tests in gmpy_test_mpz.__test__.binio
  66 tests in gmpy_test_mpz.__test__.bitops
  80 tests in gmpy_test_mpz.__test__.cmpr
  10 tests in gmpy_test_mpz.__test__.divexact
  30 tests in gmpy_test_mpz.__test__.divmod
  88 tests in gmpy_test_mpz.__test__.elemop
  36 tests in gmpy_test_mpz.__test__.format
   4 tests in gmpy_test_mpz.__test__.index
 150 tests in gmpy_test_mpz.__test__.number
 182 tests in gmpy_test_mpz.__test__.special
   4 tests in gmpy_test_mpz.factorize
   1 tests in gmpy_test_rnd
**********************************************************************
2 items had failures:
   2 of  18 in gmpy_test_mpq.__test__.power
   1 of  25 in gmpy_test_rnd.__test__.rand
1504 tests in 42 items.
1501 passed and 3 failed.
***Test Failed*** 3 failures.

Is there a gmpy manual?

Sometimes it is helpful to consider an mpz as a sequence of M n-bit fields. I 
propose to add two methods to pack (unpack) an mpz/xmpz from (to) a length-M 
list consisting of positive number of length n or less.

When packing, an error will be raised if a value in the list is negative or has 
length greater than n. When unpacking, an error will be raised if the initial 
value is negative.

Gmpy has no uploaded files at PyPi.  See 
http://pypi.python.org/pypi/gmpy/1.11rc1.  Because of this, pip install gmpy 
attempts to install gmpy2.  This is causing problems for me using tox to test 
SymPy.  See this thread for more information 
http://lists.idyll.org/pipermail/testing-in-python/2011-June/004127.html.

The fround-function does not seem to do anything:

>> gmpy.fround(gmpy.mpf(1.035),0)
1.03499999999999992006

>> gmpy.version()
1.11

What steps will reproduce the problem?
1. http://dpaste.com/87279/ <- executing that script
2.
3.

What is the expected output? What do you see instead?
I expect the program to calculate the large number, it doesn't

What version of the product are you using? On what operating system?
Svn checkout from about four hours ago x64 ubuntu

In the attached patch there is _mpmath_mpf_mul;
defining in mpmath rev843 in libmpf.py  
gmpy_mpf_mul = gmpy._mpmath_mpf_mul
mpf_mul is 2x faster at mp.dps = 100

In the patch there is also a slight speed-up for _mpmath_create

What steps will reproduce the problem?
1. e = mpz(8)
2. p = e**(e**e)
3. s = str(s)
(this will cause a segfault)
What is the expected output? What do you see instead?
The expected output is a large number

Version details:
sam@sam-laptop:~$ apt-cache showpkg python-gmpy
Package: python-gmpy
Versions: 
1.01.dfsg.1-1
(/var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_hardy_universe_binary-amd
64_Packages)
(/var/lib/dpkg/status)
 Description Language: 
                 File:
/var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_hardy_universe_binary-amd6
4_Packages
                  MD5: 8560c6a67d4864a412cfe666232e460a


Reverse Depends: 
Dependencies: 
1.01.dfsg.1-1 - python-central (2 0.5.8) python (3 2.6) python (2 2.4)
libc6 (2 2.5-5) libgmp3c2 (0 (null)) 
Provides: 
1.01.dfsg.1-1 - python2.5-gmpy python2.4-gmpy 
Reverse Provides: 

What steps will reproduce the problem?
1. download gmpy-1.11rc1.win-amd64-py3.1.exe
2. Run it
3.

What is the expected output? What do you see instead?
Completed installation of gmpy-1.1rcl.
Instead I'm told can't find Python 3.1


What version of the product are you using? On what operating system?
gmpy-1.11rc1.win32-py3.1.exe installed without a problem. 64-bit Vista SP1.



Please provide any additional information below.
PROCESSOR_ARCHITEW6432       AMD64

Converting long -> mpz is extremely slow. Try for example:

from gmpy import mpz
a = 10**500000
b = mpz(a)

A workaround is to use:

c = mpz('%x'%a, 16)

With the attached patch SELF_NO_ARG is faster
                        speedup with a = mpz(10)**16/3
sqrt function           11%
sqrt method             2%

is_square function      8%
is_square method        11%

binary function         12%
binary method           5%

Tests made on HP Pavilion Q8200 2.33GHz

My understanding of the code is that gmpy always coerces a Python int to a
gmpy.mpz instance in a binary operation with gmpy.mpz. I believe avoiding
this (i.e. using custom coercion code and reading the value of a Python int
directly) would lead to significant performance improvements e.g. for some
loops in mpmath where one operand is gmpy.mpz and the other is int. One can
then also avoid constructing a temporary mpz_t by replacing the mpz_op call
with mpz_op_si or mpz_op_ui.

Example operations:

x += 1
x >>= 1
x *= 2
x //= 2

Executing the above sequence, with x = mpz(3<<53), if the right hand sides
are replaced by precomputed mpz instances (bypassing coercion), I get a
1.3x speedup and 1.9x speedup with psyco.

root@wombat:/usr/local/src/gmpy-1.02/test# uname -a
Linux wombat 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64
GNU/Linux

root@wombat:/usr/local/src/gmpy-1.02/test# python gmpy_test.py
Unit tests for gmpy 1.02 release candidate
    on Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:12:50)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)]
Testing gmpy 1.02 (GMP 4.2.1), default caching (20, 20, -2..11)
gmpy_test_cvr 270 tests, 0 failures
gmpy_test_rnd  26 tests, 0 failures
gmpy_test_mpf 155 tests, 0 failures
gmpy_test_mpq 264 tests, 0 failures
**********************************************************************
File "/usr/local/src/gmpy-1.02/test/gmpy_test_mpz.py", line ?, in
gmpy_test_mpz.__test__.binio
Failed example:
    hash(z)
Expected:
    -791330233
Got:
    1634524889
**********************************************************************
File "/usr/local/src/gmpy-1.02/test/gmpy_test_mpz.py", line ?, in
gmpy_test_mpz.__test__.index
Failed example:
    ix(_g.mpz(sys.maxint)) == sys.maxint
Expected:
    True
Got:
    False
**********************************************************************
2 items had failures:
   2 of  34 in gmpy_test_mpz.__test__.binio
   1 of  14 in gmpy_test_mpz.__test__.index
***Test Failed*** 3 failures.
gmpy_test_mpz 400 tests, 3 failures
********************************************************************************
***************************************
2 items had failures:
   2 of  34 in gmpy_test_mpz.__test__.binio
   1 of  14 in gmpy_test_mpz.__test__.index
***Test Failed*** 3 failures.
gmpy_test_dec  16 tests, 0 failures
7 items had no tests:
    gmpy_test_cvr._test
    gmpy_test_dec._test
    gmpy_test_mpf._test
    gmpy_test_mpq._test
    gmpy_test_mpz._memsize
    gmpy_test_mpz._test
    gmpy_test_rnd._test
29 items passed all tests:
   6 tests in gmpy_test_cvr
  12 tests in gmpy_test_cvr.__test__.misc_stuff
 252 tests in gmpy_test_cvr.__test__.user_errors
   1 tests in gmpy_test_dec
  15 tests in gmpy_test_dec.__test__.elemop
   1 tests in gmpy_test_mpf
  32 tests in gmpy_test_mpf.__test__.binio
  33 tests in gmpy_test_mpf.__test__.cmpr
  49 tests in gmpy_test_mpf.__test__.elemop
  34 tests in gmpy_test_mpf.__test__.format
   6 tests in gmpy_test_mpf.__test__.newdiv
   2 tests in gmpy_test_mpq
  26 tests in gmpy_test_mpq.__test__.binio
  62 tests in gmpy_test_mpq.__test__.cmpr
  66 tests in gmpy_test_mpq.__test__.elemop
  54 tests in gmpy_test_mpq.__test__.format
  12 tests in gmpy_test_mpq.__test__.newdiv
  18 tests in gmpy_test_mpq.__test__.power
  24 tests in gmpy_test_mpq.__test__.qdiv
   4 tests in gmpy_test_mpz  62 tests in gmpy_test_mpz.__test__.bitops
  48 tests in gmpy_test_mpz.__test__.cmpr
  42 tests in gmpy_test_mpz.__test__.elemop
  36 tests in gmpy_test_mpz.__test__.format
  12 tests in gmpy_test_mpz.__test__.newdiv
 144 tests in gmpy_test_mpz.__test__.number
   4 tests in gmpy_test_mpz.factorize
   1 tests in gmpy_test_rnd
  25 tests in gmpy_test_rnd.__test__.rand
**********************************************************************
2 items had failures:
   2 of  34 in gmpy_test_mpz.__test__.binio
   1 of  14 in gmpy_test_mpz.__test__.index 
1131 tests in 38 items.
1128 passed and 3 failed.
***Test Failed*** 3 failures.

In gmpy.c the line:

#elsestatic PyTypeObject Pympz_Type;

should be:

#else
static PyTypeObject Pympz_Type;

          Brian

Reported by Fredrik in comments on Issue 33.

mpz(3) > 1e1000 causes a segfault.

What steps will reproduce the problem?
1. The docs say it does 
2. I don't know how to verify? (yea I know dumb but this is a dependency I'm 
trying to track down...)
3. I appreciate all the work that goes into answering dumb questions like this!

What is the expected output? What do you see instead?
Trying to use the Pyspread spreadsheet project on a win 64 (vista) machine 
using win 32 binaries for all components


What version of the product are you using? On what operating system?


Please provide any additional information below.

gmpy comparisons raise a TypeError when coercion fails.

>>> gmpy.mpz(1) == None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercion to gmpy.mpz type failed

Another example:

>>> [gmpy.mpz(4), None].count(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: coercion to gmpy.mpz type failed

Is it a good idea to use Cython for the wrappers? I think it'd be much
easier to maintain it, than hand written wrappers. Just a thought.

>>> gmpy.mpz(11) == 11.0
False
>>> 11 == 11.0
True

This bug exists in gmpy 1.04. I think gmpy should follow the Python
conventions whenever possible.

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from gmpy import mpz
>>> mpz(1.721116539913617e-052)

crashes Python.

try: gmpy.mpq(u"1")

raises an exception:
"TypeError: gmpy.mpq() expects numeric or string argument"

Similar for gmpy.mpf(u"1")

The argument should be casted to ascii.

PyPy 1.3 has (alpha) support for CPython extension modules. It would be nice if 
gmpy ran in PyPy.

  I have some serious memory issues in my sagemath
Mandriva package due to interaction of gmpy and sage
with gmp memory functions, and mpmath.

  I do not understand very well the machinery of python
modules, but, python-mpmath has this code:

if 'MPMATH_NOGMPY' not in os.environ:
    try:
        try:
            import gmpy2 as gmpy
        except ImportError:
            try:
                import gmpy
            except ImportError:
                raise ImportError
        if gmpy.version() >= '1.03':
            BACKEND = 'gmpy'
            MPZ = gmpy.mpz
    except:
        pass

if 'MPMATH_NOSAGE' not in os.environ:
    try:
        import sage.all
        import sage.libs.mpmath.utils as _sage_utils
        sage = sage.all
        sage_utils = _sage_utils
        BACKEND = 'sage'
        MPZ = sage.Integer
    except:
        pass

  The problem is that the "try" to load gmpy end up
calling mp_set_memory_functions, and it causes memory
corruption with sagemath.

  Not sure what should be done as deferring the call to
mp_set_memory_functions would still possibly cause problems
if gmpy is really used. But my suggestion is, if doing pretty
much only wrapping for the sake of wrapping, just keep the
default malloc/realloc/free fallbacks.

  Same would apply to sagemath, that just wraps
malloc/realloc/free with a sig_off/sig_on interface to
"defer" handling of signals after a memory function returned.

  Setting MPMATH_NOGMPY does not help, and only option to
have sagemath working is to uninstall the python-gmpy package.

gmpy 1.04:

>>> from gmpy import mpz
>>> mpz(1) << 10**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Pympz_lshift outrageous shift count

Python 2.6:

>>> 1 << 10**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

Python 3.0:

>>> 1 << 10**20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long


I think gmpy should raise an OverflowError here for compatibility. It could
copy the message from Python 3.0 too.

a = 0
total = gmpy.mpq(a)
print 'total ', total
>> total  0

a = gmpy.qbinary(total)
print 'a = ', gmpy.mpq(a,256)
>> a =  88

a = total.binary()
print 'a = ', gmpy.mpq(a,256)
>> a =  176

Platform: Windows XP, SP3
Python 2.5
gmpy-1.04.win32-py2.5.exe

What steps will reproduce the problem?

1. svn checkout http://gmpy.googlecode.com/svn/trunk/ gmpy
2. python gmpy/test/gmpy_test_mpf.py

I would expect something ending with 'Test passed' (hopefully) or a report of 
failed tests.

Instead the python interpreter badly fails because of a floating point 
exception *in the 
interpreter*.

% python gmpy/test/gmpy_test_mpf.py
Unit tests for gmpy 1.02 release candidate (mpf functionality)
    running on Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)]

Testing gmpy 1.02 (GMP 4.2.2) with default caching (20, 20, -2..11)
[1]    9923 floating point exception  python gmpy/test/gmpy_test_mpf.py

Then it appears the usual OS window informing that process Python has crashed 
and asking 
whether I want to inform apple.

I'm using 

Mac OS X Leopard 10.5.2
Darwin Kernel Version 9.2.2: Tue Mar  4 21:17:34 PST 2008; root:xnu-
1228.4.31~1/RELEASE_I386 i386

Default Python 2.5
% python --version
Python 2.5.1

gmp 4.2.2 (make checked and working)

gmpy 1.02 RC

The rest of gmpy works (passes all the test excepted the one on mpf).