Re: why did GMPY change the names of its functions?
On Mar 26, 1:33 pm, cas...@gmail.com wrote: > On Sunday, March 25, 2012 9:59:56 PM UTC-7, Mensanator wrote: > > OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. > > > But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? > > > What's the justification for that? I use those functions extensively > > in my library of Collatz utilities and I had to re-edit them for no > > obvious reason. > > I'll speak up as the maintainer of GMPY and GMPY2. > > (My comments apply to the beta1 release which should be out in a couple of > days.) > > GMPY2 introduces many changes: > > 1) the limited "mpf" type that is based on GMP has been replaced with the > "mpfr" type from the MPFR library > 2) support for multiple-precision complex arithmetic based on the MPC library > 3) support for a mutable integer type optimized for in-place bit manipulations > 4) support for addition number theory functions (generalized Lucas sequences > and more primality tests > > I began to encounter name collisions; for example, should sqrt() only return > integer square roots. I chose to call it a new name (gmpy2) and update the > API to reflect new choices I made. For example, sqrt() now returns an "mpfr" > and isqrt() returns an "mpz". > > As part of the documentation for the beta release, I will document the name > changes. "import gmpy2 as gmpy; gmpy.scan0=gmpy.bit_scan0; etc" should work > just fine. > > If you encounter problems with the alpha release, please open an issue on > gmpy's site. > > Thanks, > casevh Thanks for the explanation. Sorry if I flew off the handle, but I've been sick recently and am trying to get back into Python after 2 years. I just bought a new laptop, downloaded Python 3.2 & GMPY2 only to see my Collatz library crash. At first, given my current condition, I was afraid I'd never get it to work again. But luckily, the fix is simple. I, for one, really appreciate your maintaining GMPY, otherwise, I might have to abandon Python. I'll keep my eyes open for any further problems. Thanks Gain. > > > > On Sunday, March 25, 2012 9:59:56 PM UTC-7, Mensanator wrote: > > OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. > > > But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? > > > What's the justification for that? I use those functions extensively > > in my library of Collatz utilities and I had to re-edit them for no > > obvious reason. > On Sunday, March 25, 2012 9:59:56 PM UTC-7, Mensanator wrote: > > OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. > > > But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? > > > What's the justification for that? I use those functions extensively > > in my library of Collatz utilities and I had to re-edit them for no > > obvious reason. > On Sunday, March 25, 2012 9:59:56 PM UTC-7, Mensanator wrote: > > OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. > > > But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? > > > What's the justification for that? I use those functions extensively > > in my library of Collatz utilities and I had to re-edit them for no > > obvious reason. -- http://mail.python.org/mailman/listinfo/python-list
Re: why did GMPY change the names of its functions?
On Mar 26, 10:39 am, Terry Reedy wrote: > On 3/26/2012 12:59 AM, Mensanator wrote: > > > OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. > > > But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? > > Guess: Either the functions changed or they want to regularize their names. > > > What's the justification for that? I use those functions extensively > > in my library of Collatz utilities and I had to re-edit them for no > > obvious reason. > > If GMPY is coded in Python with a C? backup, GMPY.scan0 = GMPY.bit_scan0 > should work. > > Or you could write a GMPY.py wrapper for GMPY2 > > from GMPY2 import * > scan0=bit_scan0 > scan1=bit_scan1 > > > and leave your user code alone. > > -- > Terry Jan Reedy Oh, similar to an "import as", but this would allow me to change individual functions. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
why did GMPY change the names of its functions?
OK, GMPY is now called GMPY2. No big deal, I can import as GMPY. But why were scan0 and scan1 changed to bit_scan0 and bit_scan1? What's the justification for that? I use those functions extensively in my library of Collatz utilities and I had to re-edit them for no obvious reason. -- http://mail.python.org/mailman/listinfo/python-list
Re: huh??? weird problem
On May 14, 7:14 pm, cerr wrote: > Hi There, > > I got following code: > start=time.time() > print 'warnTimeout '+str(WarnTimeout) > print 'critTimeout '+str(CritTimeout) > print 'start',str(start) > while wait: > passed = time.time()-start > print 'passed ',str(passed) > if passed >= WarnTimeout: > print ' Warning!' > ... > ... > ... > which basically means that the loops should go until the warning time > has been reached and then i want it to print 'warning!' and execute > some warning code. But weirdly enough i get following screen output: > warnTimeout 3 > critTimeout 5 > start 1273882010.43 > passed 7.60555267334e-05 > passed 0.998471975327 > passed 1.99847102165 > passed 2.9984691143 > passed 3.99847006798 > passed 4.998472929 > ... > ... > any one a clue why after 3 seconds it doesn't go into the the if an > print 'Warning!'? Works for me: warnTimeout 3 critTimeout 5 start 1273883378.39 passed 1.0 passed 2.0 passed 3.0 Warning! passed 4.0 Warning! passed 5.0 Warning! passed 6.0 Warning! passed 7.0 Warning! > That's odd... :o Crazy, what am i not seeing? :( Did you copy it right? -- http://mail.python.org/mailman/listinfo/python-list
Re: stopping execution window on error - newbie
On May 13, 4:00 pm, a wrote:
> I'm coding on an old windows laptop
>
> i write the code and double click the icon.
Don't do that.
> it runs the program and
> writes results to a window.
>
> when the code finishes, the window closes, i do a time.sleep(10) to
> see what has happened.
>
> unfortunately when there is an error it just closes the window.
> anyway of seeing the error messages?
Go to the windows [Start] button. Select [Run...] and in the popup
box,
type "cmd" as the program to run. This will open a DOS shell window (a
text window.)
Then you can run your Python script from the window prompt and it
won't
close until you manually close it, even if the program crashes.
For example, once I open the DOS shell...
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
H:\>C:
C:\>cd python31\user\lotto
C:\Python31\user\lotto>dir
Volume in drive C has no label.
Volume Serial Number is 06DE-55B4
Directory of C:\Python31\user\lotto
05/13/2010 05:53 PM .
05/13/2010 05:53 PM ..
08/19/2009 07:08 PM 3,334 lotto.py
05/13/2010 05:56 PM 6,068 lotto_2010.py
2 File(s) 9,402 bytes
2 Dir(s) 102,247,440,384 bytes free
C:\Python31\user\lotto>..\..\python lotto_2010.py
{1: 2, 2: 3, 3: 2, 4: 1, 5: 2, 6: 1, 7: 2, 8: 1, 9: 1, 10: 2, 11: 2,
13: 1, 14: 2, 17: 1, 18: 2, 19: 1, 20: 1, 21: 1, 22: 1, 24: 1, 25: 1,
26: 3, 27: 1, 28: 2, 29: 2, 30: 1, 31: 1, 32: 1, 34: 1, 35: 1, 37: 2,
38: 2, 39: 2, 40: 1, 42: 2, 43: 1, 44: 2, 46: 2, 47: 1, 48: 1, 50: 1,
51: 2, 52: 3}
1 2 **
2 3 ***
3 2 **
4 1 *
5 2 **
6 1 *
7 2 **
8 1 *
9 1 *
10 2 **
11 2 **
12
13 1 *
14 2 **
15
16
17 1 *
18 2 **
19 1 *
20 1 *
21 1 *
22 1 *
23
24 1 *
25 1 *
26 3 ***
27 1 *
28 2 **
29 2 **
30 1 *
31 1 *
32 1 *
33
34 1 *
35 1 *
36
37 2 **
38 2 **
39 2 **
40 1 *
41
42 2 **
43 1 *
44 2 **
45
46 2 **
47 1 *
48 1 *
49
50 1 *
51 2 **
52 3 ***
(7, 21, 50, 36, 26, 3)
(7, 21, 50, 36, 26, 17)
(7, 21, 50, 36, 26, 52)
(7, 21, 50, 36, 3, 17)
(7, 21, 50, 36, 3, 52)
(7, 21, 50, 36, 17, 52)
(7, 21, 50, 26, 3, 17)
(7, 21, 50, 26, 3, 52)
(7, 21, 50, 26, 17, 52)
(7, 21, 50, 3, 17, 52)
(7, 21, 36, 26, 3, 17)
(7, 21, 36, 26, 3, 52)
(7, 21, 36, 26, 17, 52)
(7, 21, 36, 3, 17, 52)
(7, 21, 26, 3, 17, 52)
(7, 50, 36, 26, 3, 17)
(7, 50, 36, 26, 3, 52)
(7, 50, 36, 26, 17, 52)
(7, 50, 36, 3, 17, 52)
(7, 50, 26, 3, 17, 52)
(7, 36, 26, 3, 17, 52)
(21, 50, 36, 26, 3, 17)
(21, 50, 36, 26, 3, 52)
(21, 50, 36, 26, 17, 52)
(21, 50, 36, 3, 17, 52)
(21, 50, 26, 3, 17, 52)
(21, 36, 26, 3, 17, 52)
(50, 36, 26, 3, 17, 52)
8 9 32 38 40 48
13 22 28 39 42 43
1 2 5 11 18 52 +
2 3 26 44 51 52 +++
4 7 14 26 35 52 +++
2 7 10 19 42 47 +
5 20 31 34 50 51 +
1 28 29 37 39 46
10 11 27 37 38 46
6 21 24 29 30 44 +
3 14 17 18 25 26 +++
7 10 39 42 45 46 +
15 17 23 36 38 44 ++
16 19 23 27 41 49
15 25 32 36 44 47 +
16 19 24 29 38 41
3 4 8 13 43 49 +
2 11 17 19 22 50 ++
14 21 22 28 30 45 +
4 15 21 34 47 49 +
19 34 38 39 40 48
4 16 24 33 37 48
8 16 17 18 39 40 +
1 24 27 30 31 47
1 7 11 21 30 43 ++
1 8 13 18 32 36 +
5 10 12 16 20 21 +
7 11 23 24 26 35 ++
7 8 11 13 42 49 +
1 8 17 34 40 50 ++
1 24 29 35 41 45
15 17 24 32 44 52 ++
4 12 21 26 33 38 ++
2 13 15 41 48 50 +
2 7 9 27 45 52 ++
24 25 35 36 39 42 +
8 22 39 40 42 48
16 18 29 30 34 43
7 21 28 36 45 50
4 8 30 35 39 42
2 11 15 23 40 51
2 7 14 18 23 34 +
1 11 22 37 41 50 +
4 34 40 44 50 52 ++
12 28 33 39 40 52 +
14 18 25 36 38 39 +
4 11 16 17 27 37 +
1 11 16 28 31 36 +
8 16 31 34 36 52 ++
7 10 15 21 35 36 +++
2 9 21 23 29 30 +
15 29 33 41 46 47
2 5 18 34 36 39 +
7 15 21 31 45 50 +++
12 17 20 28 39 51 +
3 7 22 26 50 52 +
1 5 21 27 31 39 +
2 8 10 23 34 50 +
1 11 24 26 32 52 ++
1 18 20 38 41 42
12 33 36 42 45 48 +
1 6 21 28 37 39 +
16 18 19 22 33 35
2 7 17 27 29 47 ++
15 19 20 25 42 45
2 6 17 19 20 41 +
1 13 34 42 43 46
16 29 30 31 34 47
5 7 26 29 36 46 +++
1 27 28 30 31 49
8 17 19 47 49 52 ++
5 23 32 41 42 45
11 13 22 29 40 46
16 17 18 20 41 43 +
3 17 26 38 45 52
13 18 21 38 39 41 +
14 19 28 40 44 51
4 8 9 36 43 47 +
1 9 15 24 36 39 +
4 31 37 41 42 43
7 12 18 27 36 42 ++
3 4 26 27 35 51 ++
7 12 19 23 26 45 ++
19 28 36 39 42 52 ++
8 17 21 44 46 51 ++
2 4 18 19 36 49 +
1 4 11 16 22 35
13 14 17 18 41 46 +
8 16 23 29 43 48
1 8 25 36 37 44 +
7 20 21 23 36 50
3 7 23 27 39 43 ++
4 10 21 37 38 48 +
6 18 30 35 36 42 +
3 14 23 43 46 48 +
10 11 19 26 42 46 +
1 5 27 34 42 45
1 16 29 33 40 46
32 41 43 45 48 51
1 13 23 24 46 49
24 25 28 30 32 40
8 14 20 33 50 52 ++
2 16 27 28 33 39
13 17 19 32 43 52 ++
10 11 16 43 45 49
2 4 20 22 35 44
1 12 18 36 37 40 +
8 10 16 22 35 47
8 11 16 31 45 46
11 13 22 25 26 27 +
3 17 25 26 29 40 +++
7 10 27 37 46 47 +
3 5 7 27 33 40 ++
4 14 28 37 40 44
18 22 25 33 43 48
11 19 26 30 44 50 ++
3 11 22 42 46 51 +
7 8 21 26 30 50
6 1
Re: How to test whether bit is set within a flag with Python ?
On May 12, 1:40 pm, MRAB wrote: > robert somerville wrote: > > I am trying to determine how to test whether variors bits are set within > > a byte (or larger flag) , the python 'and' and 'or' do not seem to be > > doing what i want .. does anybody have some sample code showing how to > > do it ?? > > > e.g. (in "C") > > > unsigned char a = 6; > > > is 3rd bit set ?? > > > a & 4 =, true in this case > > 'and', 'or' and 'not' are Boolean. > > Python borrows its bitwise operators from C: > > & bitwise and > | bitwise or > ^ bitwise xor > ~ bitwise not (ones' complement) > << shift left > >> shift right > > You also need to remember that Python's integers are of (virtually) > unlimited length. The gmpy module has a wonderful set of functions tailored to the bit twiddler: FUNCTIONS bit_length(...) bit_length(x): returns length of string representing x in base 2 >>> gmpy.bit_length(275) 9 digits(...) digits(x[,base]): returns Python string representing x in the given base (2 to 36, default 10 if omitted or 0); leading '-' present if x<0, but no leading '+' if x>=0. x must be an mpz, or else gets coerced into one. >>> gmpy.digits(275,2) '100010011' hamdist(...) hamdist(x,y): returns the Hamming distance (number of bit- positions where the bits differ) between x and y. x and y must be mpz, or else get coerced to mpz. >>> a = 275# '100010011' >>> b = 333# '101001101' #x >>> gmpy.hamdist(a,b) 5 lowbits(...) lowbits(x,n): returns the n lowest bits of x; n must be an ordinary Python int, >0; x must be an mpz, or else gets coerced to one. >>> gmpy.digits(gmpy.lowbits(333,8),2) '1001101' # (bit 7 was a 0) numdigits(...) numdigits(x[,base]): returns length of string representing x in the given base (2 to 36, default 10 if omitted or 0); the value returned may sometimes be 1 more than necessary; no provision for any 'sign' character, nor leading '0' or '0x' decoration, is made in the returned length. x must be an mpz, or else gets coerced into one. >>> import collatz_functions >>> c = collatz_functions.Type12MH(6,1) >>> gmpy.numdigits(c,2) 177149 popcount(...) popcount(x): returns the number of 1-bits set in x; note that this is 'infinite' if x<0, and in that case, -1 is returned. x must be an mpz, or else gets coerced to one. >>> gmpy.popcount(3**33) 34 >>> gmpy.digits(3**33,2) '1001110101010011001011010101110111011' scan0(...) scan0(x, n=0): returns the bit-index of the first 0-bit of x (that is at least n); n must be an ordinary Python int, >=0. If no more 0-bits are in x at or above bit-index n (which can only happen for x<0, notionally extended with infinite 1-bits), None is returned. x must be an mpz, or else gets coerced to one. >>> gmpy.scan0(3**33,4) # find first 0 bit starting at bit4 4 '1001110101010011001011010101110111011' x scan1(...) scan1(x, n=0): returns the bit-index of the first 1-bit of x (that is at least n); n must be an ordinary Python int, >=0. If no more 1-bits are in x at or above bit-index n (which can only happen for x>=0, notionally extended with infinite 0-bits), None is returned. x must be an mpz, or else gets coerced to one. >>> gmpy.scan1(3**33,4) # find first 1 bit starting at bit4 7 '1001110101010011001011010101110111011' x setbit(...) setbit(x,n,v=1): returns a copy of the value of x, with bit n set to value v; n must be an ordinary Python int, >=0; v, 0 or ! =0; x must be an mpz, or else gets coerced to one. >>> a = 2**24+1 >>> gmpy.digits(a,2) '10001' >>> a = gmpy.setbit(a,12,1) >>> gmpy.digits(a,2) '100010001' -- http://mail.python.org/mailman/listinfo/python-list
Re: Why the inconsistent of those two base64 methods?
On May 12, 4:20 am, Maarten wrote:
> On May 12, 6:04 am, Leo Jay wrote:
>
> > I'd like to encode a string in base64, but I found a inconsistent of
> > two methods:
>
> > >>> 'aaa'.encode('base64')
> > 'YWFh\n'
> > >>> import base64
> > >>> base64.b64encode('aaa')
> > 'YWFh'
>
> > as you can see, the result of
> > 'aaa'.encode('base64')
> > has a '\n' at the end, but the other method doesn't.
>
> > Why the inconsistent?
>
> Don't know. Does it matter?
Yeah...
>>> import base64
>>> a = 'aaa'.encode('base64')
>>> aa = base64.b64encode('aaa')
>>> a == aa
False
>
> >>> import base64
> >>> base64.decodestring(base64.b64encode('aaa'))
>
> 'aaa'
>
> >>> 'aaa'.encode('base64').decode('base64')
>
> 'aaa'
>
> (so far so good, and as expected)
>
> >>> base64.decodestring('aaa'.encode('base64'))
>
> 'aaa'
>
> >>> base64.b64encode('aaa').decode('base64')
>
> 'aaa'
>
> (As far as I can see, both methods are completely consistent)
Your notion of 'consistency' is wanting.
>
> Maarten
--
http://mail.python.org/mailman/listinfo/python-list
Re: First Timer
On May 11, 9:32 pm, Terry Reedy wrote: > On 5/11/2010 7:03 PM, Mensanator wrote: > > > On May 11, 4:37 pm, Terry Reedy wrote: > > >> In the command line interpreter, you should be able to hit up > >> arrow and have the line above copied to the current entry line for > >> correction. In IDLE, this does not yet work, > > > It doesn't have to. Simply place the cursor on the line you originally > > entered and hit. > > >> so copy and paste or retype. > > > The line will be repeated as a new line which you can edit > > and make corrections. > > Thank you for the information. I obviously have never seen that written > anywhere and never thought to try it. It will save me time. > > >> For anything too complicated for either of those (more than one line), I > >> use (and reuse) a temporary edit file in an edit window. Just make sure > >> the file is named.py rather than just. You save > >> and run the file with F5. If there is a syntax error, IDLE will say so > >> and reopen the cursor window with the cursor at (or after) the location > >> of the error. Fix and hit F5 again. Very fast. > > > Sounds like you're making a mountain out of a molehill. You deserve > > a medal if you've been using IDLE without knowing how to edit. > > Huh? I was explaining, perhaps clumbsily, how to easily edit, run, > re-edit, and re-run multiple statements, in an editor window meant for > that job, which cannot so easily be done in the shell, if at all. > > Unlike the raw interpreter window, IDLE does not allow pasting of > multiple statements in its simulated shell (well it does, but it ignores > any after the first). Really? Touche, I didn't know that. Because it would never occur to me. The only time I would need multiple lines is in a def situation. And placing the cursor on the def line repeats the ENTIRE definition, spanning as many lines as needed, all of which can be edited. Sure, I'll open an edit window when things get messy or need to be saved. But often the IDLE prompt is all I need > So using an editor window in that case also is > necessary. > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: First Timer
On May 11, 4:37 pm, Terry Reedy wrote: > On 5/11/2010 3:28 PM, Donna Lane wrote: > > > I have downloaded Python and I'm a beginner in every sense. > > Welcome. I hope you enjoy Python too. > > > What I want to> know now is when I am in Idle and have made a syntax error > how do I repair? > > After the error I can't type in anything and I get this bing noise. > > > Usually I just start idle over again. > > You cannot directly repair a line already ed. Ok. > You must enter a new line. Huh?! I suppose it depends on what you mean by "enter". > In the command line interpreter, you should be able to hit up > arrow and have the line above copied to the current entry line for > correction. In IDLE, this does not yet work, It doesn't have to. Simply place the cursor on the line you originally entered and hit . > so copy and paste or retype. The line will be repeated as a new line which you can edit and make corrections. > > For anything too complicated for either of those (more than one line), I > use (and reuse) a temporary edit file in an edit window. Just make sure > the file is named .py rather than just . You save > and run the file with F5. If there is a syntax error, IDLE will say so > and reopen the cursor window with the cursor at (or after) the location > of the error. Fix and hit F5 again. Very fast. Sounds like you're making a mountain out of a molehill. You deserve a medal if you've been using IDLE without knowing how to edit. > > The main thing to watch is that you must say 'print(x)' rather than just > 'x' to print. File/Recent files lets one easily reopen the tem file (or > any other of the 20 most recently edited files). > > I use the tem file when I copy and paste more than a single line of code > from, say, a post here. > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Help running Windows programs from Python
On May 7, 2:14 pm, Scott wrote:
> I want to write a script to automate log archiving/compressing on a
> Win2003 server. I have Python 2.6 installed. I am planning to use 7-
> zip for compression (because I have been using it manually for a while
> now). For now all operations will be local in the C: drive.
>
> As a total beginner I'm having trouble grasping the control of
> external programs.
>
> I have found these options but have not tried any yet - I would like
> some advice on which approach would be the most appropriate to begin
> with.
>
> Command Line Application Approach:
> os.system
> os.spawn*
> os.popen*
> popen2.*
> commands.*
> All of the above recommend replacing with subprocess module
> subprocess - latest way to do command line?
> pexpect module -http://sourceforge.net/projects/pexpect/, Most recent
> file is dated 1/5/2008
> It should work on any platform that supports the standard Python
> pty module. (Windows?)
> pty - "On Windows, only sockets are supported; on Unix, all
> file descriptors." (gulp, ??)
>
> COM Application Approach:
> Per the 7-zip FAQ: Use the 7z.dll or 7za.dll - I haven't found these
> files yet on sf.net.
> comtypes 0.6.2 - has the word COM in it?
> pywin32 / win32com - there's that word again.
>
> And then there is this whole idea of "wrappers."
>
> Thanks,
> Scott
Here's a simple example:
>>> import os
>>> the_output = os.popen("dir "+"c:\\python31\\user\\*.py").readlines()
>>> for i in the_output:print(i,end='')
Volume in drive C has no label.
Volume Serial Number is 06DE-55B4
Directory of c:\python31\user
09/08/2009 01:38 PM 689 3435.py
11/10/2009 06:43 PM 614 4697.py
03/09/2010 08:42 PM 5,922 5x.py
03/30/2010 07:51 PM 1,937 7[18] impure.py
08/28/2009 08:43 PM 1,867 bones.py
05/05/2010 07:21 PM 441 code.py
03/22/2010 04:31 PM 639 collatz_curiosity.py
09/18/2009 08:06 PM17,125 collatz_game.py
08/20/2009 03:09 PM 406 csv_file_fix__minimal_2_all.py
11/06/2009 08:18 PM 432 digitsets.py
07/20/2009 07:03 PM14,451 gmpy_geni_test_3.py
10/23/2009 05:35 PM 2,952 hit_target.py
03/19/2010 07:52 PM 245 how_many_random.py
04/15/2010 07:06 PM 217 issquare.py
07/31/2009 05:14 PM 1,132 itune.py
07/31/2009 04:41 PM 527 itune_stats.py
10/08/2009 08:08 PM 6,202 make_numbers.py
04/14/2010 08:00 PM 354 montyhall4.py
04/21/2010 07:46 PM 1,196 Ryan_Whited.py
03/25/2010 07:53 PM 4,318 ultimate_cycle.py
20 File(s) 61,666 bytes
0 Dir(s) 102,634,008,576 bytes free
>>>
--
http://mail.python.org/mailman/listinfo/python-list
Re: long int computations
On May 3, 10:17 am, s...@sig.for.address (Victor Eijkhout) wrote:
> I have two long ints, both too long to convert to float, but their ratio
> is something reasonable. How can I compute that? The obvious "(1.*x)/y"
> does not work.
You could try using the gmpy module. It supports arbitrary precision
floats, so converting long to float is no problem.
YY = 3**10684
float(YY)
Traceback (most recent call last)
File "pyshell#78>", line 1, in
float(YY)
OverflowError: Python int too large to convert to C double
import gmpy
gmpy.mpf(YY)
mpf('3.6600365709...0197681e5097',16936)
>
> Victor.
>
> --
> Victor Eijkhout -- eijkhout at tacc utexas edu
--
http://mail.python.org/mailman/listinfo/python-list
Re: Performance of list.index - how to speed up a silly algorithm?
On Apr 29, 5:21 pm, Laszlo Nagy wrote:
> I have some ten thousand rows in a table. E.g.
>
> columns = ["color","size","weight","value"]
> rows = [
> [ "Yellow", "Big", 2, 4 ],
> [ "Blue", "Big", 3, -4 ],
> [ "Blue", "Small", 10, 55 ],
> ...
> ]
>
> Some columns are dimensions, others are measures. I want to convert this
> to an indexed version, that looks like this:
>
> dimension_names = ["color","size"] # List of dimension names
> dimension_cols = [0,1] # Column indexes for dimension values
> dimension_values = { # Dimension value occurences for each dimension
> 0: ["Yellow","Blue",],
> 1: ["Big","Small",...],}
>
> measure_names = ["weight","value"] # List of measure names
> measure_cols = [2,3] # List of measure columns
> facts = [ # Facts, containing tuples of (dimension_value_incides,
> measure_values )
> ( (0,0) , (2,4) ),
> ( (1,0) , (3,-4) ),
> ( (1,1) , (10,55) ),
> ...
> ]
>
> This is how I try to convert to the indexed version:
>
> #1. Iterate over all rows, and collect possible dimension values.
>
> cnt = 0
> for row in iterator_factory():
> cnt += 1
> for dimension_idx,col_idx in enumerate(dimension_cols):
> dimension_values[colidx].append(row[cold_idx])
> if cnt%1:
> dimension_values[colidx] = list(set(dimension_values[colidx]))
>
> #2. Index facts by dimension values
>
> facts = []
> for row in iterator_factory():
> dv = []
> for dimension_idx,col_idx in enumerate(dimension_cols):
> dv.append( dimension_values[col_idx].index(row[col_idx]) ) #
> THIS IS THE PROBLEMATIC LINE!
> mv = [ row[col_idx] for col_idx in measure_cols ]
> facts.append( dv,mv )
>
> (In reality, rows and facts are not stored in memory, because there can
> be 100 000+ facts. I did not want to bore you with the full source code.)
>
> And finally, here is my problem. If a dimension has many possible
> values, then the list.index() code above slows down eveything. In my
> test case, the problematic dimension had about 36 000 different values,
> and the number of rows was about 60 000. Calling index() on a list of 36
> 000 values, times 60 000, is too slow.
>
> Test performance was 262 rows/sec. If I use dv.append(0) instead of "
> dv.append( dimension_values[col_idx].index(row[col_idx]) ) " then it
> goes up to 11520 rows/sec. If I exclude the problematic dimension, and
> only leave the others (with 1000 or less values) then goes up to 3000
> rows/sec.
>
> Maybe this should be implemented in C. But I believe that the algorithm
> itself must be wrong (regardless of the language). I really think that
> I'm doing something wrong. Looks like my algorithm's processing time is
> not linear to the number of rows. Not even log(n)*n. There should be a
> more effective way to do this. But how?
>
> I had the idea of sorting the rows by a given dimension. Then it would
> be obvious to speed up the indexing part - for that dimension. PROBABLY
> sorting all rows would be faster than calling list.index() for each row.
> But... it does not seem very efficient either. What if I have 1 million
> rows and 10 dimensions? Do I sort 1 million rows on the disk 10 times?
> Some of you might have ran into the same problem before, and can tell me
> which is the most efficient way to do this.
>
> Thanks,
Have you considered using a SQL database? Personally, I would use
MS-Access and link it to Python via ODBC. That way, I could use
the Access drag-and-drop design tools and either
- copy the SQL code of working query designs to Python
or
- use the ODBC to link to said queries rather than directly
to the raw tables
Of course, Python has SQLlight now, I just don't know SQL that well.
>
> Laszlo
--
http://mail.python.org/mailman/listinfo/python-list
Re: Deleting more than one element from a list
On Apr 21, 2:56 pm, candide wrote: > Is the del instruction able to remove _at the same_ time more than one > element from a list ? > > For instance, this seems to be correct : > > >>> z=[45,12,96,33,66,'c',20,99] > >>> del z[2], z[6],z[0] > >>> z > [12, 33, 66, 'c', 20] > >>> > > However, the following doesn't work : > > >> z=[45,12,96,33,66,'c',20,99] > >>> del z[2], z[3],z[6] > Traceback (most recent call last): > File "", line 1, in > IndexError: list assignment index out of range > >>> > > Does it mean the instruction > > del z[2], z[3],z[6] > > to be equivalent to the successive calls > > del z[2] > del z[3] > del z[6] That's part of the problem. Let's look at a better example. >>> z = [0,1,2,3,4,5,6] >>> del z[0],z[3],z[6] Traceback (most recent call last): File "", line 1, in del z[0],z[3],z[6] IndexError: list assignment index out of range >>> z [1, 2, 3, 5, 6] Yes, the error was caused by the list shrinking between calls, so the 6 did not get deleted. But notice that 3 is still there and 4 is missing. If you must delete this way, do it bottom up so that the index remains valid for the subsequent calls: >>> z = [0,1,2,3,4,5,6] >>> del z[6],z[3],z[0] >>> z [1, 2, 4, 5] > > ? -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 12, 11:39 am, Terry Reedy wrote: > On 4/12/2010 1:57 AM, Mensanator wrote: > > > Likewise, I usually don't shut down > > when I leave work, so I can't allow orphaned processes to accumulate > > eating up CPU and memory. > > So don't. I don't. I'm complaining about the need to do that. > > Orphaned processes only accumulate when you use Restart Shell to abandon > a process stuck in an infinite loop. Surely, you don't expect me to beleive that Python has solved the halting problem and knows when its in an infinite loop? No, Restart Shell is used whenever the process is going to take longer than one is willing to wait. > I personally very seldom do that. > Otherwise, the old process dies in a few seconds and the number of > pythonw processes drops back down from 3 to the normal 2. You've never written a program that takes more than a few seconds to execute? Wow. > > As I already said, either roboot or use TaskManager to kill such > zombies. Do we need to add something to the documentation to explain this? Something along the lines of: "Python simply doesn't work properly. You must keep constant vigilance on the TaskKanager to watch for orphaned processes, otherwise they will consume all your CPU cycles and eat up your memory."? Maybe put it in large red letters under the caption "WARNING!"? > When I had a unix desktop machine, I routinely used the command > line equivalents ps (process status) and kill to do the same thing. No wonder you don't see the problem! You think it's normal! > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 12, 3:51 am, alex23 wrote: > Mensanator wrote: > > You think the right thing to do is just quietly work > > around the problem and sit back and laugh knowing sooner > > or later someone else will get burned by it? > > Haven't we covered argument from fallacy enough in this group by now? > > Reporting the bug was exactly the right thing to do. Loudly > pronouncing the impending demise of 3.x because of it was not. Coming > up with exaggerated parodies of arguments that no one here is actually > making is even worse. > > > Why do you guys think I'm talking about the language? I'm talking > > about a particular implementation. > > Probably because _you_ made no such restriction with your blanket > statement of "3.x won't be adopted by developers until it's fixed". If > only "under Windows", "probably" and "IDLE" had been injected into it, > I don't think there would have been a word of disagreement. Ok. If more people are aware of the issue now, then the hyperbole has served it's purpose. -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 11, 6:08 pm, Steven D'Aprano wrote: > On Sun, 11 Apr 2010 11:54:04 -0700, Mensanator wrote: > > On Apr 11, 11:53 am, Steven D'Aprano > cybersource.com.au> wrote: > >> On Sat, 10 Apr 2010 21:08:44 -0700, Mensanator wrote: > >> >> > 3.x won't be adopted by developers until it's fixed. As of now, > >> >> > it's seriously broken and unsuitable for production. > > >> >> In what ways do you consider it broken? > > >> > Issue 8093. Remarkably, this apparently hasn't been noticed before. > > >> I think that tells you that it's an unimportant bug that doesn't really > >> effect many people much, > > > It affects me ... a LOT. > > I suspect you're exaggerating, I'm not. I often use a USB drive to store my source programs, makes it easy to switch between computers. Not being able to eject the USB drive is annoying, but not a game breaker. Likewise, I usually don't shut down when I leave work, so I can't allow orphaned processes to accumulate eating up CPU and memory. > but even if you're not, you are not the entire Python community. This is probably happening to everyone, they just haven't noticed. > You stated that "3.x won't be adopted by developers until it's fixed". > It sounds like what you really mean was > "3.x won't be adopted by *me* until it's fixed" Not at all. The only 3rd party library I use is gmpy, and that's been updated, so I have more or less abandoned 2.x in favor of 3.x. I have not installed the latest 2.6 version and have no intention of ever installing 2.7 . > > 3.x is already being adopted by developers. Let's hope a little thing like this won't upset them. > The two biggest factors > slowing uptake of 3.x are: (1) lack of big libraries like numpy, and (2) > that major Linux distros still ship with 2.6 or 2.5. It was even worse with Mac OSX 10.6. Luckily, there's macports, so it all got resolved. > > >> and a million miles from implying that Python 3.x is "seriously broken > >> and unsuitable for production". > > > Maybe because I'm a user, not a developer. > > You write code. You use an Integrated DEVELOPMENT Environment. That makes > you a developer. Being a little pedantic here, aren't we? Would it help if I said "professional" developer? After all, just because I dabble in Collatz Conjecture research as a hobby, it doesn't give me the right to go around calling myself a mathematician. > > >> > I expect 2.7 will be around for a long time. > > >> As reported on the bug tracker, this bug effects Python 2.7 as well. > >> It's possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older? > >> Who knows? > > > I can't imagine my not having noticed this before. It's plausible I > > might not have noticed the runaway processes, but the fact that I can't > > eject a USB drive would have been very obvious. > > Have you tried to reproduce it on 2.6 or 2.5? No, all I can say is I haven't noticed it there. And given the symptoms, I can't see how I could have not noticed it. On the other hand, I can't see how it could have gone unnoticed on 3.x. You don't suppose I'm the only one actually using 3.1? > Unless you actively try to > reproduce it, you can't assume it doesn't occur. True, just as you can't assume I'm the only one it's happening to. > > >>http://bugs.python.org/issue8093#msg102818 > > >> In any case, IDLE is one IDE out of many, and not really up to > >> professional quality -- it's clunky and ugly. It isn't Python, it is a > >> tool written in Python. > > > You have no idea what the cause is, yet you're certain that the symptom > > is confined to IDLE. > > Certain? Of course not. But given an issue that is reported with a single > application, which is more likely? That it is a bug in the language, or a > bug in the application? *I* never said the LANGUAGE was broken. I specifically made reference to the Windows implementation of 3.1.2. > > Even if it is a bug in the language, some fundamental failure of the > underlying Python virtual machine or built-in objects, there are dozens > of standard library modules, and thousands of third-party modules, that > it doesn't affect. I assume you mean when not run in IDLE. And how do you know they're not affected? Didn't you just get done yelling at me for not testing it in 2.5 & 2.6? > > > That's the kind of thinking that leads to such bugs in the first place. > > Rght. You think these bugs are done deliberately? > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 11, 11:33 pm, Lie Ryan wrote: > On 04/12/10 04:54, Mensanator wrote: > > > On Apr 11, 11:53 am, Steven D'Aprano > cybersource.com.au> wrote: > >> On Sat, 10 Apr 2010 21:08:44 -0700, Mensanator wrote: > >>>>> 3.x won't be adopted by developers until it's fixed. As of now, it's > >>>>> seriously broken and unsuitable for production. > > >>>> In what ways do you consider it broken? > > >>> Issue 8093. Remarkably, this apparently hasn't been noticed before. > > >> I think that tells you that it's an unimportant bug that doesn't really > >> effect many people much, > > > It affects me ... a LOT. > > One way to fix it, dump tkinter and IDLE. Of course, that doesn't fix the problem, does it? You think the right thing to do is just quietly work around the problem and sit back and laugh knowing sooner or later someone else will get burned by it? And here I thought I was making a contribution by discovering something that no one else noticed. > > C/C++ is not broken since they do not ship with an ugly GUI library or > half-assed IDE called IDLE. Why do you guys think I'm talking about the language? I'm talking about a particular implementation. > Why should python ship with them? > > On a second thought, let me think about it again. Yeah, you certainly don't want to get yelled at by Mr. D'Aprano. -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 11, 12:00�pm, Terry Reedy wrote: > On 4/11/2010 12:08 AM, Mensanator wrote: > > > On Apr 10, 7:15 pm, Chris Rebert �wrote: > >> On Sat, Apr 10, 2010 at 4:47 PM, Mensanator �wrote: > >>> 3.x won't be adopted by developers until it's fixed. As of now, it's > >>> seriously broken and unsuitable for production. > > Not. Many though will wait until 3.2 and greater library availability, > which *is* coming. Which comes first, library availability or a working system? > > >> In what ways do you consider it broken? > > > Issue 8093. > > IDLE is not Python. The Task Manager doesn't say "IDLE", it says "pytonw". > And are you really sure this is 3.x-only problem No, I didn't say it was, just that that's where I noticed it. I haven't been using the latest 2.x upgrades because I switched to 3.x. > or > that it is not a Windows-only problem. Could very well be. But when YOU target a specific operating system, isn't the onus on YOU to make it work within that system? If you're not content to be a big fish in a small pond, then you better figure out a way to make it work. > > > Remarkably, this apparently hasn't been noticed before. > > Because it requires somewhat rare circumstances. Start an infinite loop > from IDLE, perhaps specifically on Windows. Try to restart. Patiently > wait for restart to happen (several seconds, and iffy) Not iffy at all. If it responds to the menu and I can click on Restart, it succeeds. > instead of > killing the runaway process from TaskManager. Why on earth would I want to do that? Then I lose the entire history of whats printed in the window. You've got a serious problem if you expect the TaskManager to be used for normal operations. > > > I expect 2.7 will be around for a long time. > > That was always expected independently of this issue. I hear 2.7 doesn't work either. I'll back off on that comment. > > Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 11, 11:53�am, Steven D'Aprano wrote: > On Sat, 10 Apr 2010 21:08:44 -0700, Mensanator wrote: > >> > 3.x won't be adopted by developers until it's fixed. As of now, it's > >> > seriously broken and unsuitable for production. > > >> In what ways do you consider it broken? > > > Issue 8093. Remarkably, this apparently hasn't been noticed before. > > I think that tells you that it's an unimportant bug that doesn't really > effect many people much, It affects me ... a LOT. > and a million miles from implying that Python > 3.x is "seriously broken and unsuitable for production". Maybe because I'm a user, not a developer. > > > I expect 2.7 will be around for a long time. > > As reported on the bug tracker, this bug effects Python 2.7 as well. It's > possible this bug goes back to, what? Python 2.5? 2.4? 2.3? Older? Who > knows? I can't imagine my not having noticed this before. It's plausible I might not have noticed the runaway processes, but the fact that I can't eject a USB drive would have been very obvious. > > http://bugs.python.org/issue8093#msg102818 > > In any case, IDLE is one IDE out of many, and not really up to > professional quality -- it's clunky and ugly. It isn't Python, it is a > tool written in Python. You have no idea what the cause is, yet you're certain that the symptom is confined to IDLE. That's the kind of thinking that leads to such bugs in the first place. > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 10, 11:51�pm, alex23 wrote: > Mensanator wrote: > > 3.x won't be adopted by WINDOWS developers WHO USE IDLE until it's fixed. > > I think you left your hyperbole level too high so I turned it down for > you. I don't know of _anyone_ who uses IDLE to run production code, > nor do I follow how one errant IDE shows that Python 3.x as a language > is broken. Planning to buy a Toyota? -- http://mail.python.org/mailman/listinfo/python-list
Re: 2.7 beta 1
On Apr 10, 7:15�pm, Chris Rebert wrote: > On Sat, Apr 10, 2010 at 4:47 PM, Mensanator wrote: > > On Apr 10, 5:45�pm, Michael Str�der wrote: > >> average wrote: > >> >> On behalf of the Python development team, I'm merry to announce the > >> >> first beta > >> >> release of Python 2.7. > > >> >> Python 2.7 is scheduled (by Guido and Python-dev) to be the last major > >> >> version > >> >> in the 2.x series. �Though more major releases have not been absolutely > >> >> ruled > >> >> out, it's likely that the 2.7 release will an extended period of > >> >> maintenance for > >> >> the 2.x series. > > >> > May I propose that the developers consider keeping this release *beta* > >> > until after the present Python moratorium? �That is, don't let it be > >> > marked as *official* until after, say, Python 3.3. > > >> > There are so many features taken from 3.0 that I fear that it will > >> > postpone its adoption interminably > > >> Whether 3.x is adopted by developers is IMO not influenced by the 2.7 > >> release > >> schedule. At least the effect is highly speculative. So please simply > >> release > >> 2.7 when it's ready. > > > 3.x won't be adopted by developers until it's fixed. As of now, it's > > seriously broken and unsuitable for production. > > In what ways do you consider it broken? Issue 8093. Remarkably, this apparently hasn't been noticed before. I expect 2.7 will be around for a long time. > > Cheers, > Chris- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: [RELEASED] 2.7 beta 1
On Apr 10, 5:45 pm, Michael Ströder wrote: > average wrote: > >> On behalf of the Python development team, I'm merry to announce the first > >> beta > >> release of Python 2.7. > > >> Python 2.7 is scheduled (by Guido and Python-dev) to be the last major > >> version > >> in the 2.x series. Though more major releases have not been absolutely > >> ruled > >> out, it's likely that the 2.7 release will an extended period of > >> maintenance for > >> the 2.x series. > > > May I propose that the developers consider keeping this release *beta* > > until after the present Python moratorium? That is, don't let it be > > marked as *official* until after, say, Python 3.3. > > > There are so many features taken from 3.0 that I fear that it will > > postpone its adoption interminably > > Whether 3.x is adopted by developers is IMO not influenced by the 2.7 release > schedule. At least the effect is highly speculative. So please simply release > 2.7 when it's ready. 3.x won't be adopted by developers until it's fixed. As of now, it's seriously broken and unsuitable for production. > > Ciao, Michael. -- http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 3, 9:03 pm, Steven D'Aprano wrote:
> On Sat, 03 Apr 2010 09:35:34 -0700, Mensanator wrote:
> > On Apr 3, 10:17 am, Steven D'Aprano > cybersource.com.au> wrote:
> >> On Sat, 03 Apr 2010 15:43:41 +0100, Martin P. Hellwig wrote:
> >> > I am replying to this post not because I disagree but because it
> >> > postalogically fits the best (I am by no means an expert either).
>
> >> > IMHO, the crackpot in this regard is actually partially right,
> >> > multiplication does mean that the number must get bigger, however for
> >> > fractions you multiply four numbers, two numerators and two
> >> > denominators. The resulting numerator and denominator by this
> >> > multiplication get indeed bigger.
>
> >> But you're not multiplying four numbers,
>
> > You are if you're using Rationals.
>
> That is sheer unadulterated nonsense.
You obviously don't understand the workings of computers.
>
> A rational number (element of Q) is not a pair of numbers,
Duh. Everybody knows that. But sometimes it is represented
by a pair of numbers such as 1/2 or mpq(1,2).
> it is a unique
> single point on the real number line R which does not depend on either
> the way you calculate it,
There are no "real number lines" inside my computer.
> or the representation you use to write it.
And if you want the computer to do a calculation, then you are
dependent on its representation.
>
> The single number 1/2 can be written as any of 1/2, 2/4, 5/10, 1234/2468
> or any of an infinite number of ratios representations. It can be written
> as a decimal expansion 0.5, or a binary expansion 0.1, or the negative-
> binary expansion 1.5, or as the base-eleven infinite expansion that
> starts as 0.5...
But we are only discussing those representations that are
a pair of numbers: numerator & denominator. Now look who's
talking nonsense, bringing up things like 0.5...
>
> Numbers can also be written as continued fractions. The continued
> fraction representation for 1/2 is unexciting and happens to include two
> digits: [0; 2]. But the continued fraction representation of (say) 5/7 is
> [0; 1, 2, 2]. 5/7 isn't four numbers, or three, or two. It is one number.
You're on a roll, aren't you?
>
> You might as well argue that 43/92 is "four numbers" -- you have a 4, and
> 3, and 9, and a 2, hence four numbers. The argument that 1/2 is two
> numbers is exactly as foolish as that.
Are you really that stupid?
>
> >> you're multiplying two numbers.
>
> > Because they're expressed as Decimals.
>
> No, the number of operands is independent of the types of the operands.
> Multiplication is a binary operator: it takes exactly two arguments. Not
> four, or six, or one. Regardless of whether I write:
>
> Fraction(1,2)*Fraction(7,14)
> Decimal('0.5')*Decimal('0.5')
> 0.5*0.5
> MyFraction.from_roman('I', 'II')*MyContinedFraction([0, 2, 0, 0, 0])
>
> I still have two numbers being multiplied.
And you claim that the internal workings of all the above are
the same?
>
> >> One-half is not "two numbers",
>
> > Sometimes it is.
>
> Only on Bizarro world.
I thought you were supposed to be a Python expert?
That you're supposed to understand the difference
between an object and its contents?
Is [1,2,3,4] one number? Of course not, it's four numbers
that are part of one object. A Rational is two numbers,
one object. Yes, squaring a Rational does mean multiplying
two objects, but you know damn well that it involves four
numbers.
>
> >> that would be a tuple
>
> > Like this?
>
> >>>> gmpy.mpq('0.5')
> > mpq(1,2)
>
> No, that's not a pair of numbers.
Yes, it is. Two numbers, one object. Perhaps you need to
read the Tutorial?
> It is a single number, equal to:
The word you want here is "object". This is exactly the reason
these words were invented. They're probably spinning in their grave.
>
> ∑(i=1,∞,9/10**i)
> --
> (ln(e)+sin(5π/2))
>
> which is also a single number.
"Object".
>
> >> or a list or
> >> possibly a coordinate pair. One-half is a single number,
>
> > When dealing with crackpots, it does not help to use the wrong
> > arguments.
>
> And you think that telling the crackpot that he is right, multiplication
> always leads to bigger numbers, is somehow going to convince him that he
> is wrong about multiplication always leading to bigger numbers?
Of course not. But it may help the OP understand that's one of the
main fallacies that crack
Re: off topic but please forgive me me and answer
On Apr 3, 10:17 am, Steven D'Aprano wrote:
> On Sat, 03 Apr 2010 15:43:41 +0100, Martin P. Hellwig wrote:
> > I am replying to this post not because I disagree but because it
> > postalogically fits the best (I am by no means an expert either).
>
> > IMHO, the crackpot in this regard is actually partially right,
> > multiplication does mean that the number must get bigger, however for
> > fractions you multiply four numbers, two numerators and two
> > denominators. The resulting numerator and denominator by this
> > multiplication get indeed bigger.
>
> But you're not multiplying four numbers,
You are if you're using Rationals.
> you're multiplying two numbers.
Because they're expressed as Decimals.
> One-half is not "two numbers",
Sometimes it is.
> that would be a tuple
Like this?
>>> gmpy.mpq('0.5')
mpq(1,2)
> or a list or
> possibly a coordinate pair. One-half is a single number,
When dealing with crackpots, it does not help to use the
wrong arguments. When multiplying gmpy.mpq(2,3) by gmpy.mpq(2,3),
the numerator and denominator have both indeed gotten bigger.
The trick is that when combined, the overall result is smaller.
> the number which
> if you double it gives one.
>
> Fortunately multiplication is consistent. Multiplying the two numbers 0.5
> and 0.5 is exactly the same as multiplying 1*1 and 2*2 then dividing to
> get a single number. It's not the same as multiplying 1*1 and 2*2 to get
> two numbers, 1 and 4.
>
> You say that multiplication means that the number "must get bigger".
Yes, not in every case, but in many cases it does. You need to point
out that it is wrong EVEN IN THE CASES WHERE IT'S TRUE. It is a
Non Sequitur - it does not follow that a number must be bigger if
the numerator and denominator have each gotten larger.
>
> 5*1 = 5
> 5*0 = 0
> 5*-2 = -10
>
> I hope you won't try to argue that 5, 0 and -10 are all bigger than 5.
Yes, but these special cases don't help. It needs to be pointed out
that the argument is wrong even in cases like 2/3 * 2/3.
>
> There really is no point trying to dignify superpollo's friend's
> assertion on the basis of some technicality. His argument is no different
> from the argument that says that pythons are snakes, and therefore python
> can't be a programming language and this newsgroup can't possibly exist.
> Words can have multiple meanings, and meanings can shift. Multiply may be
> derived from a word which, once upon a time, meant to get bigger, but
> that's not what multiply means. I don't like to dismiss somebody I've
> never met, but on the basis of what superpollo says, yes, he's a crackpot.
>
> Either that or about age four. When I was four I strongly believed that
> "one hundred" and "a hundred" were different numbers. I argued (not very
> convincingly, but with great vehemence) to my teacher and my parents that
> you counted up to ninety-nine, then a hundred, a hundred and one, a
> hundred and two, ... a hundred and ninety-nine, *one* hundred.
>
> --
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 3, 8:00 am, superpollo wrote: > Patrick Maupin ha scritto: > > > > > > > On Apr 2, 2:41 pm, Andreas Waldenburger > > wrote: > > >> While everyone else is mocking you: Can you please elaborate on why you > >> want to know and what kind of problem you're trying to solve with this? > >> Also, don't you think you should have picked a maths forum for this > >> kind of question? > > > Methinks the OP is fluent in the way of choosing newsgroups. > > According to google, he has posted 6855 messages in 213 groups. > > >http://groups.google.com/groups/profile?enc_user=ul3SQhIYmLD0Oj5Y... > > > And I can't speak for anybody else, but I just assumed it was an April > > Fool's question. I meant to be laughing with the OP, not at him, so > > sorry if I misunderstood. > > no no you understood prfectly *but* the thing is i am a regular in an > italian language math ng which is haunted by a crackpot who insists that > 1/2 * 1/2 cannot be 1/4, "because multiplication means getting bigger", > so i took a semi-serious stance and made a few posts as a statistical > tentative to "convince" said crackpot that the world is not going crazy > (but maybe he is) I seriously doubt your crackpot friend actually believes that. Probably more troll than crackpot. Showing him articles and programs that prove your premise will accomplish nothing. However, if you personally wanted information on programming with rational numbers, you came to the right place. > > thanks > > ps: note that my nickname is not unique, and there are a few people > whith the same one... and i didn't ever post using googlegroups What does it mean, "super chicken? -- http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 2, 7:32 pm, Patrick Maupin wrote: > On Apr 2, 6:50 pm, Mensanator wrote: > > > On Apr 2, 2:34 pm, Patrick Maupin wrote: > > > > Methinks the OP is fluent in the way of choosing newsgroups. > > > According to google, he has posted 6855 messages in 213 groups. > > > Does that really mean anything? Hell, I have 12765 messages > > posted to 332 groups, but I only use 10 regularly. > > Well, I have been very wrong in my assumptions before, but yes, I do > assume it means something: Yes, you are, in fact, all wet. > > - I assume that the OP knows of the existence of more than one > newsgroup. "More than one", that's fair. 213, unlikely. > > - I assume the OP knows how to locate different newsgroups, either via > search or some directory like yahoo, and is able to think about which > one he wants to post to and why. And most of those probably involved no thought at all, probably due to cross-posting from a relatively small number of sources (certainly in my case). So, no, this stat proves nothing about the OP's ability to find newsgroups or think about their appropriateness. > > - I assume that he is comfortable with the process of posting. In > fact, looking at the stats, about half as comfortable as mensanator, > and over 18 times as comfortable as me ;-) Well, _I've_ been here on Usenet for 10 years. But despite the stats, I know little about most to the groups I've "posted to". > > Of course, I could be all wet in my assumptions, and it may just be > that the OP has a cat constantly walking back and forth across his > keyboard... Don't you know how Usenet works? > > Regards, > Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 2, 2:34 pm, Patrick Maupin wrote: > On Apr 2, 2:41 pm, Andreas Waldenburger > wrote: > > > While everyone else is mocking you: Can you please elaborate on why you > > want to know and what kind of problem you're trying to solve with this? > > Also, don't you think you should have picked a maths forum for this > > kind of question? > > Methinks the OP is fluent in the way of choosing newsgroups. > According to google, he has posted 6855 messages in 213 groups. Does that really mean anything? Hell, I have 12765 messages posted to 332 groups, but I only use 10 regularly. > > http://groups.google.com/groups/profile?enc_user=ul3SQhIYmLD0Oj5Y... > > And I can't speak for anybody else, but I just assumed it was an April > Fool's question. I meant to be laughing with the OP, not at him, so > sorry if I misunderstood. > > Regards, > Pat -- http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 2, 6:07 pm, Steven D'Aprano wrote: > On Fri, 02 Apr 2010 12:35:55 -0700, Mensanator wrote: > >> If you want an exact result when multiplying arbitrary fractions, you > >> need to avoid floats and decimals and use Fractions: > > >> >>> Fraction(1, 2)**2 > > >> Fraction(1, 4) > > > Where do you get that from? > > Where do I get what from? Fraction? Oops, sorry about that. > > In Python2.6: > > >>> from fractions import Fraction Ok, thanks. I've been using gmpy to do rational arithmetic: >>> import gmpy >>> gmpy.mpq(1,2)**2 mpq(1,4) But I don't have a lot of call for it. > > In older Pythons, there was a demo module Demo/classes/Rat.py but it may > not be installed on your system. Seehttp://bugs.python.org/issue1682 > > If you meant, where did I get the statement about exact results from, > both float and Decimal are fixed precision numbers. float precision is > fixed by the operating system and/or hardware; Decimal precision can be > arbitrarily chosen by the caller, but having made that choice, > calculations are rounded to that precision. Only Fraction gives exact > results for any arbitrary rational number. Yes, rationals are handy sometimes. > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: off topic but please forgive me me and answer
On Apr 1, 9:44 pm, Steven D'Aprano wrote: > On Thu, 01 Apr 2010 19:49:43 -0500, Tim Chase wrote: > > David Robinow wrote: > >> $ python -c "print 1/2 * 1/2" > >> 0 > > >> But that's not what I learned in grade school. > >> (Maybe I should upgrade to 3.1?) > > > That's because you need to promote one of them to a float so you get a > > floating-point result: > > > >>> 1/2 * 1/2 > > 0 > > >>> 1/2 * 1/2.0 > > 0.0 > > > Oh...wait ;-) > > Tim, I'm sure you know the answer to this, but for the benefit of the > Original Poster, the problem is that you need to promote *both* divisions > to floating point. Otherwise one of them will give int 0, which gives 0.0 > when multiplied by 0.5. > > >>> 1.0/2 * 1/2.0 > > 0.25 > > If you want an exact result when multiplying arbitrary fractions, you > need to avoid floats and decimals and use Fractions: > > >>> Fraction(1, 2)**2 > > Fraction(1, 4) Where do you get that from? > > -- > Steven- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Binary Decimals in Python
On Mar 30, 1:52 pm, MRAB wrote:
> John Nagle wrote:
> > aditya wrote:
> >> On Mar 30, 10:49 am, Raymond Hettinger wrote:
> >>> On Mar 30, 8:13 am, aditya wrote:
>
> To get the decimal representation of a binary number, I can just do
> this:
> int('11',2) # returns 3
> But decimal binary numbers throw a ValueError:
> int('1.1',2) # should return 1.5, throws error instead.
> Is this by design? It seems to me that this is not the correct
> behavior.
> >>> The int() constructor returns integers.
> >>> So, look to float() for non-integral values.
> >>> Binary representation isn't supported yet,
> >>> but we do have hex:
>
> >>> >>> float.fromhex('1.8')
> >>> 1.5
>
> >>> Raymond
>
> >> That looks very elegant, thanks!
>
> > Hex floats are useful because you can get a string representation
> > of the exact value of a binary floating point number. It should
> > always be the case that
>
> > float.fromhex(float.hex(x)) == x
>
> > That's not always true of decimal representations, due to rounding
> > problems.
>
> Floats have a limited length, unlike ints which are virtually unlimited.
gmpy gives you arbitrary precision floats, also.
>
>
>
> > Long discussion of this here: "http://bugs.python.org/issue1580"- Hide
> > quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--
http://mail.python.org/mailman/listinfo/python-list
Re: Binary Decimals in Python
On Mar 30, 10:49 am, Raymond Hettinger wrote:
> On Mar 30, 8:13 am, aditya wrote:
>
> > To get the decimal representation of a binary number, I can just do
> > this:
>
> > int('11',2) # returns 3
>
> > But decimal binary numbers throw a ValueError:
>
> > int('1.1',2) # should return 1.5, throws error instead.
>
> > Is this by design? It seems to me that this is not the correct
> > behavior.
>
> The int() constructor returns integers.
> So, look to float() for non-integral values.
> Binary representation isn't supported yet,
It is supported in the gmpy module.
>>> import gmpy
>>> help(gmpy.mpf)
Help on built-in function mpf in module gmpy:
mpf(...)
mpf(n): builds an mpf object with a numeric value n (n may be any
Python number, or an mpz, mpq, or mpf object) and a
default
precision (in bits) depending on the nature of n
mpf(n,bits=0): as above, but with the specified number of bits (0
means to use default precision, as above)
mpf(s,bits=0,base=10): builds an mpf object from a string s made
up of
digits in the given base, possibly with fraction-part
(with
period as a separator) and/or exponent-part (with exponent
marker 'e' for base<=10, else '@'). If base=256, s must be
a gmpy.mpf portable binary representation as built by the
function gmpy.fbinary (and the .binary method of mpf
objects).
The resulting mpf object is built with a default precision
(in
bits) if bits is 0 or absent, else with the specified
number
of bits.
>>> gmpy.mpf('1.1',0,2)
mpf('1.5e0')
> but we do have hex:
>
> >>> float.fromhex('1.8')
> 1.5
>
> Raymond
--
http://mail.python.org/mailman/listinfo/python-list
Re: OT: Meaning of "monkey"
On Mar 29, 5:31 pm, Gib Bogle wrote: > I prefer to think of myself as a code-ape - I look down on code-monkeys. Why? They have prehensile tails. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT: Meaning of "monkey"
On Mar 26, 2:44 pm, Phlip wrote: > On Mar 26, 6:14 am, Luis M. González wrote: > > > Webmonkey, Greasemonkey, monkey-patching, Tracemonkey, Jägermonkey, > > Spidermonkey, Mono (monkey in spanish), codemonkey, etc, etc, etc... > > > Monkeys everywhere. > > Sorry for the off topic question, but what does "monkey" mean in a > > nerdy-geek context?? > > > Luis > > Better at typing than thinking. Really? I thought it was more of a reference to Eddington, i.e., given enough time even a monkey can type out a program. -- http://mail.python.org/mailman/listinfo/python-list
Re: Have you embraced Python 3.x yet?
On Mar 26, 8:23 am, Harishankar wrote: > Have you people embraced Python 3.x or still with 2.5 or 2.6? 3.1. The only module I use regularly is gmpy and that's one that has been updated. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3.1.2 release candidate
On Mar 6, 4:13 pm, Benjamin Peterson wrote: > On behalf of the Python development team, I'm pleased to announce a release > candidate for the second bugfix release of the Python 3.1 series, Python > 3.1.2. > > This bug fix release fixes numerous issues found in 3.1.1. This release > candidate has been released to solicit testing and feedback over an possible > regressions from 3.1.1. Please consider testing it with your library or > application and reporting an bugs you encounter. This will help make the > final > 3.1.2 release, planned in 2 weeks time, all the more stable. > > The Python 3.1 version series focuses on the stabilization and optimization of > the features and changes that Python 3.0 introduced. For example, the new I/O > system has been rewritten in C for speed. File system APIs that use unicode > strings now handle paths with undecodable bytes in them. Other features > include > an ordered dictionary implementation, a condensed syntax for nested with > statements, and support for ttk Tile in Tkinter. For a more extensive list of > changes in 3.1, seehttp://doc.python.org/3.1/whatsnew/3.1.htmlor Misc/NEWS in > the Python distribution. > > To download Python 3.1.2rc1 visit: > > http://www.python.org/download/releases/3.1.2/ > > A list of changes in 3.1.2rc1 can be found here: > > http://svn.python.org/projects/python/tags/r312rc1/Misc/NEWS > > The 3.1 documentation can be found at: > > http://docs.python.org/3.1 > > Bugs can always be reported to: > > http://bugs.python.org Hey, it finally let me register. Turned out the e-mail to confirm registry was getting marked Spam. I pulled it out of the Spam box and completed the registration. Of course, the reason I needed to register is because IDLE will *still* not end a process properly in Windows. see issue 8093 > > Enjoy! > > -- > Benjamin Peterson > Release Manager > benjamin at python.org > (on behalf of the entire python-dev team and 3.1.2's contributors) -- http://mail.python.org/mailman/listinfo/python-list
Re: Slicing [N::-1]
On Mar 5, 6:34 pm, Gary Herron wrote: > Mensanator wrote: > > On Mar 5, 3:42 pm, Gary Herron wrote: > > >> Mensanator wrote: > > >>> The only way to get a 0 from a reverse range() is to have a bound of > >>> -1. > > >> Not quite. An empty second bound goes all the way to the zero index: > > > Not the same thing. You're using the bounds of the slice index. > > I was refering to the bounds of the range() function. > > >>>> for a in range(9,-9,-1):print(a,end=' ') > > > 9 8 7 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8 > > > To get that to stop at 0, you use a -1 as the bounds: > > >>>> for a in range(9,-1,-1):print(a,end=' ') > > > 9 8 7 6 5 4 3 2 1 0 > > > Your slice notation only works if the last (first?) number in > > the range happens to be 0. What if the range bounds were variables? > > You may still want to force the range's last number to be 0 by > > using a constant like range(a,-1,-1) rather than just take > > the last number of range(a,b,-1) by using slice notation. > > All true and valid of course, but I was just contridicting the "the > ONLY way to get a 0" (emphasis mine) part of the statement. Does it still contradict if you do not use the '::' as the OP requested? > > Gary Herron > > > > > > >> >>> range(9)[2::-1] > >> [2, 1, 0] > > >> Gary Herron- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: Slicing [N::-1]
On Mar 5, 3:42 pm, Gary Herron wrote: > Mensanator wrote: > > > The only way to get a 0 from a reverse range() is to have a bound of > > -1. > > Not quite. An empty second bound goes all the way to the zero index: Not the same thing. You're using the bounds of the slice index. I was refering to the bounds of the range() function. >>> for a in range(9,-9,-1):print(a,end=' ') 9 8 7 6 5 4 3 2 1 0 -1 -2 -3 -4 -5 -6 -7 -8 To get that to stop at 0, you use a -1 as the bounds: >>> for a in range(9,-1,-1):print(a,end=' ') 9 8 7 6 5 4 3 2 1 0 Your slice notation only works if the last (first?) number in the range happens to be 0. What if the range bounds were variables? You may still want to force the range's last number to be 0 by using a constant like range(a,-1,-1) rather than just take the last number of range(a,b,-1) by using slice notation. > > >>> range(9)[2::-1] > [2, 1, 0] > > Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: Slicing [N::-1]
On Mar 5, 12:28 pm, Steven D'Aprano wrote: > On Fri, 05 Mar 2010 18:12:05 +, Arnaud Delobelle wrote: > l = range(10) > l > > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > l[7::-1] > > [7, 6, 5, 4, 3, 2, 1, 0] > [l[i] for i in range(7, -1, -1)] > > [7, 6, 5, 4, 3, 2, 1, 0] > > Where does the first -1 come from? Slices are supposed to have default > values of 0 and len(seq): The only way to get a 0 from a reverse range() is to have a bound of -1. > > >>> l[7::1] > [7, 8, 9] > >>> [l[i] for i in range(7, len(l), 1)] > [7, 8, 9] > >>> [l[i] for i in range(7, len(l), -1)] > > [] > > I don't believe the actual behaviour is documented anywhere. Well, it's implied. If the stopping bound in a reverse range() is greater than the starting bound, you get an empty return. > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Slicing [N::-1]
On Mar 5, 12:01 pm, Joan Miller wrote: > What does a slice as [N::-1] ? Starts at position N and returns all items to the start of the list in reverse order. > > It looks that in the first it reverses the slice and then it shows > only N items, right? Wrong. It shows N+1 items. Remember, counting starts from 0. > > Could you add an example to get the same result without use `::` to > see it more clear? for i in range(8,-1,-1):print(a[i],end=' ') although I doubt this is more clear. > > Thanks in advance -- http://mail.python.org/mailman/listinfo/python-list
Re: _winreg and access registry settings of another user
On Mar 4, 3:24 pm, News123 wrote: > Hi, > > I habe administrator privilege on a window host and would like to write > a script setting some registry entries for other users. Why? Are you writing a virus? > > There are potentially at least two wo ways of doing this: > > 1.) start a subprocess as other user and change the regitrey for > CURRENT_USER > > However I don't know how to start a process (or ideally just a thread) > as another user with python. > > 2.) Load the 'hive' of the othe user and chnage the registry. > > It seems, that one has to load the 'hive' of a different user in order > to have access to somebody eleses registry entries. > > I did not find any documetnation of how to load a 'hive' wit the library > _winreg or another python library/ > > Did anybody else try already something similiar? > > thanks in advance for pointers > > bye > > N -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about typing: ints/floats
On Mar 3, 5:45 pm, Wells wrote: > This seems sort of odd to me: > > >>> a = 1 > >>> a += 1.202 > >>> a > > 2.202 > > Indicates that 'a' was an int that was implicitly casted to a float. > But: > > >>> a = 1 > >>> b = 3 > >>> a / b > > 0 > > This does not implicitly do the casting, it treats 'a' and 'b' as > integers, and the result as well. Not in Python 3.1: Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. >>> a = 1 >>> b = 3 >>> a/b 0. > Changing 'b' to 3.0 will yield a > float as a result (0.1) > > Is there some way to explain the consistency here? Yes, use Python 3.1. > Does python > implicitly change the casting when you add variables of a different > numeric type? Sometimes. Floats and ints are compatible. But this doesn't work: >>> '3' + 1 Traceback (most recent call last): File "", line 1, in '3' + 1 TypeError: Can't convert 'int' object to str implicitly > > Anyway, just curiosity more than anything else. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Re: When will Java go mainstream like Python?
On Feb 25, 6:41 pm, "Alf P. Steinbach" wrote: > * Chris Gray: > > > Lawrence D'Oliveiro writes: > > >> In message , Wanja Gayk wrote: > > >>> Reference counting is about the worst technique for garbage collection. > >> It avoids the need for garbage collection. It means I can write things like > > > I'm by no means an expert, but how does reference counting deal with > > arbitrary long cycles of references (btw I've *written* a simple > > reference counter for a programming language)? > > Generally it doesn't. Some solutions have however been proposed for > std::shared_ptr in C++. None have made it to any noteworthy status, but they > demonstrate that there are more or less practical solutions for the most > common > cases. > > Currently the upshot is that if you need the kind of self-referential > spaghetti > structure (no offense) created by mathematical expressions that refer to each > other, then you've passed beyond what can be handled practically by reference > counting alone or even in combination with cycle handling techniques. > > For that you're better off with some functional language, or Python... ;-) > > > When I asked someone whose knowlege of Java I trust, he said that modern > > Java's do both reference counting and garbage collection. That was 2 or 3 > > years ago. I would have guessed that Python was the same. > > Yes, Python adds general garbage collection to deal with cycles. > > Essentially the reference counting deals efficiently and immediately with > objects created by expression evaluation, while the general garbage collection > deals with cyclic structures. > > But there's no magic: in particular in Java, Python and like languages you > must > still remember to remove references installed in singletons and globals (e.g. > for event notifications), otherwise objects will still be referenced and thus > not garbage collected, causing a memory leak. Is that really considered a leak, a single instance of an uncollected global as opposed to a function that is called millions of times, and each time it's called creates uncollected temporary variables? > > Cheers & hth., > > - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Walking lists
On Feb 25, 7:02 am, Tim Chase wrote:
> Python 3 introduced a variable tuple assignment which I
> suspect[*] would work in this context:
>
> for first, *rest in L: # note the asterisk
> print first
> for x in rest:
> do_stuff(x)
>
> [*] not having py3 on this machine, I can't readily verify this.
Seems fine under 3.1. Cool.
>>> L = ((1,2,3),
(4,),
(5,),
(6,7)
)
>>> for first, *rest in L:
print('first',first,end=' ')
print('rest',rest)
first 1 rest [2, 3]
first 4 rest []
first 5 rest []
first 6 rest [7]
--
http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
On Feb 21, 7:39 pm, rantingrick wrote: > Mensanator snipped: """Yeah, I saw that. Funny that something > important like that wasn't part of the announcement. I notice no > mention of Mac OS, so visiting the website was a complete waste of > time on my part, wasn't it?""" > > Oh Mensanator, why you always so grumpy? Part of the job requirements of a gadfly. > I visited your site a few > years ago and i found it to be a complete waste of my time but you > don't hear me whining about it do you? Did I ever claim it wasn't? > Besides mac is always the last > to get releases (if any) everybody knows that. I'm not complaining about the lack of Mac support, just that it wasn't mentioned in the announcement. > If you drive a porsche > you can't get all upset every time you find yourself on road with pot- > holes, your just not *that* important because you drive a porsche! "You're" not getting the point. > Please (in the future) leave the ranting to me, i'm better at it ;). > > Thanks for the release Noam, i look forward to "test driving" it. > hehe ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
On Feb 21, 12:14 pm, Paul Boddie wrote: > On 21 Feb, 17:32, Mensanator wrote: > > > On Feb 21, 10:30 am, Mensanator wrote: > > > > What versions of Python does it suuport? > > > What OS are supported? > > From the Web site referenced in the announcement (http:// > dreampie.sourceforge.net/): > > """ > # Supports Python 2.5, Python 2.6, Jython 2.5, IronPython 2.6 and > Python 3.1. > # Works on Windows and Linux. > """ Yeah, I saw that. Funny that something important like that wasn't part of the announcement. I notice no mention of Mac OS, so visiting the website was a complete waste of time on my part, wasn't it? > Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
On Feb 21, 10:30�am, Mensanator wrote: > On Feb 21, 3:42 am, Noam Yorav-Raphael wrote:> I'm > pleased to announce DreamPie 1.0 - a new graphical interactive > > Python shell! > > What versions of Python does it suuport? What OS are supported? -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
On Feb 21, 3:42�am, Noam Yorav-Raphael wrote: > I'm pleased to announce DreamPie 1.0 - a new graphical interactive > Python shell! > What versions of Python does it suuport? -- http://mail.python.org/mailman/listinfo/python-list
Re: Stephen -- Bruce?
On Feb 8, 3:02 am, Stefan Behnel wrote: > Mensanator, 05.02.2010 00:36: > > > On Feb 4, 5:13 pm, "Alf P. Steinbach" wrote: > >> What's this about all the Stephen'ses here? > > >> Shouldn't it be Bruce? > > > Of course. We just call everyone Stephen to avoid confusion. > > Some people even manage to adapt the spellings accordingly. > > Stefan You appear to be confused. -- http://mail.python.org/mailman/listinfo/python-list
Re: Stephen -- Bruce?
On Feb 4, 5:13 pm, "Alf P. Steinbach" wrote: > What's this about all the Stephen'ses here? > > Shouldn't it be Bruce? Of course. We just call everyone Stephen to avoid confusion. > > - Alf (wondering) -- http://mail.python.org/mailman/listinfo/python-list
Re: Last M digits of expression A^N
On Feb 5, 2:18 pm, Mark Dickinson wrote: > On Feb 5, 8:14 pm, mukesh tiwari wrote: > > > Hello everyone. I am kind of new to python so pardon me if i sound > > stupid. > > I have to find out the last M digits of expression.One thing i can do > > is (A**N)%M but my A and N are too large (10^100) and M is less than > > 10^5. The other approach was repeated squaring and taking mod of > > expression. Is there any other way to do this in python more faster > > than log N. > > > def power(A,N,M): > > ret=1 > > while(N): > > if(N%2!=0):ret=(ret*A)%M > > A=(A*A)%M > > N=N//2 > > return ret > > The built-in pow function does exactly this, It doesn't do 'exactly' that. M is the number of digits. If you want 17 digits, the third number should 10**17. Using 17 directly will give you a 2-digit answer as shown. Try this instead: >>> pow(12345,67891,10**17) 50553131103515625 > if you give it three > arguments: > > >>> pow(12345, 67891, 17) > 10 > >>> 12345 ** 67891 % 17 > > 10L > > (Though this won't work for negative N.) > > Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 3, 12:36 pm, casevh wrote: > On Feb 3, 10:22 am, Mensanator wrote: > > > Historically, gmpy really didn't have alpha/beta/rc versions and > gmpy.version() just had the version "number" and didn't indicate the > status. If I change it, I'd rather go to "1.1.1rc1" or "1.2.0a0" but > that might break some applications. Ok. And historically, we never had Python 2.5, 2.6, 2.7 & 3.1 to support simultaneously with Windows Xp, Vista and 7 along with Mac OSX 10.4, 10.5,& 10.6 as well as whatever flavors Linnux comes it. Not to mention that there's now two flavors of GMP. How many different permutations do you suppose that is? Thinking about it makes my head hurt. I certainly fell sympathy towards you developers. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 3, 10:37 am, casevh wrote: > On Feb 2, 10:03 pm, Mensanator wrote: > > > > > > > On Feb 2, 12:45 am, casevh wrote: > > > > Everyone, > > > > I'm pleased to annouce the final release of GMPY 1.11. > > > GMPY is a wrapper for the MPIR or GMP multiple-precision > > > arithmetic library. GMPY 1.11 is available for download from: > > > >http://code.google.com/p/gmpy/ > > > > In addition to support for Python 3.x, there are several new > > > features in this release: > > > > - Even faster conversion to/from Python longs. > > > - Performance improvements by reducing function overhead. > > > - Performance improvements by improved caching. > > > - Support for cdivmod, fdivmod, and tdivmod. > > > - Unicode strings are accepted on Python 2.x and 3.x. > > > - Fixed regression in GMPY 1.10 where True/False were no > > > longer recognized. > > > > Changes since 1.11rc1: > > > - Recognizes GMP 5. > > > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > > > Comments on provided binaries > > > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > > > 1.3.1 and will automatically recognize the CPU type and use code > > > optimized for the CPU at runtime. The 64-bit Windows installers were > > > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > > > instructions are included if you want to compile your own binary. > > > > Please report any issues! > > > My previous replies didn't show up. Something to do the .announce > > group? I'll trim that and try again. Sorry if they show up eventually. > > > Two issues: > > > 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply > > > >>> gmpy.version() > > > '1.11' > > > Aren't these different versions? How are we supposed to tell them > > apart? > > Check the name of source tarball? > > gmpy._cvsid() will return the internal source code revision number. > The changes made in each revision number are listed > athttp://code.google.com/p/gmpy/source/list. So, '$Id: gmpy.c 237 2010-01-10 03:46:37Z casevh $' would be Revision 237 on that source list? > > I know some applications check gmpy.version(). I don't know if they'll > work if the format of the string changes. Then gmpy.version() isn't really intended to be a version per se, it's just a level of compatibility for those programs that care? > > > > > 2] Is it true that the only changes since 1.11rc1 are not > > applicable to me since > > > - I'm not using Windows > > - whether it recognizes GMP 5 is moot as GMP 5 cannot be > > compiled on a Mac (according to GMP site) > > Yes. The only change for GMP 5 was to recognize the new version number > when running the tests. Good. > > > > > Is it possible GMP's problems with getting GMP 5 to compile > > are the same ones I had with 3.1 on Snow Leopard? (They bemoan > > not having a set of every Mac system.) Think it would behoove > > me to try it? > > According to comments on GMP's mailing list, the latest snapshot > should work.ftp://ftp.gmplib.org/pub/snapshot/ > I'll have to see if I can get it to work this weekend. I sure hope I don't muck it up after after all the trouble I had getting the previous one to work. Thanks for the links. > > > > > > > casevh -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: GMPY 1.11 released
On Feb 2, 12:45 am, casevh wrote: > Everyone, > > I'm pleased to annouce the final release of GMPY 1.11. > GMPY is a wrapper for the MPIR or GMP multiple-precision > arithmetic library. GMPY 1.11 is available for download from: > > http://code.google.com/p/gmpy/ > > In addition to support for Python 3.x, there are several new > features in this release: > > - Even faster conversion to/from Python longs. > - Performance improvements by reducing function overhead. > - Performance improvements by improved caching. > - Support for cdivmod, fdivmod, and tdivmod. > - Unicode strings are accepted on Python 2.x and 3.x. > - Fixed regression in GMPY 1.10 where True/False were no > longer recognized. > > Changes since 1.11rc1: > - Recognizes GMP 5. > - Bugs fixed in Windows binaries (MPIR 1.3.0rc3 -> 1.3.1). > > Comments on provided binaries > > The 32-bit Windows installers were compiled with MinGW32 using MPIR > 1.3.1 and will automatically recognize the CPU type and use code > optimized for the CPU at runtime. The 64-bit Windows installers were > compiled Microsoft's SDK compilers using MPRI 1.3.1. Detailed > instructions are included if you want to compile your own binary. > > Please report any issues! My previous replies didn't show up. Something to do the .announce group? I'll trim that and try again. Sorry if they show up eventually. Two issues: 1] why does both gmpy 1.11 and gmpy 1.11rc1 both reply >>> gmpy.version() '1.11' Aren't these different versions? How are we supposed to tell them apart? 2] Is it true that the only changes since 1.11rc1 are not applicable to me since - I'm not using Windows - whether it recognizes GMP 5 is moot as GMP 5 cannot be compiled on a Mac (according to GMP site) Is it possible GMP's problems with getting GMP 5 to compile are the same ones I had with 3.1 on Snow Leopard? (They bemoan not having a set of every Mac system.) Think it would behoove me to try it? > > casevh -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 3147 - new .pyc format
On Jan 30, 4:14 pm, John Roth wrote: > PEP 3147 has just been posted, proposing that, beginning in release > 3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a > directory with a .pyr extension. The reason is so that compiled > versions of a program can coexist, which isn't possible now. > > Frankly, I think this is a really good idea, although I've got a few > comments. > > 1. Apple's MAC OS X should be mentioned, since 10.5 (and presumably > 10.6) ship with both Python release 2.3 and 2.5 installed. Mac OSX 10.6 has 2.6 installed. > > 2. I think the proposed logic is too complex. If this is installed in > 3.2, then that release should simply store its .pyc file in the .pyr > directory, without the need for either a command line switch or an > environment variable (both are mentioned in the PEP.) > > 3. Tool support. There are tools that look for the .pyc files; these > need to be upgraded somehow. The ones that ship with Python should, of > course, be fixed with the PEP, but there are others. > > 4. I'm in favor of putting the source in the .pyr directory as well, > but that's got a couple more issues. One is tool support, which is > likely to be worse for source, and the other is some kind of algorithm > for identifying which source goes with which object. > > Summary: I like it, but I think it needs a bit more work. > > John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
On Jan 28, 11:35 am, Ethan Furman wrote: > Steven D'Aprano wrote: > > 4. Python 3 will make you irresistible to women. > > > FALSE > > What?!? Drat!!! Guess I'll have to learn Lisp... ;) Irresisible? Ha! The chicks will think you have a harelip. > > ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with a program
On Jan 28, 12:28 pm, Steven Howe wrote:
> On 01/28/2010 09:49 AM, Jean-Michel Pichavant wrote:
>
>
>
>
>
> > evilweasel wrote:
> >> I will make my question a little more clearer. I have close to 60,000
> >> lines of the data similar to the one I posted. There are various
> >> numbers next to the sequence (this is basically the number of times
> >> the sequence has been found in a particular sample). So, I would need
> >> to ignore the ones containing '0' and write all other sequences
> >> (excluding the number, since it is trivial) in a new text file, in the
> >> following format:
>
> >>> seq59902
> >> TTTATTATATAGT
>
> >>> seq59903
> >> TTTATTTCTTGGCGTTGT
>
> >>> seq59904
> >> TTTGGTTGCCCTGCGTGG
>
> >>> seq59905
> >> TTTGTTTATGGG
>
> >> The number next to 'seq' is the line number of the sequence. When I
> >> run the above program, what I expect is an output file that is similar
> >> to the above output but with the ones containing '0' ignored. But, I
> >> am getting all the sequences printed in the file.
>
> >> Kindly excuse the 'newbieness' of the program. :) I am hoping to
> >> improve in the next few months. Thanks to all those who replied. I
> >> really appreciate it. :)
> > Using regexp may increase readability (if you are familiar with it).
> > What about
>
> > import re
>
> > output = open("sequences1.txt", 'w')
>
> > for index, line in enumerate(open(sys.argv[1], 'r')):
> > match = re.match('(?P[GATC]+)\s+1')
> > if match:
> > output.write('seq%s\n%s\n' % (index, match.group('sequence')))
>
> > Jean-Michel
>
> Finally!
>
> After ready 8 or 9 messages about find a line ending with '1', someone
> suggests Regex.
> It was my first thought.
And as a first thought, it is, of course, wrong.
You don't want lines ending in '1', you want ANY non-'0' amount.
Likewise, you don't want to exclude lines ending in '0' because
you'll end up excluding counts of 10, 20, 30, etc.
You need a regex that extracts ALL the numeric characters at the end
of the
line and exclude those that evaluate to 0.
>
> Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: myths about python 3
On Jan 27, 2:56 pm, John Nagle wrote: > Daniel Fetchinson wrote: > > Hi folks, > > > I was going to write this post for a while because all sorts of myths > > periodically come up on this list about python 3. I don't think the > > posters mean to spread false information on purpose, they simply are > > not aware of the facts. > > > My list is surely incomplete, please feel free to post your favorite > > misconception about python 3 that people periodically state, claim or > > ask about. > > Myths about Python 3: > > 1. Python 3 is supported by major Linux distributions. > > FALSE - most distros are shipping with Python 2.4, or 2.5 at best. So? I use Mac OSX 10.6, not Linux. And that comes with 2.6. Nothing stopped me from adding 3.1. > > 2. Python 3 is supported by multiple Python implementations. > > FALSE - Only CPython supports 3.x. Iron Python, Unladen Swallow, > PyPy, and Jython have all stayed with 2.x versions of Python. So? I only use CPython. > > 3. Python 3 is supported by most 3rd party Python packages. > > FALSE - it's not supported by MySQLdb, OpenSSL, feedparser, etc. So? The only 3rd party module I use is gmpy, and that's been updated to 3.x. > > Arguably, Python 3 has been rejected by the market. Instead, there's > now Python 2.6, Python 2.7, and Python 2.8. Python 3 has turned into > a debacle like Perl 6, now 10 years old. > > That's the reality, Python 3 fanboys. Maybe in *your* world. I'm perfectly happy in my world using 3.1. > > John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: chr(12) Form Feed in Notepad (Windows)
On Jan 15, 6:40 pm, "W. eWatson" wrote: > Tim Chase wrote: > > W. eWatson wrote: > >> Tim Chase wrote: > >>> The pseudo-pipeline comparison would be > > >>> type file.txt > lpt1: > > >>> which would send the raw text file to the printer (assuming it's set > >>> up on LPT1, otherwise, use whatever port it's attached to in your > >>> printer control panel); or are you using something like > > >>> notepad file.txt > >>> File -> Print > > >> I should mention I'm using Windows. I just put chr(12) right in the > >> txt. It's the first character in the next line of the txt file where I > >> want to page forward. Not acquainted with GDI. Maybe I need some > >> sequence of such characters? > > > It's not a matter of you controlling the GDI stuff. Unless you're > > writing directly to the printer device, printing on Windows is done > > (whether by Notepad, gvim, Word, Excel, whatever) into a graphical > > representation which is then shipped off to the printer. So if you're > > printing from Notepad, it's going to print what you see (the little > > square), because Notepad renders to this graphical representation to > > print. If you send the file *directly* to the printer device (bypassing > > the Win32 printing layer), it will send the ^L directly and should eject > > a new page on most printers. > > > -tkc > > I am writing a txt file. It's up to the user to print it using Notepad > or some other tool. I have no idea how to send it directly to the > printer, but I really don't want to furnish that capability in the > program. From Google, The Graphics Device Interface (GDI). Have you considered the possibility that your printer can't print raw text files? I had one that would ONLY print Postscript. Embedding a chr(12) would accomplish nothing, you HAD to use a driver that would translate chr(12) into the appropriate Postcript codes. What you're doing MIGHT work for others with different printers. -- http://mail.python.org/mailman/listinfo/python-list
Re: Clarifications on compiling for Windows
On Jan 8, 12:19 am, peteshinners wrote: > My presentation for Pycon is coming together, but I need to make sure > my information about compiling Python and Python extensions for > Windows is correct. I'm really only experienced with this on the Linux > side of things. > > First of all, is the Windows FAQ fairly up to date? Should people be > referring to section 6 if they are going to build an application with > an embedded Python > interpreter?http://www.python.org/doc/faq/windows/#how-can-i-embed-python-into-a-... > > If I understand correctly, compiled extensions for Python on Windows > should match the compiler that was used to build the interpreter > itself? Is there a list somewhere that shows which version of msvc was > used to compile the recent Python binaries? > > Thank you for feedback. I definitely want to make sure I have this > correct before telling anybody else? You aren't going to try it? -- http://mail.python.org/mailman/listinfo/python-list
Re: it gets worse (was: How do you configure IDLE on a Mac...)
On Jan 5, 4:03 pm, Ned Deily wrote: > In article > <6672dad2-26ba-458b-8075-21bac6506...@e37g2000yqn.googlegroups.com>, Mensanator > wrote: > > [...] > > > > > > > So, for all practical purposes, the macports install is broken also. > > > IDLE simply does not work in an X11 window (you think someone would > > have noticed that). The missing preferences is just the beginning. > > Apparently NONE of the menu item shortcuts work. > > > For example, the Cut, Copy, Paste shortcuts are given as Command-X, > > Command-C and Command-V. But that doesn't work in an X11 window, > > apperently only in an Aqua Tk (parent application appears as IDLE). > > > Of course, I can do Control-X, Control-C and Control-V to do Cut, > > Copy and Paste. Don't know if this works for all shortcuts, but > > I suppose I could just pick them from the menu (and I can bang > > my head against the wall while I'm at it). > > > What do you think, suppose I copy the gmpy built with the macports > > install over to the directory where the python.org version is? Would > > it > > import? If that'll work, I can switch back to using the python.org > > install and use it's version of IDLE. I certainly won't be needing > > distutils once I have a working version of gmpy. > > Let's go back to your original problem, which, if I understand > correctly, was trying to get going with Python 3 and gmpy on OS X 10.6. Right. > (Sorry I was away over the holidays and didn't get a chance to respond > to your original postings at the time.) Hey, no problem. I bought this dingus with the idea I would spend my the holiday time to get it to work. Boy, was I right. > I believe the problems you > originally encountered with installing gmpy were all due to a couple of > problems with building C extension modules on 10.6 when using the > current 3.1.1 OS X python.org. Yeah, I used the Mac disk image for Python 3.1. > Unfortunately, 3.1.1 was released before > 10.6 was so there are a couple of important fixes that haven't yet been > released for 3.1 (but are in the 2.6.4 installer which was released > after 10.6 came out). Fortunately, though, there are simple workarounds > for the problems. Keep in mind, though, that, at the moment, the > python.org installers for OS X are 32-bit only; I just checked, I was told to check sys.maxint but that doesn't exist, I assume it's now sys.maxsize. On the python.org disk image, that returns >>> hex(sys.maxsize) '0x7fff' looks like 32 bits. > that will change in the > future but if you do need a 64-bit Python 3 you'll need to stick to > other solutions like MacPorts for the time being. The macports install of 3.1 gives: >>> hex(sys.maxsize) '07x7fff' so the macports must be 64 bits. > > First, make sure the gmp library you've installed has 32-bit support. Uh, why would I want that? If it comes down to a choice between IDLE and 64 bits, I'll live without IDLE. > If you installed it using MacPorts, check with the file command: > > $ file /opt/local/lib/libgmp.dylib > /opt/local/lib/libgmp.dylib: Mach-O universal binary with 2 architectures > /opt/local/lib/libgmp.dylib (for architecture i386): Mach-O dynamically > linked shared library i386 > /opt/local/lib/libgmp.dylib (for architecture x86_64): Mach-O 64-bit > dynamically linked shared library x86_64 I get /opt/local/lib/libgmpdylib: Mach-0 64-bit dynamically linked shared library x86_64 > > If it doesn't have an i386 variant, reinstall the gmp library from > MacPorts: But I only need that if I want to run the 32 bit version of Python from python.org. If I'm willing to use the 64 bit version from macports, I don't care, right? > > $ sudo port selfupdate # make sure MacPorts is up-to-date > $ sudo port clean gmp > $ sudo port install gmp +universal # install 32-/64-bit variants > > Second, you need to install the MacOSX10.4u SDK because the current > python.org pythons are built with it. Then I'll just not use the download from python.org. Is there a way to uninstall that disk image? > That SDK is included in the Snow > Leopard Xcode installer package but it is not installed by default. > There should be an Xcode.mpkg somewhere, perhaps on your hard disk if > your system came with Snow Leopard factory-installed or perhaps on a > restore DVD. If not, it's on the retail Snow Leopard DVD and can be > downloaded from the Apple Developer site. After launching the Xcode > installer, just select and install the "Mac OS 10.4 Support" package > from the Custom Install menu. > > Third, you need to
Re: twenty years ago Guido created Python
On Jan 5, 8:22 am, n00m wrote: > Stick your English into your ass Most people would say "up your ass". And use a period at the end of the sentence. Got any more funny insults? -- http://mail.python.org/mailman/listinfo/python-list
Re: parsing an Excel formula with the re module
On Jan 5, 12:35 pm, MRAB wrote: > vsoler wrote: > > Hello, > > > I am acessing an Excel file by means of Win 32 COM technology. > > For a given cell, I am able to read its formula. I want to make a map > > of how cells reference one another, how different sheets reference one > > another, how workbooks reference one another, etc. > > > Hence, I need to parse Excel formulas. Can I do it by means only of re > > (regular expressions)? > > > I know that for simple formulas such as "=3*A7+5" it is indeed > > possible. What about complex for formulas that include functions, > > sheet names and possibly other *.xls files? > > > For example "=Book1!A5+8" should be parsed into ["=","Book1", "!", > > "A5","+","8"] > > > Can anybody help? Any suggestions? > > Do you mean "how" or do you really mean "whether", ie, get a list of the > other cells that are referred to by a certain cell, for example, > "=3*A7+5" should give ["A7"] and "=Book1!A5+8" should give ["Book1!A5] Ok, although "Book1" would be the default name of a workbook, with default worksheets labeled "Sheet1". "Sheet2", etc. If I had a worksheet named "Sheety" that wanted to reference a cell on "Sheetx" OF THE SAME WORKBOOK, it would be =Sheet2!A7. If the reference was to a completely different workbook (say Book1 with worksheets labeled "Sheet1", "Sheet2") then the cell might have =[Book1]Sheet1!A7. And don't forget the $'s! You may see =[Book1]Sheet1!$A$7. -- http://mail.python.org/mailman/listinfo/python-list
it gets worse (was: How do you configure IDLE on a Mac...)
On Jan 5, 12:32 am, Ned Deily wrote: > In article > <0d70cb54-3d77-4176-b621-e764ecf61...@26g2000yqo.googlegroups.com>, > > > > > > Mensanator wrote: > > I assume I've been using the IDLE from macports. From the command > > prompt I've > > been typing "idle". This launches a "shell" window which appears to > > have an X11 > > parent application for which there are no "preferences" applicable to > > fonts. > > > However, if I use the quick launcher from the python.org, I get a > > "shell" whose > > parent is named "IDLE"! And that one has a completely different > > preferences, > > one similar the the Windows Configure which allows me to set the font! > > > Now, if I close this shell and start IDLE from the command line again, > > I still > > get a "shell" with an X11 parent, but, lo and behold, the font has > > changed to > > what I had previously set with the IDLE parent. > > > Course, I can't import gmpy, cause the python.org version can't > > compile it, so I > > still have to use the macports install of 3.1, but that's ok, once I > > use > > the IDLE application to set the preferences, I can switch back to the > > X11 version and the preferences will follow. > > The prefs follow because all versions of IDLE use the same (unversioned) > directory for configuration files, ~/.idlerc/. In particular, the > configuration file ~/.idlerc/config-main.cfg contains, among other > things, any changes to the default font. So, if you're successful at > changing it in one version of IDLE, it will likely affect all versions > you have. Note the file is a simple ini format: > > [EditorWindow] > font = monaco > > so you can edit it by hand. Good to know. But, as the subject says... > > BTW, the python.org IDLEs and the Apple-supplied IDLEs use the > system-supplied Aqua (aka Quartz) Tk not the X11 one that MacPorts > builds by default. The MacPorts Tk port does have a "quartz" variant > but that doesn't yet work in 64-bit mode. So, for all practical purposes, the macports install is broken also. IDLE simply does not work in an X11 window (you think someone would have noticed that). The missing preferences is just the beginning. Apparently NONE of the menu item shortcuts work. For example, the Cut, Copy, Paste shortcuts are given as Command-X, Command-C and Command-V. But that doesn't work in an X11 window, apperently only in an Aqua Tk (parent application appears as IDLE). Of course, I can do Control-X, Control-C and Control-V to do Cut, Copy and Paste. Don't know if this works for all shortcuts, but I suppose I could just pick them from the menu (and I can bang my head against the wall while I'm at it). What do you think, suppose I copy the gmpy built with the macports install over to the directory where the python.org version is? Would it import? If that'll work, I can switch back to using the python.org install and use it's version of IDLE. I certainly won't be needing distutils once I have a working version of gmpy. > > -- > Ned Deily, > n...@acm.org- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you configure IDLE on a Mac, seeing as there's no Configure Option...
On Jan 4, 9:17 am, "Alf P. Steinbach" wrote: > * Mensanator: > > > ...because there's no [Options] menu on the shell window? > > > Or at least give me a clue to how to use Courier New font? > > > For some inscrutable reason, depite the plethora of formatting tools, > > someone decided that proportional spaced fonts ought to be the > > default for IDLE. > > Why not just use the Python interpreter, a reasonable programmer's editor and, > if you need it, some debugger. I think I've solved my problem. I'll just say here that at least IDLE is cross-platform AND is part of the "batteries included". I'll be using it on both my new Mac and my desktop PCs running Windows. > > The source code level debugging in IDLE is nothing to write home about. I've got 20 years worth of programs and web pages written with Notepad, so don't let me hear any dissing of IDLE, ok? :-) > > In Windows XP it is just silly: it marks the current line by ordinary text > selection, which (depending on your config, but I think this is default) is > invisible when you're looking at the debugger window for single stepping. You > can see it by switching back to the source code window but that's annoying, > not > very practical. Invisible highlighting of the current line, he he... > > Cheers & hth., > > - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you configure IDLE on a Mac, seeing as there's no Configure Option...
On Jan 4, 10:44 pm, Mensanator wrote: > On Jan 4, 10:05 am, Benjamin Kaplan wrote: > > > On Sun, Jan 3, 2010 at 8:42 PM, Mensanator wrote: > > > ...because there's no [Options] menu on the shell window? > > > > Or at least give me a clue to how to use Courier New font? > > > > For some inscrutable reason, depite the plethora of formatting tools, > > > someone decided that proportional spaced fonts ought to be the > > > default for IDLE. > > > -- > > >http://mail.python.org/mailman/listinfo/python-list > > > Mac Applications don't have "options" menus. They have a "preferences" > > pane which is the second item in the application menu > > Sometimes it's the second item, sometimes it's not > > > (the one that > > takes the name of the active program) and has a keyboard shortcut of > > Cmd-, > > > Apple's user-interface guidelines are pretty specific, so you'll find > > that this works for all native OS X (i.e. not X11) applications. > > Right, it doesn't apply to IDLE which uses X11 Depending on how you launch it. If I type "idle" at a command prompt, I get a shell window whose parent is X11. Here you will get X11 preferences which can't be used to change fonts. If I click the IDLE icon, then I get a shell whose parent is IDLE, not X11 and here you'll find a preferences window similar to the OPTIONS/Configure in Windows. > (there is a preferences > window, > but it doesn't have any font control, unlike stuff like Safari). > > I assume there must be a configuration file. Any idea what that file > is called? I still don't know but apparently as long as I use the IDLE application instead of X11, I can set the font. Thanks for your time. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you configure IDLE on a Mac, seeing as there's no Configure Option...
On Jan 4, 2:25 pm, Ned Deily wrote: > In article > , > Benjamin Kaplan wrote: > > > On Sun, Jan 3, 2010 at 8:42 PM, Mensanator wrote: > > > ...because there's no [Options] menu on the shell window? > > > > Or at least give me a clue to how to use Courier New font? > > > > For some inscrutable reason, depite the plethora of formatting tools, > > > someone decided that proportional spaced fonts ought to be the > > > default for IDLE. > > Mac Applications don't have "options" menus. They have a "preferences" > > pane which is the second item in the application menu (the one that > > takes the name of the active program) and has a keyboard shortcut of > > Cmd-, > > > Apple's user-interface guidelines are pretty specific, so you'll find > > that this works for all native OS X (i.e. not X11) applications. > > But be aware that IDLE on OS X has had various problems with missing > and/or duplicate menu items. IIRC, the current python.org OS X IDLEs > (2.6.4 and 3.1.1) should be OK and you can modify the font via the > Preferences menu No, I already checked. Both system preferences and X11 preferences. > (and currently changed preferences apply to all > versions of IDLE). Note also that there are two different ways to > launch the OS X IDLE. python.org installers put a double-clickable > IDLE.app in /Applications/Python n.x. Yeah, I've still got that one installed, but it has the broken distutils from python.org. > There is also a command-line > "idlen.n" in /Library/Frameworks/Python.framework/Versions/n.n/bin > which, optionally, has a symlink from /usr/local/bin. AARRGGHH!!! I'm pulling my hair out! I haven't been using the IDLE from the broken python.org disk image. I assume I've been using the IDLE from macports. From the command prompt I've been typing "idle". This launches a "shell" window which appears to have an X11 parent application for which there are no "preferences" applicable to fonts. However, if I use the quick launcher from the python.org, I get a "shell" whose parent is named "IDLE"! And that one has a completely different preferences, one similar the the Windows Configure which allows me to set the font! Now, if I close this shell and start IDLE from the command line again, I still get a "shell" with an X11 parent, but, lo and behold, the font has changed to what I had previously set with the IDLE parent. Course, I can't import gmpy, cause the python.org version can't compile it, so I still have to use the macports install of 3.1, but that's ok, once I use the IDLE application to set the preferences, I can switch back to the X11 version and the preferences will follow. Wow! That was fun. Thanks for the help everyone. Don't ask me to explain what I just did, sometimes you just have to let art flow over you. > > -- > Ned Deily, > n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you configure IDLE on a Mac, seeing as there's no Configure Option...
On Jan 4, 10:05 am, Benjamin Kaplan wrote: > On Sun, Jan 3, 2010 at 8:42 PM, Mensanator wrote: > > ...because there's no [Options] menu on the shell window? > > > Or at least give me a clue to how to use Courier New font? > > > For some inscrutable reason, depite the plethora of formatting tools, > > someone decided that proportional spaced fonts ought to be the > > default for IDLE. > > -- > >http://mail.python.org/mailman/listinfo/python-list > > Mac Applications don't have "options" menus. They have a "preferences" > pane which is the second item in the application menu Sometimes it's the second item, sometimes it's not > (the one that > takes the name of the active program) and has a keyboard shortcut of > Cmd-, > > Apple's user-interface guidelines are pretty specific, so you'll find > that this works for all native OS X (i.e. not X11) applications. Right, it doesn't apply to IDLE which uses X11 (there is a preferences window, but it doesn't have any font control, unlike stuff like Safari). I assume there must be a configuration file. Any idea what that file is called? -- http://mail.python.org/mailman/listinfo/python-list
Re: twenty years ago Guido created Python
On Jan 4, 4:20 pm, n00m wrote: > Ben, go away from here. With all your stupids sigs. > Do you think are you original? > You are a stupid animal. > Guido, Tim Peters, Raymond Hettinger are geniuis. > I don't know exactly Python mob. Maybe forgot someone. > You is only a source of depspise for them > You get your everymonth fucking 1000 e sitting here > whom are you teaching? This crowds of animals? > They and you you cant nothing Rants are so much funnier when the speaker can't speak English. -- http://mail.python.org/mailman/listinfo/python-list
How do you configure IDLE on a Mac, seeing as there's no Configure Option...
...because there's no [Options] menu on the shell window? Or at least give me a clue to how to use Courier New font? For some inscrutable reason, depite the plethora of formatting tools, someone decided that proportional spaced fonts ought to be the default for IDLE. -- http://mail.python.org/mailman/listinfo/python-list
Re: Significant whitespace
On Jan 1, 4:02�pm, Dan Stromberg wrote: > I put together a page about significant whitespace (and the lack thereof). The real problem is your use of proportional spaced fonts. > > You're invited to check it out: > > http://stromberg.dnsalias.org/~dstromberg/significant-whitespace.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Significant whitespace
On Jan 2, 4:19 pm, Emile van Sebille wrote: > On 1/1/2010 5:05 PM Steven D'Aprano said... > > > In Python terms, imagine if we could write > > > foriinrange(10): > > > instead of the usual > > > for i in range(10): > > > Since the colon makes it unambiguous that it is some sort of block > > construct, and it starts with "for", it must be a for loop. Pretty > > horrible, yes? > > Yes -- early on I got stung by something similar. My first programming > job (1977?) was working in a basic dialect called Buisness Basic Level > II (BBII). To delete a record in the file you used a remove statement. > White space on the line was optional, allowing you to write lines like > '100 remove(1,key=k$)' and '100 fori=1to10'. REM was how a remark > statement began, which allowed statements like "100 REM comment". I was > sent on-site to a customer running the prior version (BBI). I didn't > realize the REMOVE command changed between versions from REKEY, and it > was only after a more experienced programmer co-wroker pointed out that > my REMOVE statement was being interpreted as a REM that I finally found > the bug I'd created. Better than the other way 'round, eh? > > Manuals and documentation, while often lacking, are as often underrated. > > Emile -- http://mail.python.org/mailman/listinfo/python-list
Re: the need for 64 bits
On Dec 28, 9:04 pm, Roy Smith wrote: > In article <034921cf$0$1277$c3e8...@news.astraweb.com>, > Steven D'Aprano wrote: > > > On Sun, 27 Dec 2009 22:50:11 -0800, Mensanator wrote: > > > > I routinely use large numbers in my Collatz Conjecture work. > > > > Really large. As in a quarter million bits. > > > That's not large. *THIS* is a large number: > > >http://en.wikipedia.org/wiki/Graham's_number > > > Unless you need special notation merely to describe how to generate the > > number, it's not a large number. > > And then, after 'e was done nailing my head to the floor, he said, > "Consider an n-dimensional hypercube". It was at that point that I knew he > was talking about a really big number. I remember it more like: And then, after 'e was done nailing my head to the floor, he said, "Consider an n-dimensional hypercube, Eric". It was at that point that I knew he was talking about a really big number, so I said "My names not Eric." -- http://mail.python.org/mailman/listinfo/python-list
Re: the need for 64 bits
On Dec 28, 6:48 pm, Steven D'Aprano wrote: > On Mon, 28 Dec 2009 16:27:58 -0800, Mensanator wrote: > > And if I were ice fishing on the retention pond near my house and > > someone came up and said "You know, blue whales can achieve a length of > > up to 108 ft.", he would leave in a basket. > > Come and see the violence inherent in the system! Help, help! I'm being > repressed! > > Bringing it back to Python'ly yrs, :-) > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: the need for 64 bits
On Dec 28, 4:44 pm, Steven D'Aprano wrote: > On Sun, 27 Dec 2009 22:50:11 -0800, Mensanator wrote: > > I routinely use large numbers in my Collatz Conjecture work. > > > Really large. As in a quarter million bits. > > That's not large. Perhaps not in the absolute sense. But it's large compared to 32-bit or 64-bit integers. Probably most people's applications don't come anywhere near the limit of what can be represented in long integers. Numbers near such a limit are "large" for practical purposes. > *THIS* is a large number: > > http://en.wikipedia.org/wiki/Graham's_number Right. And if I were ice fishing on the retention pond near my house and someone came up and said "You know, blue whales can achieve a length of up to 108 ft.", he would leave in a basket. > > Unless you need special notation merely to describe how to generate the > number, it's not a large number. I'm only interested in numbers I can represent in memory and run through the Collatz process. Interesting as they are, these truly "large" numbers are of no use to me. > > -- > Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: the need for 64 bits
On Dec 28, 9:08 am, casevh wrote: > On Dec 28, 2:13 am, Mark Dickinson wrote: > > > > > > > On Dec 28, 6:50 am, Mensanator wrote: > > > > But with a 64-bit processor, that limitation no longer stops me. > > > > i: 11 bits: 10,460,353,205 decimals: 3,148,880,080 > > > i: 12 bits: 94,143,178,829 decimals: 28,339,920,715 > > > > Wow! 94 billion bits! 28 billion decimal digits! > > > > Of course, once one wall falls, you get to go up against the next > > > one. > > > For generation 13, I get: > > > > gmp: overflow in mpz type > > > Abort trap > > > > Hmm, not sure what "overflow" means in this context, but I suspect > > > it ran out of memory, I probably should have gotten the MacBook Pro > > > with 8 GB of ram. But then, maybe it wouldn't help. > > > I don't think this was due to running out of memory: it looks like > > gmp uses the 'int' C type to count the number of limbs in an mpz, > > which would make the maximum number of bits 2**31 * 64, or around 137 > > billion, on a typical 64-bit machine. Maybe there's a configure > > option to change this? > > > For Python longs, the number of limbs is stored as a signed size_t > > type, so on a 64-bit machine memory really is the only limitation. > > > -- > > Mark > > Based on comments on the GMP website, the maximum number of bits on a > 64-bit platform is limited to 2**37 or 41 billion decimal digits. I guess that eliminates ever finding generation 13. :-) And I haven't checked the 12th generation number yet. I can calculate it, but I don't if I can actually run it through the Collatz process. Being a Mersenne Number, the excursion (maximum value reached in the sequence) will be about 1.585 times as many bits as the starting number. If that fails with genertaion 12, then finding generation 13 is moot. > A number this size requires 16GB of RAM. Ah, the 8 GB Mac wouldn't have helped. Glad I didn't spend the extra $1000. > A future version of GMP (5.x) > is supposed to remove that limit and also work well with disk-based > storage. Something to look forward to. Thanks, guys. > > casevh -- http://mail.python.org/mailman/listinfo/python-list
the need for 64 bits
I routinely use large numbers in my Collatz Conjecture work. Really large. As in a quarter million bits. You wouldn't think that the processor would make all that much difference. But using the number is a doddle. The real trick is getting there. There is a limitation that few encounter. In an exponential, the exponent is limited to 32 bits, else you get an "outrageous exponent" error. But I assume that was due to integer size, that if you have 64 bit integers, the limit of the exponent ought to also be 64 bits. With my new MacBook replacing my old Windows laptop, I can try this. Using this function (which grows really large, really quick)... 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 i: 1 bits: 5 decimals:2 i: 2 bits: 29 decimals:9 i: 3 bits:245 decimals: 74 i: 4 bits: 2,189 decimals: 659 i: 5 bits: 19,685 decimals:5,926 i: 6 bits:177,149 decimals: 53,328 i: 7 bits: 1,594,325 decimals: 479,940 i: 8 bits: 14,348,909 decimals:4,319,453 i: 9 bits:129,140,165 decimals: 38,875,064 i: 10 bits: 1,162,261,469 decimals: 349,875,565 … my Windows/32-bit machine can't get past generation 10 without getting "outrageous exponent". But with a 64-bit processor, that limitation no longer stops me. i: 11 bits: 10,460,353,205 decimals: 3,148,880,080 i: 12 bits: 94,143,178,829 decimals: 28,339,920,715 Wow! 94 billion bits! 28 billion decimal digits! Of course, once one wall falls, you get to go up against the next one. For generation 13, I get: gmp: overflow in mpz type Abort trap Hmm, not sure what "overflow" means in this context, but I suspect it ran out of memory, I probably should have gotten the MacBook Pro with 8 GB of ram. But then, maybe it wouldn't help. Regardless, my window of research has gotten slightly larger. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1? -SOLVED!
On Dec 27, 8:19 am, Steve Holden wrote: > Mensanator wrote: > > On Dec 26, 10:02 pm, Benjamin Kaplan wrote: > >> On Sat, Dec 26, 2009 at 9:21 PM, Mensanator wrote: > >>> On Dec 26, 4:20 pm, Mensanator wrote: > >>>> On Dec 26, 3:57 pm, Benjamin Kaplan wrote: > >>>>> On Sat, Dec 26, 2009 at 4:36 PM, Mensanator wrote: > >>>>>> I guess the point here is NEVER use the disk image on python.org, > >>>>>> ALWAYS use macports to install Python 3.1. > >>>>>> At least until python.org fixes it. > >>>>> Have you filed a bug report on this? > >>>> I will. > >>> ...NOT! > >>> *I* won't be filling a bug report because *I* am still > >>> locked out of python.org (it won't let me register). > >>> Sorry, but this is beyond my control. All I can do is > >>> report problems on comp.lang.python. > >>> -- > >> Alright. I filed it.http://bugs.python.org/issue7580 > > > Thank you! I would hate to see anyone else go through this hassle. > > >>>http://mail.python.org/mailman/listinfo/python-list > > Perhpas you would do me a favor and report the problem about being > unable to register on bugs.python.org to the pydotorg webmaster list > (pydotorg at python dot org) and let me know if you get any result. Ok, i reported it. > > Please be sure to identify explicitly what the problem is and on which > page(s) it occurs. It wasn't any page per se, it was supposed to send an e-mail for me to follow up the registration. I never got any e-mail. > > Thanks > Steve > -- > Steve Holden +1 571 484 6266 +1 800 494 3119 > PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ > Holden Web LLC http://www.holdenweb.com/ > UPCOMING EVENTS: http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1? -SOLVED!
On Dec 26, 10:02 pm, Benjamin Kaplan wrote: > On Sat, Dec 26, 2009 at 9:21 PM, Mensanator wrote: > > On Dec 26, 4:20 pm, Mensanator wrote: > >> On Dec 26, 3:57 pm, Benjamin Kaplan wrote: > > >> > On Sat, Dec 26, 2009 at 4:36 PM, Mensanator wrote: > > >> > > I guess the point here is NEVER use the disk image on python.org, > >> > > ALWAYS use macports to install Python 3.1. > > >> > > At least until python.org fixes it. > > >> > Have you filed a bug report on this? > > >> I will. > > > ...NOT! > > > *I* won't be filling a bug report because *I* am still > > locked out of python.org (it won't let me register). > > > Sorry, but this is beyond my control. All I can do is > > report problems on comp.lang.python. > > -- > > Alright. I filed it.http://bugs.python.org/issue7580 Thank you! I would hate to see anyone else go through this hassle. > > > > >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1? -SOLVED!
On Dec 26, 4:20�pm, Mensanator wrote: > On Dec 26, 3:57�pm, Benjamin Kaplan wrote: > > > On Sat, Dec 26, 2009 at 4:36 PM, Mensanator wrote: > > > > I guess the point here is NEVER use the disk image on python.org, > > > ALWAYS use macports to install Python 3.1. > > > > At least until python.org fixes it. > > > Have you filed a bug report on this? > > I will. ...NOT! *I* won't be filling a bug report because *I* am still locked out of python.org (it won't let me register). Sorry, but this is beyond my control. All I can do is report problems on comp.lang.python. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1? -SOLVED!
On Dec 26, 3:57 pm, Benjamin Kaplan wrote: > On Sat, Dec 26, 2009 at 4:36 PM, Mensanator wrote: > > > I guess the point here is NEVER use the disk image on python.org, > > ALWAYS use macports to install Python 3.1. > > > At least until python.org fixes it. > > Have you filed a bug report on this? I will. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1? -SOLVED!
On Dec 26, 2:07 pm, Benjamin Kaplan wrote: PROBLEM RESOLVED! Yes, it does appear that the disk image on pytho.ord is defective (maybe they made the image from an obsolete version?) I installed Python 3.1 from macports and everything seems to work now. (I never would have figured it out, although installing from macports was on my long erm list of things to try). # after macports install of Python 3.1 $ python setup.py install running install running build running build_ext building 'gmpy' extension creating build/temp.macosx-10.6-i386-3.1 creating build/temp.macosx-10.6-i386-3.1/src /usr/bin/gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./src -I/opt/local/include -I/ opt/local/Library/Frameworks/Python.framework/Versions/3.1/include/ python3.1 -c src/gmpy.c -o build/temp.macosx-10.6-i386-3.1/src/gmpy.o creating build/lib.macosx-10.6-i386-3.1 /usr/bin/gcc-4.2 -L/opt/local/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.6-i386-3.1/src/gmpy.o -L/opt/local/lib -lgmp -o build/lib.macosx-10.6-i386-3.1/gmpy.so running install_lib copying build/lib.macosx-10.6-i386-3.1/gmpy.so -> /opt/local/Library/ Frameworks/Python.framework/Versions/3.1/lib/python3.1/site-packages error: /opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/ python3.1/site-packages/gmpy.so: Permission denied # minor glitch, easily resolveable $ sudo python setup.py install running install running build running build_ext running install_lib copying build/lib.macosx-10.6-i386-3.1/gmpy.so -> /opt/local/Library/ Frameworks/Python.framework/Versions/3.1/lib/python3.1/site-packages running install_egg_info Writing /opt/local/Library/Frameworks/Python.framework/Versions/3.1/ lib/python3.1/site-packages/gmpy-1.11rc1-py3.1.egg-info $ python Python 3.1.1 (r311:74480, Dec 26 2009, 15:02:38) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import gmpy >>> gmpy.version() '1.11' >>> [2]+ Stopped pytho $ python test3/gmpy_test.py Unit tests for gmpy 1.11 on Python 3.1.1 (r311:74480, Dec 26 2009, 15:02:38) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) gmpy_test_cvr 148 tests, 0 failures gmpy_test_rnd 26 tests, 0 failures . . . 1500 tests in 42 items. 1500 passed and 0 failed. Test passed. Thanks guys, you saved my Christmas! I was afraid this MacBook was going to turn into a waste of money. I guess the point here is NEVER use the disk image on python.org, ALWAYS use macports to install Python 3.1. At least until python.org fixes it. -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1?
On Dec 25, 8:59�pm, Benjamin Kaplan wrote: > On Fri, Dec 25, 2009 at 1:19 PM, Mensanator wrote: > > On Dec 25, 9:25�am, Benjamin Kaplan wrote: > >> On Fri, Dec 25, 2009 at 1:48 AM, Mensanator wrote: > >> > On Dec 24, 10:18�pm, Benjamin Kaplan wrote: > >> >> On Thu, Dec 24, 2009 at 9:11 PM, Mensanator wrote: > >> >> > Ok, so I got a MacBook Air. > > >> >> > Has OS X 10.6 (Snow Leopard) and Python 2.6.1 already installed. > > >> >> > So I install Xcode, download macports and download gmpy-1.11rc1. > > >> >> > Following the instructions in mac_build.txt, I do the following: > > >> >> > - sudo /opt/local/bin/port install gmp > > >> >> > This works fine. > > >> >> > Then I do > > >> >> > - python setup.py install > > >> >> > This also works (a few warnings, but nothing looked serious). > > >> >> > Python 2.6.1 (r261:67515, Jul �7 2009, 23:51:51) > >> >> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > >> >> > Type "help", "copyright", "credits" or "license" for more information. > >> >> >>>> import gmpy > >> >> >>>> gmpy.version() > >> >> > '1.11' > > >> >> > python gmpy_test.py > >> >> > Unit tests for gmpy 1.11 > >> >> > � �on Python 2.6.1 (r261:67515, Jul �7 2009, 23:51:51) > >> >> > [GCC 4.2.1 (Apple Inc. build 5646)] > >> >> > Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) > >> >> > gmpy_test_cvr 151 tests, 0 failures > >> >> > . > >> >> > . > >> >> > . > >> >> > �25 tests in gmpy_test_rnd.__test__.rand > >> >> > 1469 tests in 42 items. > >> >> > 1469 passed and 0 failed. > >> >> > Test passed. > > >> >> > Looks like a viable gmpy module for 2.6. > > >> >> > What do I do AFTER I install Python 3.1? Just running python3.1 from > >> >> > the > >> >> > same directory doesn't work. > > >> >> > I've spent the last 5 days trying to figure that out. I hosed it so > >> >> > bad > >> >> > I somehow wrecked the 2.6 version to the point where it won't even > >> >> > load. > > >> >> > I just got done doing a factory restore of the entire OS to undo > >> >> > everything > >> >> > I did. Re-did all the above and got it back working. Haven't re- > >> >> > installed 3.1 > >> >> > yet. > > >> >> > Anbody have any idea how to make this work? > > >> >> Did you run setup.py with python3? Python 3.1 won't install itself as > >> >> the default python install for compatibility reasons so you have to > >> >> run "python3 install setup.py" to install it for that version of > >> >> python. > > >> > I wondered why there was both python3 and python3.1 in the bin > >> > directory. > > >> > But why, when I type... > > >> > $ python3 > > >> > ...do I get... > > >> > Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) > >> > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > >> > Type "help", "copyright", "credits" or "license" for more information. > > >> > [1]+ �Stopped � � � � � � � � python3 > > >> > I get the same result with python3.1. > > >> > So, no, trying python3 is of no help, same errors as before. > >> > There's hundreds of them, but they start out > > >> > $ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3 > >> > setup.py install > >> > running install > >> > running build > >> > running build_ext > >> > building 'gmpy' extension > >> > creating build/temp.macosx-10.3-fat-3.1 > >> > creating build/temp.macosx-10.3-fat-3.1/src > >> > Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ > >> > MacOSX10.4u.sdk > >> > Please check your Xcode installation > >> > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > >> > fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/ > >&g
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1?
On Dec 25, 9:25 am, Benjamin Kaplan wrote: > On Fri, Dec 25, 2009 at 1:48 AM, Mensanator wrote: > > On Dec 24, 10:18 pm, Benjamin Kaplan wrote: > >> On Thu, Dec 24, 2009 at 9:11 PM, Mensanator wrote: > >> > Ok, so I got a MacBook Air. > > >> > Has OS X 10.6 (Snow Leopard) and Python 2.6.1 already installed. > > >> > So I install Xcode, download macports and download gmpy-1.11rc1. > > >> > Following the instructions in mac_build.txt, I do the following: > > >> > - sudo /opt/local/bin/port install gmp > > >> > This works fine. > > >> > Then I do > > >> > - python setup.py install > > >> > This also works (a few warnings, but nothing looked serious). > > >> > Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > >> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > >> > Type "help", "copyright", "credits" or "license" for more information. > >> >>>> import gmpy > >> >>>> gmpy.version() > >> > '1.11' > > >> > python gmpy_test.py > >> > Unit tests for gmpy 1.11 > >> > on Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > >> > [GCC 4.2.1 (Apple Inc. build 5646)] > >> > Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) > >> > gmpy_test_cvr 151 tests, 0 failures > >> > . > >> > . > >> > . > >> > 25 tests in gmpy_test_rnd.__test__.rand > >> > 1469 tests in 42 items. > >> > 1469 passed and 0 failed. > >> > Test passed. > > >> > Looks like a viable gmpy module for 2.6. > > >> > What do I do AFTER I install Python 3.1? Just running python3.1 from > >> > the > >> > same directory doesn't work. > > >> > I've spent the last 5 days trying to figure that out. I hosed it so > >> > bad > >> > I somehow wrecked the 2.6 version to the point where it won't even > >> > load. > > >> > I just got done doing a factory restore of the entire OS to undo > >> > everything > >> > I did. Re-did all the above and got it back working. Haven't re- > >> > installed 3.1 > >> > yet. > > >> > Anbody have any idea how to make this work? > > >> Did you run setup.py with python3? Python 3.1 won't install itself as > >> the default python install for compatibility reasons so you have to > >> run "python3 install setup.py" to install it for that version of > >> python. > > > I wondered why there was both python3 and python3.1 in the bin > > directory. > > > But why, when I type... > > > $ python3 > > > ...do I get... > > > Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) > > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > > [1]+ Stopped python3 > > > I get the same result with python3.1. > > > So, no, trying python3 is of no help, same errors as before. > > There's hundreds of them, but they start out > > > $ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3 > > setup.py install > > running install > > running build > > running build_ext > > building 'gmpy' extension > > creating build/temp.macosx-10.3-fat-3.1 > > creating build/temp.macosx-10.3-fat-3.1/src > > Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ > > MacOSX10.4u.sdk > > Please check your Xcode installation > > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > > fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/ > > opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/ > > include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/ > > gmpy.o > > In file included from src/gmpy.c:206: > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:11:20: error: limits.h: No such file or directory > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:14:2: error: #error "Something's broken. UCHAR_MAX should be > > defined in limits.h." > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:18: > > > Any other ideas? Do I have to install a separate Python 3? > > That's not a Python 3 problem. It appears to be a problem in the build script. > > > Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ > > MacOSX10.4u.sdk > > My guess would be you're on Snow Leopard while the original developer > is either on Tiger or Leopard. The script wants to use the 10.4 SDK > but Apple only includes the SDKs for the latest 2 versions of OS X. I just thought of something. Why I am able to do the build for python 2.6? Wouldn't that also fail for lack of a 10.4 SDK? > > > > > > >> > -- > >> >http://mail.python.org/mailman/listinfo/python-list > > > -- > >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1?
On Dec 25, 9:25 am, Benjamin Kaplan wrote: > On Fri, Dec 25, 2009 at 1:48 AM, Mensanator wrote: > > On Dec 24, 10:18 pm, Benjamin Kaplan wrote: > >> On Thu, Dec 24, 2009 at 9:11 PM, Mensanator wrote: > >> > Ok, so I got a MacBook Air. > > >> > Has OS X 10.6 (Snow Leopard) and Python 2.6.1 already installed. > > >> > So I install Xcode, download macports and download gmpy-1.11rc1. > > >> > Following the instructions in mac_build.txt, I do the following: > > >> > - sudo /opt/local/bin/port install gmp > > >> > This works fine. > > >> > Then I do > > >> > - python setup.py install > > >> > This also works (a few warnings, but nothing looked serious). > > >> > Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > >> > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > >> > Type "help", "copyright", "credits" or "license" for more information. > >> >>>> import gmpy > >> >>>> gmpy.version() > >> > '1.11' > > >> > python gmpy_test.py > >> > Unit tests for gmpy 1.11 > >> > on Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > >> > [GCC 4.2.1 (Apple Inc. build 5646)] > >> > Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) > >> > gmpy_test_cvr 151 tests, 0 failures > >> > . > >> > . > >> > . > >> > 25 tests in gmpy_test_rnd.__test__.rand > >> > 1469 tests in 42 items. > >> > 1469 passed and 0 failed. > >> > Test passed. > > >> > Looks like a viable gmpy module for 2.6. > > >> > What do I do AFTER I install Python 3.1? Just running python3.1 from > >> > the > >> > same directory doesn't work. > > >> > I've spent the last 5 days trying to figure that out. I hosed it so > >> > bad > >> > I somehow wrecked the 2.6 version to the point where it won't even > >> > load. > > >> > I just got done doing a factory restore of the entire OS to undo > >> > everything > >> > I did. Re-did all the above and got it back working. Haven't re- > >> > installed 3.1 > >> > yet. > > >> > Anbody have any idea how to make this work? > > >> Did you run setup.py with python3? Python 3.1 won't install itself as > >> the default python install for compatibility reasons so you have to > >> run "python3 install setup.py" to install it for that version of > >> python. > > > I wondered why there was both python3 and python3.1 in the bin > > directory. > > > But why, when I type... > > > $ python3 > > > ...do I get... > > > Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) > > [GCC 4.0.1 (Apple Inc. build 5493)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > > [1]+ Stopped python3 > > > I get the same result with python3.1. > > > So, no, trying python3 is of no help, same errors as before. > > There's hundreds of them, but they start out > > > $ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3 > > setup.py install > > running install > > running build > > running build_ext > > building 'gmpy' extension > > creating build/temp.macosx-10.3-fat-3.1 > > creating build/temp.macosx-10.3-fat-3.1/src > > Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ > > MacOSX10.4u.sdk > > Please check your Xcode installation > > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - > > fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/ > > opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/ > > include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/ > > gmpy.o > > In file included from src/gmpy.c:206: > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:11:20: error: limits.h: No such file or directory > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:14:2: error: #error "Something's broken. UCHAR_MAX should be > > defined in limits.h." > > /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ > > Python.h:18: > > > Any other ideas? Do I have to install a separate Python 3? > > That's not a Python 3 problem. It appears to be a problem in the build script. > > > Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ > > MacOSX10.4u.sdk > > My guess would be you're on Snow Leopard Yes, this machine has OS X 10.6. > while the original developer > is either on Tiger or Leopard. The script wants to use the 10.4 SDK > but Apple only includes the SDKs for the latest 2 versions of OS X. Is there any easy way to fix the build script? Is there a hard way? Which files comprise the build script? Thanks for your help. > > > > > > >> > -- > >> >http://mail.python.org/mailman/listinfo/python-list > > > -- > >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1?
On Dec 24, 10:18 pm, Benjamin Kaplan wrote: > On Thu, Dec 24, 2009 at 9:11 PM, Mensanator wrote: > > Ok, so I got a MacBook Air. > > > Has OS X 10.6 (Snow Leopard) and Python 2.6.1 already installed. > > > So I install Xcode, download macports and download gmpy-1.11rc1. > > > Following the instructions in mac_build.txt, I do the following: > > > - sudo /opt/local/bin/port install gmp > > > This works fine. > > > Then I do > > > - python setup.py install > > > This also works (a few warnings, but nothing looked serious). > > > Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > > [GCC 4.2.1 (Apple Inc. build 5646)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > >>>> import gmpy > >>>> gmpy.version() > > '1.11' > > > python gmpy_test.py > > Unit tests for gmpy 1.11 > > on Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) > > [GCC 4.2.1 (Apple Inc. build 5646)] > > Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) > > gmpy_test_cvr 151 tests, 0 failures > > . > > . > > . > > 25 tests in gmpy_test_rnd.__test__.rand > > 1469 tests in 42 items. > > 1469 passed and 0 failed. > > Test passed. > > > Looks like a viable gmpy module for 2.6. > > > What do I do AFTER I install Python 3.1? Just running python3.1 from > > the > > same directory doesn't work. > > > I've spent the last 5 days trying to figure that out. I hosed it so > > bad > > I somehow wrecked the 2.6 version to the point where it won't even > > load. > > > I just got done doing a factory restore of the entire OS to undo > > everything > > I did. Re-did all the above and got it back working. Haven't re- > > installed 3.1 > > yet. > > > Anbody have any idea how to make this work? > > Did you run setup.py with python3? Python 3.1 won't install itself as > the default python install for compatibility reasons so you have to > run "python3 install setup.py" to install it for that version of > python. I wondered why there was both python3 and python3.1 in the bin directory. But why, when I type... $ python3 ...do I get... Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> [1]+ Stopped python3 I get the same result with python3.1. So, no, trying python3 is of no help, same errors as before. There's hundreds of them, but they start out $ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3 setup.py install running install running build running build_ext building 'gmpy' extension creating build/temp.macosx-10.3-fat-3.1 creating build/temp.macosx-10.3-fat-3.1/src Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/ MacOSX10.4u.sdk Please check your Xcode installation gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/ opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/ include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/ gmpy.o In file included from src/gmpy.c:206: /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ Python.h:11:20: error: limits.h: No such file or directory /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ Python.h:14:2: error: #error "Something's broken. UCHAR_MAX should be defined in limits.h." /Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/ Python.h:18: Any other ideas? Do I have to install a separate Python 3? > > > > > -- > >http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
How do I install GMPY 1.11 on a Mac with OS X 10.6 and Python 3.1?
Ok, so I got a MacBook Air. Has OS X 10.6 (Snow Leopard) and Python 2.6.1 already installed. So I install Xcode, download macports and download gmpy-1.11rc1. Following the instructions in mac_build.txt, I do the following: - sudo /opt/local/bin/port install gmp This works fine. Then I do - python setup.py install This also works (a few warnings, but nothing looked serious). Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import gmpy >>> gmpy.version() '1.11' python gmpy_test.py Unit tests for gmpy 1.11 on Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] Testing gmpy 1.11 (GMP 4.3.1), default caching (100, 128) gmpy_test_cvr 151 tests, 0 failures . . . 25 tests in gmpy_test_rnd.__test__.rand 1469 tests in 42 items. 1469 passed and 0 failed. Test passed. Looks like a viable gmpy module for 2.6. What do I do AFTER I install Python 3.1? Just running python3.1 from the same directory doesn't work. I've spent the last 5 days trying to figure that out. I hosed it so bad I somehow wrecked the 2.6 version to the point where it won't even load. I just got done doing a factory restore of the entire OS to undo everything I did. Re-did all the above and got it back working. Haven't re- installed 3.1 yet. Anbody have any idea how to make this work? -- http://mail.python.org/mailman/listinfo/python-list
Re: force non-exponential representation for Decimal?
On Dec 23, 4:03 am, jh...@gmx.de wrote:
> (cc-ing the list)
>
> > > Is there a convenient way to force a decimal.Decimal representation to
> > not use exponential representation?
>
> > Which Python version are you using? For Python 2.6 (and 3.1), the
> > answer's yes. For earlier Python verions, I don't think so. In
> > Python 2.6, use new-style formatting with the 'f' modifier:
>
> > >>> '{0:f}'.format(Decimal('1e-100'))
> > '0.0001'
> > >>> '{0:f}'.format(Decimal('1e100'))
> > '10000'
>
> Unfortunately, I'm still using Python 2.4 so I can't go that way (at least
> not anytime soon, this is a production environment).
But you can get gmpy for Python 2.4. And then you can do:
>>> c = gmpy.mpf('2.343000837483727772E-19')
>>> c
mpf('2.3430008374837278e-19')
>>> help(gmpy.fdigits)
Help on built-in function fdigits in module gmpy:
fdigits(...)
fdigits(x, base=10, digs=0, mine=0, maxe=-1, opts=0): formats x,
which is an mpf or else gets coerced to one.
Returns up to digs digits in the given base (if digs is 0, as many
digits as are available), but no more than available given x's
precision; the resulting string is formatted in fixed point
if the exponent is >=mine and <=maxe, else in exponential (the
exponent-separator is 'e' for base up to 10, else '@' -- the
exponent is always output as a signed, base-10 integer). If opts
has bit 1 set, the whole is wrapped in 'gmpy.mpf(...)', to ease
later approximate reconstruction via builtin function eval
(Or, in just mpf(...) if gmpy.set_tagoff(1) was called).
If opts has bit 2 set, then opts bit 1, mine, and maxe, are
ignored; the result is then a 2-element tuple, first element
the raw string of base-digits without formatting, second the
exponent in base as a Python int.
>>> gmpy.fdigits(c,10,30,-30,30)
'0.0023430008374837278'
>
> > For earlier Python versions, you can manipulate the output string as
> > you describe, or you can extract the raw components of the Decimal
> > instance (e.g. with the as_tuple() method) and construct a string
> > directly from those. You might be also be able to extract code for
> > the '{:f}' formatting from the Python 2.6 Decimal source (Lib/
> > decimal.py), but it's fairly convoluted.
>
> Thanks a lot for the hints, I'll look into that.
>
> Holger
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unterhttp://portal.gmx.net/de/go/maxdome01
--
http://mail.python.org/mailman/listinfo/python-list
Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments
On Dec 19, 12:21 am, "Alf P. Steinbach" wrote: > * Mensanator: > > > > >> That said, and a bit off-tangent to your comment's main thrust, the time > >> spent > >> on coding that repeated-division-by-2 optimization would, I think, be > >> better > >> spent googling "Collatz Conjecture" -- avoiding writing /any/ code. ;-) > > > Ha! I know more about Collatz than you can ever find by Googling! > > And how did I achieve that? By writing such code. Be a good boy and > > maybe I'll show you how to do Ulam's Spiral with Turtle Graphics. > > It's probably good for you that you know so much about Collatz. > > I fail to see the relevance to anything. No kidding. Here let me explain it: You said my time would be better spent googling "Collatz Conjecture". I said I know more than can be found by googling. Therefore, it follows that my time could NOT be better spent googling. Thus, your staement is shown to be false. QED > > Cheers & hth., > > - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments
On Dec 18, 6:25 pm, "Alf P. Steinbach" wrote: > * Mensanator: > > >> The second deviation is that since most names are constants, > > > Really? Does that mean you don't use literals, to save the time > > required to convert them to integers? Isn't that done at compile > > time? > > > So, instead of doing the Collatz Conjecture as > > > while a>1: > > f = gmpy.scan1(a,0) > > if f>0: > > a = a >> f > > else: > > a = a*3 + 1 > > > You would do this? > > > zed = 0 > > one = 1 > > two = 2 > > twe = 3 > > while a>one: > > f = gmpy.scan1(a,zed) > > if f>zed: > > a = a >> f > > else: > > a = a*twe + one > > That seems to have no relation to what you quoted / responded to. Whose fault is that? Here's a hint: when people's replies don't make any sense, it's because they don't understand your prattle. That's not good for someone who fancies himself a teacher of programming. > > On the other hand, if there is some specific rôle played by the 3 above, where > some other value (like e.g. 5) might be used instead, then a self descriptive > name for that rôle might be good. > > Such reasonable naming (not what you did above) then allows easier > modification > of and makes it easier to understand the code. > > That said, and a bit off-tangent to your comment's main thrust, the time spent > on coding that repeated-division-by-2 optimization would, I think, be better > spent googling "Collatz Conjecture" -- avoiding writing /any/ code. ;-) Ha! I know more about Collatz than you can ever find by Googling! And how did I achieve that? By writing such code. Be a good boy and maybe I'll show you how to do Ulam's Spiral with Turtle Graphics. > > > Does this really save any time? > > If by "it" you mean the silly naming, no it doesn't. > > On the contrary, it wastes time, both for writing the code and reading it. > > Generally, IMO, think about the clarity of your code. If naming something > increases clarity, then name the thing. If it doesn't increase clarity, don't. > > > > > > > Now, it's a different story if you're using the gmpy module. > > You DON'T want to use literals in loops involving gmpy, because > > they would have to be coerced to .mpz's on every pass through the > > loop. > > > In that case, you DO want to use constants as opposed to literals: > > > ZED = gmpy.mpz(0) > > ONE = gmpy.mpz(1) > > TWO = gmpy.mpz(2) > > TWE = gmpy.mpz(3) > > while a>ONE: > > f = gmpy.scan1(a,0) # int used here, so it can be a literal > > if f>ZED: > > a = a >> f > > else: > > a = a*TWE + ONE > > > And yes, the time savings can be tremendous, especially when 'a' > > has over 50,000 decimal digits. > > Yeah, good point. Few languages have compile time evaluation of logically > constant expressions. C++0x will have that feature (called 'constexpr' IIRC) > but > in Python, current C++ etc. it's just a good idea to precompute values, and > name > them, rather than computing them again and again where they're needed. > > > . I do not follow PEP > >> 8's recommendation to use uppercase names of constants. In fact almost no > >> Python > >> code does, > > > Mine does when I use gmpy. Otherwise, the notion that "most names > > are constants" is generally false. > > No, it depends on what you mean by "constant". Why don't you try using what PEP 8 means by "constant". > The problem with Python, as > Google noted, is that the language is so excessively dynamic: even names of > routines are variables, and there /are/ no named user defined constants except > logically, in the programmer's mind. And logically (that is, at the "in the > programmer's mind" level), if you define "constant" as a name whose value will > not change after initialization, then routine names are constants. You're sitting too close to the fire. Why don't you back off and quit overanalizing things. > > However, if you define "constant" as only a global scope (that is, module > scope) > name that denotes a boolean, numerical or string or Null value and that > doesn't > change after initialization, then your statement about the scarcity of > constants > appears to be true, but using a practically useless definition. > > I think for such constants exported by modules it's a good idea to at least > provide uppercase names so as conform to very firmly established convention. > There might even be tools that rely on that convention. But for application > code > the uppercase names are just distracting, and they don't help you... They help when I look at something like a = (i-ONE)*NIN**(k-ONE) + (NIN**(k-ONE) - ONE)//TWO + ONE > > Cheers & hth., > > - Alf -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming intro book ch1 and ch2 (Windows/Python 3) - Request For Comments
> The second deviation is that since most names are constants, Really? Does that mean you don't use literals, to save the time required to convert them to integers? Isn't that done at compile time? So, instead of doing the Collatz Conjecture as while a>1: f = gmpy.scan1(a,0) if f>0: a = a >> f else: a = a*3 + 1 You would do this? zed = 0 one = 1 two = 2 twe = 3 while a>one: f = gmpy.scan1(a,zed) if f>zed: a = a >> f else: a = a*twe + one Does this really save any time? Now, it's a different story if you're using the gmpy module. You DON'T want to use literals in loops involving gmpy, because they would have to be coerced to .mpz's on every pass through the loop. In that case, you DO want to use constants as opposed to literals: ZED = gmpy.mpz(0) ONE = gmpy.mpz(1) TWO = gmpy.mpz(2) TWE = gmpy.mpz(3) while a>ONE: f = gmpy.scan1(a,0) # int used here, so it can be a literal if f>ZED: a = a >> f else: a = a*TWE + ONE And yes, the time savings can be tremendous, especially when 'a' has over 50,000 decimal digits. . I do not follow PEP > 8's recommendation to use uppercase names of constants. In fact almost no > Python > code does, Mine does when I use gmpy. Otherwise, the notion that "most names are constants" is generally false. -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 17, 1:40 am, geremy condra wrote:
> On Thu, Dec 17, 2009 at 2:25 AM, Mensanator wrote:
> > On Dec 16, 8:45 pm, Ned Deily wrote:
> >> In article
> >> <88bab2c0-d27c-4081-a703-26b353b9e...@9g2000yqa.googlegroups.com>,
>
> >> Mensanator wrote:
> >> > Oh, and about Chapter 1.
>
> >> > If you're going to use version 3.1.1 as your standard, shouldn't
> >> > you also point out that 3.1.1 is NOT bundled with Mac OS X?
>
> >> > How about devoting a section on downloading the source files
> >> > and compiling it on a Mac?
>
> >> Why would you do that?
>
> > Oh, I don't know, maybe because I'm thinking about
> > buying one and seeing 2.3, 2.4 and 2.5 directories
> > on the model in the store made me wary.
>
> >>http://www.python.org/download/releases/3.1.1/http://www.python.org/f...
>
> > This tells me nothing.
>
> >> or (for MacPorts fans):
>
> >> $ sudo port install python31
>
> > And since I haven't got one, this also tells me nothing.
>
> He just told you what it meant, as if it weren't already obvious.
Why would it be obvious? I use a PC, for which
$ sudo port install python31
is meaningless. Is MacPorts bundled with Snow Leopard?
Or do I have to do this first:
MacPorts version 1.8.1 is available in various formats for download
and installation (note, if you are upgrading your Mac OS X to a new
major release, see the migration info page):
“dmg” disk images for Snow Leopard, Leopard and Tiger as a legacy
platform, containing pkg installers for use with the Mac OS X
Installer. By far the simplest installation procedure that most users
should follow after meeting the requirements listed below.
In source form as either a tar.bz2 package or a tar.gz one for manual
compilation, if you intend to customize your installation in any way.
SVN checkout of the unpackaged sources, if you wish to follow MacPorts
development.
The selfupdate target of the port(1) command, for users who already
have MacPorts installed and wish to upgrade to a newer release.
Checksums for our packaged downloads are contained in the
corresponding checksums file.
Please note that in order to install and run MacPorts on Mac OS X,
your system must have installations of the following components:
Apple's Xcode Developer Tools (version 3.2.1 or later for Snow
Leopard, 3.1.4 or later for Leopard, or 2.5 for Tiger), found at the
Apple Developer Connection site or on your Mac OS X installation CDs/
DVD.
Ensure that the optional components for command line development are
installed ("Unix Development" in the Xcode 3.x installer).
The X11 windowing environment (A.K.A. “X11 User”) for ports that
depend on the functionality it provides to run.
The “X11 User” package is an optional installation on your system CDs/
DVD for Tiger, enabled through the “Customize” button of the
installer, whereas it is included by default on Leopard and Snow
Leopard.
You can use the xorg-server port instead of Apple's X11.app if you
wish.
>
> Geremy Condra
--
http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 17, 10:12 am, Benjamin Kaplan wrote: > On Thu, Dec 17, 2009 at 5:33 AM, Ned Deily wrote: > > >> > or (for MacPorts fans): > > >> > $ sudo port install python31 > > >> And since I haven't got one, this also tells me nothing. > > >http://www.macports.org/ > > > "The MacPorts Project is an open-source community initiative to design > > an easy-to-use system for compiling, installing, and upgrading either > > command-line, X11 or Aqua based open-source software on the Mac OS X > > operating system." > > Description sans marketing fluff: It's a Mac package manager. It's > basically the same as Gentoo's portage if you've ever used that. It > downloads source tarballs and patches and then compiles them locally. > There are built-in lists of "variants", basically sets of configure > args, to compile each package. That's the kind of thing I want to hear. Looks like I can go ahead and get a Mac and not worry about getting 3.1.1 installed. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 17, 4:33 am, Ned Deily wrote: > In article > <183af5d2-e157-4cd6-bec6-8997809e1...@d21g2000yqn.googlegroups.com>, > > Mensanator wrote: > > Oh, I don't know, maybe because I'm thinking about > > buying one and seeing 2.3, 2.4 and 2.5 directories > > on the model in the store made me wary. > > That's odd since, AFAIK, Apple has never released an OS X with Python > 2.4. Hmm...I was poking around in the finder on a display of new iMacs at Best Buy last saturday. I searched for "python" and it took me to a directory listing with three items: Python 2.3 Python 2.4 Python 2.5 It's possible that Python 2.6 is located somewhere else. I assume that Snow Leopard was installed, but I didn't actually check that. > > Current Apple systems ship with OS X 10.6, aka Snow Leopard. 10.6 > includes a Python 2.6.1 (64-bit/32-bit) and a Python 2.5.4 (32-bit > only). The previous release, 10.5, shipped with 2.5 and 2.3. But, not > to worry, if you need other versions, you can download OS X installers > from python.org. > > > >http://www.python.org/download/releases/3.1.1/http://www.python.org/f... > > > on/3.1.1/python-3.1.1.dmg > > > This tells me nothing. > > That's the disk image for the OS X Python 3.1.1 installer. But it doesn't say whether that disk image is compatible with Snow Leopard and I don't take such things for granted. > Official > binary installers for OS X are provided on python.org for every final > Python release. > > > > or (for MacPorts fans): > > > > $ sudo port install python31 > > > And since I haven't got one, this also tells me nothing. > > http://www.macports.org/ > > "The MacPorts Project is an open-source community initiative to design > an easy-to-use system for compiling, installing, and upgrading either > command-line, X11 or Aqua based open-source software on the Mac OS X > operating system." Ok, now I know. Thanks for the information. > > -- > Ned Deily, > n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 16, 8:45�pm, Ned Deily wrote: > In article > <88bab2c0-d27c-4081-a703-26b353b9e...@9g2000yqa.googlegroups.com>, > > �Mensanator wrote: > > Oh, and about Chapter 1. > > > If you're going to use version 3.1.1 as your standard, shouldn't > > you also point out that 3.1.1 is NOT bundled with Mac OS X? > > > How about devoting a section on downloading the source files > > and compiling it on a Mac? > > Why would you do that? Oh, I don't know, maybe because I'm thinking about buying one and seeing 2.3, 2.4 and 2.5 directories on the model in the store made me wary. > > http://www.python.org/download/releases/3.1.1/http://www.python.org/ftp/python/3.1.1/python-3.1.1.dmg This tells me nothing. > > or (for MacPorts fans): > > $ sudo port install python31 And since I haven't got one, this also tells me nothing. > > -- > �Ned Deily, > �n...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python to Execute a C or FORTRAN Program (Windows)
On Dec 16, 8:41 pm, "W. eWatson" wrote: > Mensanator wrote: > > On Dec 14, 8:14 pm, "W. eWatson" wrote: > >> I think Python is capable of executing a compiled C or FORTRAN program, > > > Sure, if it was compiled to an .exe file. > > >> and maybe even getting some parameters passed back. > > > Sure, if the program prints to stdout. > > >> Does anyone have a > >> example of how this might be done? I'm running under Win XP Pro. > > > Here's one. The test program is factor.exe (included in > > the MIRACL library). I recompiled it (factor!.exe) to > > produce consitent output. > > ... > Thanks. OK, I think I can follow that. I want to pass it along to > someone who either missed this possibility in some coding, ignored it, > or felt more comfortable about just writing the whole program from > scratch in c++. His program was originally written in Python, but a new > hardware device (capture card) had no good interface with Python, so he > wrote it in C++, which does. From my knowledge of the Python program > before the entry of c++, it seems he could have farmed out the hardware > interface in much the same way he had done it before with a capture card > well know to him. > > Would the same Python interface work for a compiled C++ program? If it runs from the command line and writes to stdout, I don't why it wouldn't. -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 16, 5:45 pm, "Alf P. Steinbach" wrote: > * Mensanator: > > > > > > > On Dec 16, 4:41 pm, Mensanator wrote: > >> On Dec 14, 1:23 am, "Alf P. Steinbach" wrote: > > >>> * Alf P. Steinbach: > >>>> Format: PDF > >>>> http://preview.tinyurl.com/ProgrammingBookP3> > >>>> The new stuff, section 2.7, is about programs as simulations and > >>>> handling data, focusing on modeling things. It includes some Python GUI > >>>> programming. The plan is to discuss containers like lists and > >>>> dictionaries in perhaps two more subsections of 2.7, but I'm not quite > >>>> sure about how to approach that or exactly how much to cover, since the > >>>> intent of ch 2 is to introduce mostly general concepts and enable the > >>>> reader to try out (more or less) interesting things. > >>>> Cheers, > >>>> - Alf > >>>> PS: comments welcome! > >>> Well, I posted the current doc. It has a not yet quite complete section > >>> 2.7.7 > >>> about arrays, and that will be the last subsection of the chapter. I > >>> thought > >>> using the Josephus circle problem as example was pretty neat... :-) > >>> But anyway, comments welcome, even if that last section's not yet > >>> finished. > >>> Cheers, > >>> - Alf > >>> PS: Oh, I changed the manuscript title to "Intelligent Person's Intro to > >>> Programming" -- is that good? > >> Sure. After all, "Idiot's Guide to Programming" and "Programming for > >> Dummies" are probably already taken, albeit more appropriate > > > Oh, and about Chapter 1. > > > If you're going to use version 3.1.1 as your standard, shouldn't > > you also point out that 3.1.1 is NOT bundled with Mac OS X? > > > How about devoting a section on downloading the source files > > and compiling it on a Mac? > > Learn to read. > > At the top of every second page it tells you that this is an introduction > based > on Windows. Still, no excuse for giving out mis-information. It's just as easy to get these things right. > > Cheers & hth., > > - Alf- Hide quoted text - > > - Show quoted text - -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 16, 4:41 pm, Mensanator wrote: > On Dec 14, 1:23 am, "Alf P. Steinbach" wrote: > > > > > > > * Alf P. Steinbach: > > > > Format: PDF > > > http://preview.tinyurl.com/ProgrammingBookP3> > > > > The new stuff, section 2.7, is about programs as simulations and > > > handling data, focusing on modeling things. It includes some Python GUI > > > programming. The plan is to discuss containers like lists and > > > dictionaries in perhaps two more subsections of 2.7, but I'm not quite > > > sure about how to approach that or exactly how much to cover, since the > > > intent of ch 2 is to introduce mostly general concepts and enable the > > > reader to try out (more or less) interesting things. > > > > Cheers, > > > > - Alf > > > > PS: comments welcome! > > > Well, I posted the current doc. It has a not yet quite complete section > > 2.7.7 > > about arrays, and that will be the last subsection of the chapter. I > > thought > > using the Josephus circle problem as example was pretty neat... :-) > > > But anyway, comments welcome, even if that last section's not yet finished. > > > Cheers, > > > - Alf > > > PS: Oh, I changed the manuscript title to "Intelligent Person's Intro to > > Programming" -- is that good? > > Sure. After all, "Idiot's Guide to Programming" and "Programming for > Dummies" are probably already taken, albeit more appropriate Oh, and about Chapter 1. If you're going to use version 3.1.1 as your standard, shouldn't you also point out that 3.1.1 is NOT bundled with Mac OS X? How about devoting a section on downloading the source files and compiling it on a Mac? -- http://mail.python.org/mailman/listinfo/python-list
Re: More stuff added to ch 2 of my programming intro
On Dec 14, 1:23 am, "Alf P. Steinbach" wrote: > * Alf P. Steinbach: > > > > > > > Format: PDF > > http://preview.tinyurl.com/ProgrammingBookP3> > > > The new stuff, section 2.7, is about programs as simulations and > > handling data, focusing on modeling things. It includes some Python GUI > > programming. The plan is to discuss containers like lists and > > dictionaries in perhaps two more subsections of 2.7, but I'm not quite > > sure about how to approach that or exactly how much to cover, since the > > intent of ch 2 is to introduce mostly general concepts and enable the > > reader to try out (more or less) interesting things. > > > Cheers, > > > - Alf > > > PS: comments welcome! > > Well, I posted the current doc. It has a not yet quite complete section 2.7.7 > about arrays, and that will be the last subsection of the chapter. I thought > using the Josephus circle problem as example was pretty neat... :-) > > But anyway, comments welcome, even if that last section's not yet finished. > > Cheers, > > - Alf > > PS: Oh, I changed the manuscript title to "Intelligent Person's Intro to > Programming" -- is that good? Sure. After all, "Idiot's Guide to Programming" and "Programming for Dummies" are probably already taken, albeit more appropriate. -- http://mail.python.org/mailman/listinfo/python-list
Re: Apple Mac OS X 10.6 support & compatability with Python 3 ?
On Dec 16, 11:41 am, pdlem...@earthlink.net wrote: > I've been given a MAC AIR laptop with OS X 10.6 "Snow Leopard". > On my desktop I dual boot with XP - Ubuntu and have Python on both. > Unfortunately all my Python programs are written on Windows XP and > I heavily rely on WConio for console I/O. > Called Apple tech support. The technician had never heard of Python, > ascertained the MAC AIR does not come preloaded with Python and > did not know if Python 3 would run under OS X 10.6. This was "beyond" > their expertise. No, it's not. Call them back and if you get that bullshit again, ask to speak to the supervisor. And then ask for his supervisor, if necessary. It probably doesn't come with 3.1, you just got ahold of an idiot. BTW, I was just looking at an iMac the other day and it had 2.3, 2.4 and 2.5 installed. Beyond their expertise indeed. > Does anyone have experience with OS X ? Could I use WConio in a > Windows emulator ? I have no experience with MACs and am debating > whether to send this back before opening. > Thanks. Dave WB3DWE -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python to Execute a C or FORTRAN Program (Windows)
On Dec 14, 8:14�pm, "W. eWatson" wrote: > I think Python is capable of executing a compiled C or FORTRAN program, Sure, if it was compiled to an .exe file. > and maybe even getting some parameters passed back. Sure, if the program prints to stdout. > Does anyone have a > example of how this might be done? I'm running under Win XP Pro. Here's one. The test program is factor.exe (included in the MIRACL library). I recompiled it (factor!.exe) to produce consitent output. Instead of stupidly saying C:\factor!\miracl\source>factor 31 31 this number is prime! I now have it print C:\factor!\miracl\source>factor! 31 PRIME_FACTOR 31 I now call it from Python and have Python fix its mistakes. ##Mistakes? - numbers reported as COMPOSITE may still ##be factorable. Composites are not returned to the ##start of the algorithm for re-factoring. But that's ok, ##if I don't like it, I'm free to fix it myself since ##I have the source code (so says the author). ## ##Hey, I won't look a gift horse in the mouth, but you ##are advised that when you see... ## ##C:\factor!\miracl\source>factor! 5081842980034330599 ##30221143303110332712493139579190463526792062 ##62204589342623811236647989889145173098650749 ## ##PRIME_FACTOR 37 ##PRIME_FACTOR 43 ##PRIME_FACTOR 167 ##COMPOSITE_FACTOR 507787751 ##PRIME_FACTOR 69847 ##PRIME_FACTOR 30697 ##PRIME_FACTOR 89017 ##PRIME_FACTOR 3478697 ##PRIME_FACTOR 434593 ##PRIME_FACTOR 49998841 ##PRIME_FACTOR 161610704597143 ##PRIME_FACTOR 14064370273 ##COMPOSITE_FACTOR 963039394703598565337297 ##PRIME_FACTOR 11927295803 ## ##...you should follow that with... ## ##C:\factor!\miracl\source>factor! 507787751 ##PRIME_FACTOR 29819 ##PRIME_FACTOR 17029 ## ##C:\factor!\miracl\source>factor! 963039394703598565337297 ##PRIME_FACTOR 518069464441 ##PRIME_FACTOR 1858900129817 import os import random import time factor_program = 'factor! -d200 ' the_composites = [['COMPOSITE_FACTOR','50818429800343305993022114330311033271249313957919046352679206262204589342623811236647989889145173098650749']] ##random_digits = [str(random.randint(0,9)) for d in range(30)] ##test_number = ''.join(random_digits) ##the_composites = [['COMPOSITE_FACTOR',test_number]] the_primes = [] the_intractables = [] phase = 1 the_times = [] while the_composites: print "="*40 print 'Phase',phase the_comp = the_composites.pop(0) print the_comp print the_times.append(time.time()) # time how long it takes to run factor!.exe the_output = os.popen(factor_program+the_comp[1]).readlines() the_times.append(time.time()) new_factors = [i.split() for i in the_output] for i in new_factors: print i print if len(new_factors) == 1: # it's prime or intractable if new_factors[0][0] == 'PRIME_FACTOR': the_primes.append([new_factors[0][0],long(new_factors[0][1])]) else: the_intractables.append([new_factors[0][0],long(new_factors[0] [1])]) new_factors.pop() while new_factors: j = new_factors.pop(0) if j[0] == 'PRIME_FACTOR': the_primes.append([j[0],long(j[1])]) else: the_composites.append(j) print the_times[phase] - the_times[phase-1],'seconds' phase += 1 print "="*40 print print 'Factoring complete' print the_primes.sort() the_intractables.sort() the_primes.extend(the_intractables) for i in the_primes: print i[0],i[1] print print "="*40 ## ##Phase 1 ##['COMPOSITE_FACTOR', '50818429800343305993022114330311033271249313957919046352679206262204589342623811236647989889145173098650749'] ## ##['PRIME_FACTOR', '37'] ##['PRIME_FACTOR', '43'] ##['PRIME_FACTOR', '167'] ##['COMPOSITE_FACTOR', '507787751'] ##['PRIME_FACTOR', '69847'] ##['PRIME_FACTOR', '30697'] ##['PRIME_FACTOR', '89017'] ##['PRIME_FACTOR', '3478697'] ##['PRIME_FACTOR', '434593'] ##['PRIME_FACTOR', '49998841'] ##['PRIME_FACTOR', '161610704597143'] ##['PRIME_FACTOR', '14064370273'] ##['COMPOSITE_FACTOR', '963039394703598565337297'] ##['PRIME_FACTOR', '11927295803'] ## ## ##Phase 2 ##['COMPOSITE_FACTOR', '507787751'] ## ##['PRIME_FACTOR', '29819'] ##['PRIME_FACTOR', '17029'] ## ## ##Phase 3 ##['COMPOSITE_FACTOR', '963039394703598565337297'] ## ##['PRIME_FACTOR', '518069464441'] ##['PRIME_FACTOR', '1858900129817'] ## ## ## ##Factoring complete ## ##PRIME_FACTOR 37 ##PRIME_FACTOR 43 ##PRIME_FACTOR 167 ##PRIME_FACTOR 17029 ##PRIME_FACTOR 29819 ##PRIME_FACTOR 30697 ##PRIME_FACTOR 69847 ##PRIME_FACTOR 89017 ##PRIME_FACTOR 434593 ##PRIME_FACTOR 3478697 ##PRIME_FACTOR 49998841 ##PRIME_FACTOR 11927295803
