gmpy 1.01 rc near... anybody wanna test>

I have fixed almost all of the outstanding bugreports and feature
request for gmpy: divm doesn't leak memory any more, truediv and
floordiv are implemented for all types, etc -- in the current CVS
version (one thing I must still look at is divm's behavior when its args
are not mutually prime). It currently compiles w/o warnings, and passes
all of its 1040+ tests, w/the current release of GMP (4.1.4), Python
(2.4.2), MacOSX (10.4.3), XCode (2.1), gcc (4.0).\\

gmpy users able to download and build from sourceforge's cvs are
encouraged to test the current CVS version. This is a great time to
send me any bug reports or (minor;-) feature requests, since I hope to
release a "1.01 release candidate" of gmpy ASAP. I'm currently unable
to build any Windows version -- any volunteer for THAT task is doubly
welcome;-).


Thanks,

Alex

re: gmpy 1.01 rc near... anybody wanna test>

I downloaded and tried the CVS version. Division still didn't work as
expected.
[color=blue][color=green][color=darkred]
>>> import gmpy
>>> gmpy.version()[/color][/color][/color]
'1.01'[color=blue][color=green][color=darkred]
>>> gmpy.mpz(9)//gmpy.mpz(4)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for //: 'mpz' and 'mpz'[color=blue][color=green][color=darkred]
>>> from __future__ import division
>>> gmpy.mpz(9)//gmpy.mpz(4)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for //: 'mpz' and 'mpz'[color=blue][color=green][color=darkred]
>>> gmpy.mpz(9)/gmpy.mpz(4)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for /: 'mpz' and 'mpz'[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Platform: Solaris 10 x86, SunStudio compiler, GMP 4.1.4, Python 2.4.2

re: gmpy 1.01 rc near... anybody wanna test>

Alex Martelli wrote:[color=blue]
> I have fixed almost all of the outstanding bugreports and feature
> request for gmpy: divm doesn't leak memory any more, truediv and
> floordiv are implemented for all types, etc -- in the current CVS
> version (one thing I must still look at is divm's behavior when its args
> are not mutually prime). It currently compiles w/o warnings, and passes
> all of its 1040+ tests, w/the current release of GMP (4.1.4), Python
> (2.4.2), MacOSX (10.4.3), XCode (2.1), gcc (4.0).\\
>
> gmpy users able to download and build from sourceforge's cvs are
> encouraged to test the current CVS version. This is a great time to
> send me any bug reports or (minor;-) feature requests, since I hope to
> release a "1.01 release candidate" of gmpy ASAP. I'm currently unable
> to build any Windows version -- any volunteer for THAT task is doubly
> welcome;-).
>[/color]
I tried compiling it with the MS free toolkit but the C compile
complains about the absence of "gmp.h". Since I see such a header in my
Cygwin installation I presume it's something that a full VC7
installation could expect to be present.

