ANN: GMPY 1.10 alpha with support for Python 3

casevh casevh at gmail.com
Wed Jul 8 20:38:06 EDT 2009


On Jul 8, 5:03 pm, Mensanator <mensana... at aol.com> wrote:
> On Jul 7, 12:47 am, Mensanator <mensana... at aol.com> wrote:
>
>
>
> > On Jul 7, 12:16 am, casevh <cas... at gmail.com> wrote:
>
> > > I discovered a serious bug with comparisons and have posted alpha2
> > > which fixes that bug and adds Unicode support for Python 2.x
>
> > > casevh
>
> > Damn! I was just congatulating myself for pulling off
> > a hat trick (there had been no point in downloading
> > 3.x without gmpy so I have been putting it off):
>
> > - installing Python 3.1
> > - installing gmpy 1.10
> > - converting my Collatz Function library to 3.1 syntax
>
> > And it all worked smoothly, just had to add parentheses
> > to my print statements, change xrange to range and all
> > my / to // (the library is exclusively integer). I had
> > gmpy running in my library on 3.1 in about 10 minutes.
>
> > So I'll have to re-do the gmpy install. Shouldn't be
> > any big deal.
>
> > I started doing some real world tests. Generally, things
> > look good (nothing crashes, timing looks not bad) but
> > I'm getting some funny results on one of my tests, so
> > I'll report back when I have more information.
>
> As I said, I was getting funny results from one of my tests.
>
> It seemed to work ok, but timing varied from 2 to 88 seconds,
> which seemed odd. The other tests were generally consistent
> for a given environment (cpu speed, OS, Python version, gmpy
> version).
>
> At some point I watched the memory usage profile from Windows.
> On the same machine I have both Python 2.6 and 3.1 installed,
> with the appropriate gmpy 1.10 version loaded for each.
>
> In Python 2.6, it looks like this:
>
> memory usage profile Python 2.6 gmpy 1.1 Vista
>
>       /--------------\  /-------\ .....RESTART SHELL
>      /               .\/         \
> ____/                .            \________
>    .                 .
>    .                 .
>    start of RUN      start of RUN
>
> The first "start of RUN" is the first time the test is run
> (from IDLE). That change in usage represents about 700 MB
> (I'm testing really BIG numbers, up to 500 million digits).
>
> The memory remains allocated after the program terminates
> (the flat plateau). When I run a second time, we see the
> allocation dip, then climb back up to the plateau, so it
> appears that the allocation never climbs above 1.1 GB.
>
> Finally, doing a RESTART SHELL seems to completely free
> the allocated memory. I assume this is normal behaviour.
>
> With Python 3.1, it get this profile:
>
> memory usage profile Python 3.1 gmpy 1.1 Vista
>
>                          /-
>                         / |
>       /----------------/   \------\ .....RESTART SHELL
>      /                 .           \
> ____/                  .            \___________
>    .                   .
>    .                   .
>    start of RUN        start of RUN
>
> Here, at the start of the second RUN, it appears that new
> memory is allocated BEFORE the previous is cleared. Is this
> a quirk in the way 3.1 behaves? Here, the peak usage climbs
> to 1.8 GB which I think causes VM thrashing accounting for
> the increased execution times.
>

Hmmm. It looks like memory is not being release properly. I don't see
that behavior under Linux. The running time is a very consistent 1.35
seconds. I'm traveling at the moment so it will be at least a week
before I can test under Windows.

Thanks for the report. I'll try to see if I can figure out what is
going on.

casevh
> My guess is that gmpy is provoking, but not causing this
> behaviour.
>
> The actual test is:
>
> t0 = time.time()
> n=10
> for k in range(1,n):
>   for i in range(1,n-2):
>     print((str(cf.gmpy.numdigits(cf.Type12MH(k,i))).zfill(n)),end=' ')
>   print()
> print()
> t1 = time.time()
>
> The library function Type12MH is:
>
> 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
>
> ##  Sample runs
> ##
> ##  Test 1 - create numbers up to 500 million digits
> ##
> ##  0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
> 0000000013
> ##  0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
> 0000000107
> ##  0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
> 0000000952
> ##  0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
> 0000008560
> ##  0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
> 0000077028
> ##  0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
> 0000693246
> ##  0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
> 0006239209
> ##  0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
> 0056152869
> ##  0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
> 0505375816
> ##
> ##  15.5460000038
> ##  >>> ================================ RESTART
> ================================
> ##  >>>
> ##  0000000002 0000000004 0000000006 0000000007 0000000009 0000000011
> 0000000013
> ##  0000000009 0000000025 0000000042 0000000058 0000000074 0000000091
> 0000000107
> ##  0000000074 0000000221 0000000367 0000000513 0000000659 0000000806
> 0000000952
> ##  0000000659 0000001976 0000003293 0000004610 0000005926 0000007243
> 0000008560
> ##  0000005926 0000017777 0000029627 0000041477 0000053328 0000065178
> 0000077028
> ##  0000053328 0000159981 0000266634 0000373287 0000479940 0000586593
> 0000693246
> ##  0000479940 0001439818 0002399696 0003359574 0004319453 0005279331
> 0006239209
> ##  0004319453 0012958355 0021597258 0030236161 0038875064 0047513967
> 0056152869
> ##  0038875064 0116625189 0194375315 0272125440 0349875565 0427625691
> 0505375816
> ##
> ##  3.06299996376




More information about the Python-list mailing list