On Jul 8, 5:03 pm, Mensanator <mensana...@aol.com> wrote: > On Jul 7, 12:47 am, Mensanator <mensana...@aol.com> wrote: > > > > > On Jul 7, 12:16 am, casevh <cas...@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 -- http://mail.python.org/mailman/listinfo/python-list