Unfortunately modifying the build to use the Cygwin include directory
gave errors, I suspect because other Cygwin headers were also being
picked up in error (I just added /cygwin/usr/include to include_dirs.

Compilation ran to completion with the header files from both Cygwin and
the GNU gmp-static library, but then of course in both cases I was
missing the gmp library to link it against.

So I'm afraid you might need someone with access to VC to test this on
Windows for you, sorry.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

re: gmpy 1.01 rc near... anybody wanna test>

aleax@mail.comcast.net (Alex Martelli) writes:[color=blue]
> gmpy users able to download and build from sourceforge's cvs are
> encouraged to test the current CVS version.[/color]

Oh cool, I wondered whether any gmpy maintenance was still going on.
I'll see if I can give the new version a try.

re: gmpy 1.01 rc near... anybody wanna test>

Steve Holden <steve@holdenweb.com> wrote:
...[color=blue]
> I tried compiling it with the MS free toolkit but the C compile
> complains about the absence of "gmp.h". Since I see such a header in my
> Cygwin installation I presume it's something that a full VC7
> installation could expect to be present.[/color]

gmp.h is the header of GMP, the GNU library that gmpy wraps. It appears
to be preinstalled on Cygwin, from what you mention, but I'm pretty sure
Microsoft doesn't preinstall GPL-covered libraries from GNU with THEIR
stuff... a suitable Windows version need to be procured and installed in
some other way (having no Windows around I'm hard put to suggest what is
the best way to do this these days).
[color=blue]
> So I'm afraid you might need someone with access to VC to test this on
> Windows for you, sorry.[/color]

Tx for the attempt, but I don't think VC per se will suffice -- somebody
needs to build or find a suitable version of GMP for Windows, too.


Alex

re: gmpy 1.01 rc near... anybody wanna test>

<casevh@comcast.net> wrote:
[color=blue]
> I downloaded and tried the CVS version. Division still didn't work as
> expected.[/color]

Now that's truly interesting...
[color=blue][color=green][color=darkred]
> >>> import gmpy
> >>> gmpy.version()[/color][/color]
> '1.01'[color=green][color=darkred]
> >>> gmpy.mpz(9)//gmpy.mpz(4)[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: unsupported operand type(s) for //: 'mpz' and 'mpz'[/color]

while, on my machine:

Helen:~/gmpy/test alex$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> import gmpy
>>> gmpy.mpz(9)//gmpy.mpz(4)[/color][/color][/color]
mpz(2)[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

etc, etc.

The CVS commit which I did before the post you're replying to gave me:

....
Checking in src/gmpy.c;
/cvsroot/gmpy/gmpy/src/gmpy.c,v <-- gmpy.c
new revision: 1.14; previous revision: 1.13
done
Mailing gmpy-commits@lists.sourceforge.net...
Generating notification message...
Generating notification message... done.

and the logfile should be...:


Helen:~/gmpy alex$ cvs log src/gmpy.c | head -20
aleax@cvs.sourceforge.net's password:

RCS file: /cvsroot/gmpy/gmpy/src/gmpy.c,v
Working file: src/gmpy.c
head: 1.14
branch:
locks: strict
access list:
symbolic names:
import_release: 1.1.1.1
import_vendor: 1.1.1
keyword substitution: kv
total revisions: 15; selected revisions: 15
description:
----------------------------
revision 1.14
date: 2005/11/07 05:29:24; author: aleax; state: Exp; lines: +83 -2

Add floordiv and truediv implementations to mpz, mpq, mpf (unittests
still need to be added).
----------------------------
revision 1.13
....


Unfortunately, I didn't have a CVS $Id$ in gmpy.c (silly me!) so
checking that you have the right version was hard. I have now added it,
and an accessor to it from Python:

Helen:~/gmpy/test alex$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> import gmpy
>>> gmpy._cvsid()[/color][/color][/color]
'$Id: gmpy.c,v 1.15 2005/11/07 15:43:24 aleax Exp $'[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Can you cvs update again and check what's going on? Thanks!


Alex

re: gmpy 1.01 rc near... anybody wanna test>

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
[color=blue]
> aleax@mail.comcast.net (Alex Martelli) writes:[color=green]
> > gmpy users able to download and build from sourceforge's cvs are
> > encouraged to test the current CVS version.[/color]
>
> Oh cool, I wondered whether any gmpy maintenance was still going on.[/color]

Only when I get guilt-tripped into working a bit on it;-). gmpy as it
stands mostly meets my modest personal needs, but I'd still like to keep
it useful to others, too, of course.
[color=blue]
> I'll see if I can give the new version a try.[/color]

Thanks. The floordiv and truediv still need tests, and there's a
mysterious report of them not working at all (which I suspect is due to
a cvs update somehow going awry -- I've now added a gmpy._cvsid()
accessor to return the CVS $Id$ string to facilitate checking for such
issues); divm shouldn't leak memory any more, but still fails when
arguments aren't mutually prime (haven't looked into that yet). I will
be working on these issues presently.

I haven't even looked at what's new in GMP 4.1.4 to see if there's
anything there which I should wrap in gmpy (or use to reimplement some
of gmpy's existing functionality in a more optimized way...). I'm open
to suggestions for any such minor features or optimizations, although my
main goal for 1.01 is to remove bugs and leaks -- any _major_ new
feature will have to wait for a future 1.1 or whatever...

Current gmpy's biggest single issue right now is that I can't build it
on Windows, having no Windows machine, and even less any GMP 4.1.4 for
Windows...


Alex

re: gmpy 1.01 rc near... anybody wanna test>

Alex Martelli wrote:[color=blue]
> Steve Holden <steve@holdenweb.com> wrote:
> ...
>[color=green]
>>I tried compiling it with the MS free toolkit but the C compile
>>complains about the absence of "gmp.h". Since I see such a header in my
>>Cygwin installation I presume it's something that a full VC7
>>installation could expect to be present.[/color]
>
>
> gmp.h is the header of GMP, the GNU library that gmpy wraps. It appears
> to be preinstalled on Cygwin, from what you mention, but I'm pretty sure
> Microsoft doesn't preinstall GPL-covered libraries from GNU with THEIR
> stuff... a suitable Windows version need to be procured and installed in
> some other way (having no Windows around I'm hard put to suggest what is
> the best way to do this these days).
>
>[color=green]
>>So I'm afraid you might need someone with access to VC to test this on
>>Windows for you, sorry.[/color]
>
>
> Tx for the attempt, but I don't think VC per se will suffice -- somebody
> needs to build or find a suitable version of GMP for Windows, too.
>
>[/color]
Yes indeed. I took a look at the gmplib source distro, but it would mean
installing way too much other stuff to be practical right now,
unfortunately.

As a consolation prize you might like to know that it appears to build
and pass all tests happily under Cygwin. Sorry I can't be more help.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

re: gmpy 1.01 rc near... anybody wanna test>

Everything works fine with v1.16. I'm sure I was doing something wrong.
I shouldn't be testing that late at night. ;-)

It looks like the warning about "tp_compare" has been fixed.

I will try to build a version for Windows, but that may take me a day
or two.

Thanks for the updates to gmpy!

Case

re: gmpy 1.01 rc near... anybody wanna test>

<casevh@comcast.net> wrote:
[color=blue]
> Everything works fine with v1.16. I'm sure I was doing something wrong.
> I shouldn't be testing that late at night. ;-)
>
> It looks like the warning about "tp_compare" has been fixed.[/color]

I didn't touch tp_compare specifically, so the fix must have been a side
effect (?).
[color=blue]
>
> I will try to build a version for Windows, but that may take me a day
> or two.[/color]

Great, pls let me know when you do (particularly if you're willing to
make your build available to others -- if you send it to me I can make
it downloadable from sourceforge).

[color=blue]
> Thanks for the updates to gmpy![/color]

You're welcome, and thank YOU for the feedback &c.


Alex

re: gmpy 1.01 rc near... anybody wanna test>

Alex Martelli wrote:[color=blue]
> <casevh@comcast.net> wrote:
>[color=green]
> > Everything works fine with v1.16. I'm sure I was doing something wrong.
> > I shouldn't be testing that late at night. ;-)
> >
> > It looks like the warning about "tp_compare" has been fixed.[/color]
>
> I didn't touch tp_compare specifically, so the fix must have been a side
> effect (?).
>[color=green]
> >
> > I will try to build a version for Windows, but that may take me a day
> > or two.[/color]
>
> Great, pls let me know when you do (particularly if you're willing to
> make your build available to others -- if you send it to me I can make
> it downloadable from sourceforge).
>
>[color=green]
> > Thanks for the updates to gmpy![/color]
>
> You're welcome, and thank YOU for the feedback &c.
>
>
> Alex[/color]
I made a successful installer for Windows using Mingw32 and Python 2.4.
I needed to edit setup.py to list gmp as a required library.

if sys.version.find('MSC')==-1:
gmpy_ext = Extension('gmpy', sources=['src/gmpy.c'],
# library_dirs=['/usr/local/lib'],
libraries=['gmp'])
else:
gmpy_ext = Extension('gmpy', sources=['src/gmpy.c'],
include_dirs=['./src'],
libraries=['gmp']) # I added libraries!

Will you be updating the information in setup.py file?

Tomorrow, I'll recreate my build process on another computer. I am
willing to create Windows installers.

Which versions of Python do you want to support?

Do you want versions that include GMP tailored for specific processors?


With GMP 4.1.4 compiled for pentium3, and running on a 1.8Ghz Pentium
M, I'm able to calculate the decimal form of 2^25964951 (the 43rd
Mersenne prime) in 10 seconds. The prior gmpy release takes just over
14 seconds. Without gmpy, Python takes 25.4 seconds. On an Athlon
MP2800+ (2.133Ghz) with GMP compiled for that processor, I can do it in
6.6 seconds using gmpy and 22.4 seconds without gmpy. I'm working with
blocks of 1000 digits and using a combination of Toom-Cook and
Nussbaumer convolution to perform the multiplies and squares.

I did very that the tp_compare errors are fixed. I removed the warnings
filter in my code and the warning did occur with the old gmpy but did
not occur with my version.

Case

re: gmpy 1.01 rc near... anybody wanna test>

<casevh@comcast.net> wrote:
...[color=blue]
> I made a successful installer for Windows using Mingw32 and Python 2.4.[/color]

Great, thanks.
[color=blue]
> I needed to edit setup.py to list gmp as a required library.
>
> if sys.version.find('MSC')==-1:
> gmpy_ext = Extension('gmpy', sources=['src/gmpy.c'],
> # library_dirs=['/usr/local/lib'],
> libraries=['gmp'])
> else:
> gmpy_ext = Extension('gmpy', sources=['src/gmpy.c'],
> include_dirs=['./src'],
> libraries=['gmp']) # I added libraries!
>
> Will you be updating the information in setup.py file?[/color]

Done, in the current CVS version.
[color=blue]
> Tomorrow, I'll recreate my build process on another computer. I am
> willing to create Windows installers.[/color]

Wonderful!
[color=blue]
> Which versions of Python do you want to support?[/color]

I have tested gmpy with 2.3 and 2.4 on Mac, and those two and also 2.2
on Linux. I think supporting 2.2 with a Windows download is probably
unneeded, but 2.4 is a must and I suspect 2.3 would be nice...
[color=blue]
> Do you want versions that include GMP tailored for specific processors?[/color]

My gut reaction here is that people with special processors, Windows,
and demanding performance needs should probably get their own
development environments and build GMP and gmpy accordingly.

Any opinions from the public on this one...?
[color=blue]
> With GMP 4.1.4 compiled for pentium3, and running on a 1.8Ghz Pentium
> M, I'm able to calculate the decimal form of 2^25964951 (the 43rd
> Mersenne prime) in 10 seconds. The prior gmpy release takes just over
> 14 seconds. Without gmpy, Python takes 25.4 seconds. On an Athlon
> MP2800+ (2.133Ghz) with GMP compiled for that processor, I can do it in
> 6.6 seconds using gmpy and 22.4 seconds without gmpy. I'm working with
> blocks of 1000 digits and using a combination of Toom-Cook and
> Nussbaumer convolution to perform the multiplies and squares.[/color]

