Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
On Sat, 29 Jul 2006 15:44:33 +1200 Greg Ewing <[EMAIL PROTECTED]> wrote: > Michael Urman wrote: > > The fact that > > round returns a float rather than an int, while intentional, does not > > feature prominently in one's mine when the first version yielded the > > expected results. > > As an aside, does anyone else think that it would be > useful to have a builtin which rounds and converts to > an int in one go? Whenever I use round(), I almost > always want the result as an int, and making me do > it in two steps seems unnecessarily bothersome. It's not even clear to me that int(round(x)) is always the nearest integer to x. Is it always true that float(some_int)>=some_int ? (for positive values). (ie. I am wondering if truncating the float representation of an int always gives back the original int). Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 2 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rounding float to int directly (Re: struct module and coercing floats to integers)
On Wed, 2 Aug 2006 07:21:02 -0400 "Chermside, Michael" <[EMAIL PROTECTED]> wrote: > > You wrote: > > (ie. I am wondering if truncating the float representation > > of an int always gives back the original int). > > Yes it does, because all integers that can be expressed as floats > can be expressed EXACTLY as floats. Yes, OK this makes sense. My point is that, regardless of this answer, as a python user I should not be worried by such details. At least: the doc string for round() should be expanded to mention the int(round(x)) use case. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 2 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C AST to Python discussion
On Wed, 15 Feb 2006 00:34:35 -0800 Brett Cannon <[EMAIL PROTECTED]> wrote: > As per Neal's prodding email, here is a thread to discuss where we > want to go with the C AST to Python stuff and what I think are the > core issues at the moment. > > First issue is the ast-objects branch. Work is being done on it, but > it still leaks some references (Neal or Martin can correct me if I am > wrong). I've been doing the heavy lifting on ast-objects the last few weeks. Today it finally passed the python test suite. The last thing to do is the addition of XDECREF's, so yes, it is leaking a lot of references. I won't make it to PyCon (it's a long way for me to come), but gee I've left all the fun stuff for you to do ! :) Even if AST transforms are not allowed, I see it as the strongest form of code reflection, and long over-due in python. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST branch is in?
On Fri, 21 Oct 2005 18:32:22 + (UTC) nas at arctrix.com (Neil Schemenauer) wrote: > > Does it just allow us to do new and interesting manipulations of > > the code during compilation? > > Well, that's a pretty big deal, IMHO. For example, adding > pychecker-like functionality should be straight forward now. I also > hope some of the namespace optimizations get explored (e.g. PEP > 267). Is there a python interface ? Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31
On Thu, 17 Nov 2005 13:36:36 +1300 Tony Meyer <[EMAIL PROTECTED]> wrote: > > -- > AST for Python > -- > > As of October 21st, Python's compiler now uses a real Abstract Syntax > Tree (AST)! This should make experimenting with new syntax much > easier, as well as allowing some optimizations that were difficult > with the previous Concrete Syntax Tree (CST). > While there is no > Python interface to the AST yet, one is intended for the not-so- > distant future. OK, who is doing this ? I am mad keen to get this happening. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2005-10-16 to 2005-10-31
On Tue, 22 Nov 2005 11:31:34 -0800 Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 11/21/05, Simon Burton <[EMAIL PROTECTED]> wrote: > > On Thu, 17 Nov 2005 13:36:36 +1300 > > Tony Meyer <[EMAIL PROTECTED]> wrote: > > > > > > > > -- > > > AST for Python > > > -- > > > > > > As of October 21st, Python's compiler now uses a real Abstract Syntax > > > Tree (AST)! This should make experimenting with new syntax much > > > easier, as well as allowing some optimizations that were difficult > > > with the previous Concrete Syntax Tree (CST). > > > > > While there is no > > > Python interface to the AST yet, one is intended for the not-so- > > > distant future. > > > > OK, who is doing this ? I am mad keen to get this happening. > > > > No one yet. Some ideas have been tossed around (read the thread for > details), but no one has sat down to hammer out the details. Might > happen at PyCon. > > -Brett Yes, i've been reading the threads but I don't see anything about a python interface. Why I'm asking is because I could probably convince my employer to let me (or an intern) work on it. And pycon is not until febuary. I am likely to start hacking on this before then. Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] computed goto's in ceval loop
I have been experimenting with replacing the big switch in ceval.c by a computed goto construct [1]. It uses #define's to make it optional. This work was inspired by Mono's MINT interpreter code, and Neil Norwitz's attempt to use a function pointer table [2]. Result: about 1% slower on the pystone benchmark. It also seems to have broken the interpreter; at least one test fails (test_StringIO). Whoops. Not sure if the other switch-speedup hacks (eg. PREDICT(op)) conflict at all with this patch (ie. make it slower than it could be). Mono uses a much larger opcode set, with 2-byte opcodes, that includes type info in each opcode. This means that the actual case statements are much faster. My initial thought about using computed goto's (January 2003) was that the python opcode cases were much fatter than mono's (often involving a function call) so that the overhead of branching on opcodes would be insignificant. It seems that this is true indeed. The patch id is 1408710. [1] http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Labels-as-Values.html [2] http://mail.python.org/pipermail/python-dev/2003-February/033705.html Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