Sounds quite decent -- about a 2.5 to 3+ times speedup wrt Python, and
some speedup wrt gmpy 1.0 (all GMP's merit -- I didn't address
performance aspects at all in this delta). Just out of curiosity: what
performance do you get on the Athlon with a pentium3-compiled GMP?

[color=blue]
> I did very that the tp_compare errors are fixed. I removed the warnings
> filter in my code and the warning did occur with the old gmpy but did
> not occur with my version.[/color]

Excellent. Sounds like an "all systems go"...!-)


Thanks,

Alex

re: gmpy 1.01 rc near... anybody wanna test>

> > Will you be updating the information in setup.py file?[color=blue]
>
> Done, in the current CVS version.[/color]

I will grab the CVS version and create installers.
[color=blue][color=green]
> > Which versions of Python do you want to support?[/color]
>
> I have tested gmpy with 2.3 and 2.4 on Mac, and those two and also 2.2
> on Linux. I think supporting 2.2 with a Windows download is probably
> unneeded, but 2.4 is a must and I suspect 2.3 would be nice...[/color]

I will definately build for 2.3 and 2.4.
[color=blue]
>[color=green]
> > Do you want versions that include GMP tailored for specific processors?[/color]
>
> My gut reaction here is that people with special processors, Windows,
> and demanding performance needs should probably get their own
> development environments and build GMP and gmpy accordingly.
>
> Any opinions from the public on this one...?[/color]

Unless there is a demand for compatibilty with older processors
(Pentium, Pentium Pro, Pentium II), I will build for Pentium 3.
[color=blue]
>[color=green]
> > With GMP 4.1.4 compiled for pentium3, and running on a 1.8Ghz Pentium
> > M, I'm able to calculate the decimal form of 2^25964951 (the 43rd
> > Mersenne prime) in 10 seconds. The prior gmpy release takes just over
> > 14 seconds. Without gmpy, Python takes 25.4 seconds. On an Athlon
> > MP2800+ (2.133Ghz) with GMP compiled for that processor, I can do it in
> > 6.6 seconds using gmpy and 22.4 seconds without gmpy. I'm working with
> > blocks of 1000 digits and using a combination of Toom-Cook and
> > Nussbaumer convolution to perform the multiplies and squares.[/color]
>
> Sounds quite decent -- about a 2.5 to 3+ times speedup wrt Python, and
> some speedup wrt gmpy 1.0 (all GMP's merit -- I didn't address
> performance aspects at all in this delta). Just out of curiosity: what
> performance do you get on the Athlon with a pentium3-compiled GMP?
>[/color]
I'll try to find out. Unfortunately, my Athlon box won't run Windows.
;-)
[color=blue]
> Thanks,
>
> Alex[/color]

You're welcome,

Case

re: gmpy 1.01 rc near... anybody wanna test>

I tested gmpy cvs as of now on Debian/testing/x86 with python2.3. It
compiled perfectly, ran all of its unit tests and also all my test
programs - Well done!

My test program seemed to run at the same speed with both versions
(not suprising really since both are using the same libgmp.so on the
system).

Thanks and look forward to the release

Nick
--
Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick

re: gmpy 1.01 rc near... anybody wanna test>

Nick Craig-Wood <nick@craig-wood.com> wrote:
[color=blue]
> I tested gmpy cvs as of now on Debian/testing/x86 with python2.3. It
> compiled perfectly, ran all of its unit tests and also all my test
> programs - Well done![/color]

Thanks!
[color=blue]
> My test program seemed to run at the same speed with both versions
> (not suprising really since both are using the same libgmp.so on the
> system).[/color]

Yep, as I said any speed differences should be due to the underlying
GMP, since gmpy.c itself has not undergone any speed-related change.

[color=blue]
> Thanks and look forward to the release[/color]

Thank YOU for the feedback!


Alex

re: gmpy 1.01 rc near... anybody wanna test>

I've created Windows binaries for Python 2.3 and 2.4. It should be
compatible with PentiumPro or later processors.

They can be found at http://home.comcast.net/~casevh/

Case

re: gmpy 1.01 rc near... anybody wanna test>

<casevh@comcast.net> wrote:
[color=blue]
> I've created Windows binaries for Python 2.3 and 2.4. It should be
> compatible with PentiumPro or later processors.[/color]

Thanks! I hope to package up a release early next week, and to include
these.


Alex

re: gmpy 1.01 rc near... anybody wanna test>

Alex Martelli wrote:[color=blue]
> <casevh@comcast.net> wrote:
>[color=green]
> > I've created Windows binaries for Python 2.3 and 2.4. It should be
> > compatible with PentiumPro or later processors.[/color]
>
> Thanks! I hope to package up a release early next week, and to include
> these.
>
>
> Alex[/color]

I downloaded the binaries and ran some Big Arithmetic tests:


First, I wanted to see how version 1.0 handled the test which
is a typical problem for which I use gmpy. A Type [1,2] Mersenne
Hailstone is an object I encounter in my Collatz Conjecture
research. There are an infinite number of them. Every 9th (starting
from the 5th) generation 1 hailstone is a generation 2 hailstone.
Every 9th (starting from the 5th) generation 2 hailstone is a
generation 3 hailstone, etc.

In this case, a closed form equation can be used to directly find
the ith member of the kth generation. But not all hailstone types
have closed form equations. For those, I use a recursive function
that uses divm().

The test makes three passes. The first is a brute force search
through every Mesenne Number from 1 to 177150 bits. A test
determines what generation each is (most are not Type [1,2] and
evaluate to generation 0). The test prints the first occurrence of
each generation.

The second pass uses the closed form equation to directly
calculate the 1st member of each generation. These results must
match those found in the brute force search.

Finally, the third pass takes each hailstone found in the second
pass, calculates it's absolute offset from the first general
Type [1,2] hailstone of the corresponding generation, and calls
the recursive function to see if it calculates the same hailstone
found in pass 2 and pass 1.

==========================================

gmpy.version: 1.0 (with divm() replaced by invert())

Brute force search: gclass(2**i-1,xyz)
Find 1st Generation k Type [1,2] Mersenne Hailstone

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5

7.031 seconds

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7

0.657 seconds

Verify Type12MH Hailstones:
Find ith, kth Generation Type (xyz) Hailstone
using the recursive equation

(gmpy.divm(y**(k-1)-prev_gen[2],y-x,y**(k-1))/y**(k-2))*y**(k-1)+prev_gen[3]

where i=((hailstone-geni(k,1,xyz))/(y**k))+1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7

0.078 seconds

==========================================
NOTE: Brute force search could not reach generation 6 without
locking up

Switching to gmpy version 1.01
==========================================

gmpy.version: 1.01 (now using divm())

Brute force search: gclass(2**i-1,xyz)
Find 1st Generation k Type [1,2] Mersenne Hailstone

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5

0.579 seconds

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7

0 seconds

Verify Type12MH Hailstones:
Find ith, kth Generation Type (xyz) Hailstone
using the recursive equation

(gmpy.divm(y**(k-1)-prev_gen[2],y-x,y**(k-1))/y**(k-2))*y**(k-1)+prev_gen[3]

where i=((hailstone-geni(k,1,xyz))/(y**k))+1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7

0.015 seconds

==========================================
NOTE: Wow, what an improvement!
How far can I go now?
==========================================

gmpy.version: 1.01

Brute force search: gclass(2**i-1,xyz)
Find 1st Generation k Type [1,2] Mersenne Hailstone

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6

31.92 seconds

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9

0.234 seconds

Verify Type12MH Hailstones:
Find ith, kth Generation Type (xyz) Hailstone
using the recursive equation

(gmpy.divm(y**(k-1)-prev_gen[2],y-x,y**(k-1))/y**(k-2))*y**(k-1)+prev_gen[3]

where i=((hailstone-geni(k,1,xyz))/(y**k))+1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9

8.766 seconds

==========================================
NOTE: Brute force can now reach generation 6, but won't try
anything higher.
Generation 9 is a 129 million bit number!
Can we get to generation 10?
==========================================

gmpy.version: 1.01

Brute force search: gclass(2**i-1,xyz)
Find 1st Generation k Type [1,2] Mersenne Hailstone

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6

32.14 seconds

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9
2**1162261469-1 generation:10

51.83 seconds

Verify Type12MH Hailstones:
Find ith, kth Generation Type (xyz) Hailstone
using the recursive equation

(gmpy.divm(y**(k-1)-prev_gen[2],y-x,y**(k-1))/y**(k-2))*y**(k-1)+prev_gen[3]

where i=((hailstone-geni(k,1,xyz))/(y**k))+1

2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9
Traceback (most recent call last):
File "C:\Python23\user\gmpy ver 1.01\MHtest.py", line 64, in ?
i = (h-a0)/(xyz[1]**g)

==========================================
NOTE: No, ran out of virtual memory. Probably due to the
recursion and having to store the pass 2 numbers.

I used to have a sign in my lab saying
"Test to Destruction"
But the paranoid schizophrenic field engineer
got freaked out by it and the boss made me
take it down.
==========================================


Excellent work guys!

Not only is the divm() bug fixed but it looks like we got a
significant performance increase.

re: gmpy 1.01 rc near... anybody wanna test>

What processor are you running?

I only have Windows running on an old Pentium 3. It is easy for me to
build a version that will running on almost any recent processor. I'm
willing to try and override the CPU detection and make a processor
specific build for you. I won't be able to test it, though.

Thanks for the testing!

Case

re: gmpy 1.01 rc near... anybody wanna test>

David Gutierrez <davegu1@hotmail.com> wrote:
[color=blue]
> Include me in your list, please.[/color]

Uh, what list? If you mean gmpy-commits, you subscribe to it on
gmpy.sf.net -- if you mean the general Python list, on www.python.org.


Alex

re: gmpy 1.01 rc near... anybody wanna test>

mensanator@aol.com <mensanator@aol.com> wrote:
...[color=blue]
> Excellent work guys!
>
> Not only is the divm() bug fixed but it looks like we got a
> significant performance increase.[/color]

Thanks!

Alex

re: gmpy 1.01 rc near... anybody wanna test>

casevh@comcast.net wrote:[color=blue]
> What processor are you running?[/color]

Drat, didn't see this before I left work. I'm fairly certain it was a
Pentium 4, definitely 1.7GHz, Win2000 and Python 2.3.

So I thought I would run the test again on my home computers,
a Pentium 4 1.5 GHz WinXP Python 2.3 and a laptop with a
Celeron 2.8 GHz WinXP Python 2.4.

Here are the Celeron/Python2.4 numbers (and original test times)

BF: 27.89 sec gen6 (31.92)
CF: 0.203 sec gen9 (0.234)
V: 5.062 sec gen9 (8.766)
[color=blue]
>
> I only have Windows running on an old Pentium 3. It is easy for me to
> build a version that will running on almost any recent processor. I'm
> willing to try and override the CPU detection and make a processor
> specific build for you. I won't be able to test it, though.
>
> Thanks for the testing!
>
> Case[/color]

re: gmpy 1.01 rc near... anybody wanna test>

mensanator@aol.com wrote:[color=blue]
> casevh@comcast.net wrote:[color=green]
> > What processor are you running?[/color]
>
> Drat, didn't see this before I left work. I'm fairly certain it was a
> Pentium 4, definitely 1.7GHz, Win2000 and Python 2.3.
>
> So I thought I would run the test again on my home computers,
> a Pentium 4 1.5 GHz WinXP Python 2.3 and a laptop with a
> Celeron 2.8 GHz WinXP Python 2.4.
>
> Here are the Celeron/Python2.4 numbers (and original test times)
>
> BF: 27.89 sec gen6 (31.92)
> CF: 0.203 sec gen9 (0.234)
> V: 5.062 sec gen9 (8.766)
>[/color]

Oops, accidentally hit the send button. I didn't give you the
results from my home desktop machine. And those are
interesting.

I did not intend for this test to be a benchmark, simply to
make sure gmpy (and my library of Collatz Functions) were
working properly. Can you imagine my shock at the reults
of the closed form test:

gmpy.version: 1.01

Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1

2**5-1 generation: 1 0 seconds
2**29-1 generation: 2 0 seconds
2**245-1 generation: 3 0.015 seconds
2**2189-1 generation: 4 0 seconds
2**19685-1 generation: 5 0 seconds
2**177149-1 generation: 6 0.219 seconds
2**1594325-1 generation: 7 29.22 seconds
2**14348909-1 generation: 8 5295 seconds

That's 88 minutes for the gen8 test alone (gen9 is still running).
I was expecting a quarter second for the entire test! I realize that
my office pc and my home pc are configured differently but there
shouldn't be that much difference with the same version of Python
and gmpy.

At first I thought it was locking up, but it didn't have the symptoms
of a lockup: menus still worked, Task manager didn't report not
responding, and sure enough, it completed gen7 eventually.

I finally figured it out, though. I had been toying with my Collatz
Functions and made what I thought was a trivial change:

Original function
def Type12MH(k,i):
"""Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

Type12MH(k,i)
k: generation
i: member of generation
returns Hailstone (a)
"""
if (k<1) or (i<1): return 0
a = (i-1)*9**(k-1) + (9**(k-1) - 1)/2 + 1
return 2**(6*a - 1) - 1

Now I know better than to allow coersion to mpz's to take place
inside a loop, but this function doesn't loop. Nevertheless, I changed
it to

def Type12MH(k,i):
"""Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation

Type12MH(k,i)
k: generation
i: member of generation
returns Hailstone (a)
"""
ONE = gmpy.mpz(1)
TWO = gmpy.mpz(2)
SIX = gmpy.mpz(6)
NIN = gmpy.mpz(9)

if (k<1) or (i<1): return 0

i = gmpy.mpz(i)
k = gmpy.mpz(k)

# a = (i-1)*9**(k-1) + (9**(k-1) - 1)/2 + 1
# return 2**(6*a - 1) - 1

a = (i-ONE)*NIN**(k-ONE) + (NIN**(k-ONE) - ONE)/TWO + ONE
return TWO**(SIX*a - ONE) - ONE

And this was what is making my home desktop run so slow
(at least with mega-bit sized numbers). As soon as I updated the
Collatz Library, I got normal reults:

BF: 37.11 sec gen6
CF: 0.563 sec gen9
V: 1.093 sec gen9

(Verified by setting it back to original.)

Wow. Didn't realize things were that sensitive. Looks like I'll
have to review a lot of my programs.
[color=blue][color=green]
> >
> > I only have Windows running on an old Pentium 3. It is easy for me to
> > build a version that will running on almost any recent processor. I'm
> > willing to try and override the CPU detection and make a processor
> > specific build for you. I won't be able to test it, though.
> >
> > Thanks for the testing!
> >
> > Case[/color][/color]