Re: [Python-Dev] Caching float(0.0)
On Tue, Oct 03, 2006 at 09:47:03AM +1000, Delaney, Timothy (Tim) wrote: This doesn't actually give us a very useful indication of potential memory savings. What I think would be more useful is tracking the maximum simultaneous count of each value i.e. what the maximum refcount would have been if they were shared. It isn't just memory savings we are playing for. Even if 0.0 is allocated and de-allocated 10,000 times in a row, there would be no memory savings by caching its value. However there would be a) less allocator overhead - allocation objects is relatively expensive b) better caching of the value c) less cache thrashing I think you'll find that even in the no memory saving case a few cycles spent on comparison with 0.0 (or maybe a few other values) will speed up programs. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick ___ 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] Caching float(0.0)
On Mon, Oct 02, 2006 at 07:53:34PM -0500, [EMAIL PROTECTED] wrote: Terry Kristján V. Jónsson [EMAIL PROTECTED] wrote: Anyway, Skip noted that 50% of all floats are whole numbers between -10 and 10 inclusive, Terry Please, no. He said something like this about Terry *non-floating-point applications* (evidence unspecified, that I Terry remember). But such applications, by definition, usually don't Terry have enough floats for caching (or conversion time) to matter too Terry much. Correct. The non-floating-point application I chose was the one that was most immediately available, make test. Note that I have no proof that regrtest.py isn't terribly floating point intensive. I just sort of guessed that it was. For my application caching 0.0 is by far the most important. 0.0 has ~200,000 references - the next highest reference count is only about ~200. -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick ___ 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] Caching float(0.0)
Terry Reedy wrote: For true floating point measurements (of temperature, for instance), 'integral' measurements (which are an artifact of the scale used (degrees F versus C versus K)) should generally be no more common than other realized measurements. a real-life sensor is of course where the 121.216 in my original post to this thread came from. (note that most real-life sensors involve A/D conversion at some point, which means that they provide a limited number of discrete values. but only the code dealing with the source data will be able to make any meaningful assumptions about those values.) I still think it might make sense to special-case float(0.0) (padding, default values, etc) inside PyFloat_FromDouble, and possibly also float(1.0) (scale factors, unit vectors, normalized max values, etc) but everything else is just generalizing from random observations. adding a few notes to the C API documentation won't hurt either, I suppose. (e.g. note that each call to PyFloat_FromDouble may create a new floating point object; if you're converting data from some internal format to Python floats, it's often more efficient to map directly to preallocated shared PyFloat objects, instead of mapping first to float or double and then calling PyFloat_FromDouble on that value). /F ___ 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] Caching float(0.0)
Terry Reedy [EMAIL PROTECTED] wrote: For true floating point measurements (of temperature, for instance), 'integral' measurements (which are an artifact of the scale used (degrees F versus C versus K)) should generally be no more common than other realized measurements. Not quite, but close enough. A lot of algorithms use a conversion to integer, or some of the values are actually counts (e.g. in statistics), which makes them a bit more likely. Not enough to get excited about, in general. Thirty years ago, a major stat package written in Fortran (BMDP) required that all data be stored as (Fortran 4-byte) floats for analysis. So a column of yes/no or male/female data would be stored as 0.0/1.0 or perhaps 1.0/2.0. That skewed the distribution of floats. But Python and, I hope, Python apps, are more modern than that. And SPSS and Genstat and others - now even Excel Float caching strikes me a a good subject for cookbook recipies, but not, without real data and a willingness to slightly screw some users, for the default core code. Yes. It is trivial (if tedious) to add analysis code - the problem is finding suitable representative applications. That was always my difficulty when I was analysing this sort of thing - and still is when I need to do it! Nick Craig-Wood [EMAIL PROTECTED] wrote: For my application caching 0.0 is by far the most important. 0.0 has ~200,000 references - the next highest reference count is only about ~200. Yes. All the experience I have ever seen over the past 4 decades confirms that is the normal case, with the exception of floating-point representations that have a missing value indicator. Even in IEEE 754, infinities and NaN are rare unless the application is up the spout. There are claims that a lot of important ones have a lot of NaNs and use them as missing values but, despite repeated requests, none of the people claiming that have ever provided an example. There are some pretty solid grounds for believing that those claims are not based in fact, but are polemic. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] PEP 315 - do while
Hans Polak wrote: Ok, I see your point. Really, I've read more about Python than worked with it, so I'm out of my league here. Can I combine your suggestion with mine and come up with the following: do: setup code loop body while condition else: loop completion code In my example, the 3 sections (setup code, loop body and loop completion code are all optional. A basic do-while loop would look like this: do: setup code while condition (That is, setup code is still repeated each time around the loop - it's called that because it is run before the loop evaluated condition is evaluated) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] PEP 315 - do while
Nick Coghlan wrote: Hans Polak wrote: Ok, I see your point. Really, I've read more about Python than worked with it, so I'm out of my league here. Can I combine your suggestion with mine and come up with the following: do: setup code loop body while condition else: loop completion code In my example, the 3 sections (setup code, loop body and loop completion code are all optional. A basic do-while loop would look like this: do: setup code while condition (That is, setup code is still repeated each time around the loop - it's called that because it is run before the loop evaluated condition is evaluated) +1 This looks good. The current idiom works fine, but looks unnatural : while True: if condition: break Would a 'while' outside of a 'do' block (but without the colon) then be a syntax error ? 'do:' would just be syntactic sugar for 'while True:' I guess. Michael Foord http://www.voidspace.org.uk Cheers, Nick. ___ 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] Caching float(0.0)
But that is precisely the point. A non-floating point application tends to use floating point values in a predictable way, with a lot of integral values floating around and lots of zeroes. As this constitutes the majority of python applications (okay, daring assumption here) it seems to warrant some consideration. In one of my first messages on the subject I promised to report refcounts of -1.0, 0.0 and 1.0 for the EVE server as being. I didn't but instead gave you the frequency of the values reported. Well , now I can provide you with refcounts for the [-10, 10] range plus the total float count, of a server that has just started up: -10,0 589 -9,056 -8,065 -7,063 -6,0243 -5,0731 -4,0550 -3,0246 -2,0246 -1,01096 0,0 195446 1,0 79382 2,0 9650 3,0 6224 4,0 5223 5,0 14766 6,0 2616 7,0 1303 8,0 3307 9,0 1447 10,08102 total: 331351 The total count of floating point numbers allocated at this point is 985794. Without the reuse, they would be 1317145, so this is a saving of 25%, and of 5Mb. Kristján -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 3. október 2006 00:54 To: Terry Reedy Cc: python-dev@python.org Subject: Re: [Python-Dev] Caching float(0.0) Terry Kristján V. Jónsson [EMAIL PROTECTED] wrote: Anyway, Skip noted that 50% of all floats are whole numbers between -10 and 10 inclusive, Terry Please, no. He said something like this about Terry *non-floating-point applications* (evidence unspecified, that I Terry remember). But such applications, by definition, usually don't Terry have enough floats for caching (or conversion time) to matter too Terry much. Correct. The non-floating-point application I chose was the one that was most immediately available, make test. Note that I have no proof that regrtest.py isn't terribly floating point intensive. I just sort of guessed that it was. Skip ___ 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] Caching float(0.0)
=?iso-8859-1?Q?Kristj=E1n_V=2E_J=F3nsson?= [EMAIL PROTECTED] wrote: The total count of floating point numbers allocated at this point is 985794. Without the reuse, they would be 1317145, so this is a saving of 25%, and of 5Mb. And, if you optimised just 0.0, you would get 60% of that saving at a small fraction of the cost and considerably greater generality. It isn't clear whether the effort justifies doing more. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Caching float(0.0)
The total count of floating point numbers allocated at this point is 985794. Without the reuse, they would be 1317145, so this is a saving of 25%, and of 5Mb. Nick And, if you optimised just 0.0, you would get 60% of that saving Nick at a small fraction of the cost and considerably greater Nick generality. It isn't clear whether the effort justifies doing Nick more. Doesn't that presume that optimizing just 0.0 could be done easily? Suppose 0.0 is generated all over the place in EVE? Skip ___ 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] Caching float(0.0)
Nick Craig-Wood schrieb: Even if 0.0 is allocated and de-allocated 10,000 times in a row, there would be no memory savings by caching its value. However there would be a) less allocator overhead - allocation objects is relatively expensive b) better caching of the value c) less cache thrashing I think you'll find that even in the no memory saving case a few cycles spent on comparison with 0.0 (or maybe a few other values) will speed up programs. Can you demonstrate that speedup? It is quite difficult to anticipate the performance impact of a change, in particular if there is no change in computational complexity. Various effects tend to balance out each other. Regards, Martin ___ 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] Caching float(0.0)
Nick Maclaren schrieb: The total count of floating point numbers allocated at this point is 985794. Without the reuse, they would be 1317145, so this is a saving of 25%, and of 5Mb. And, if you optimised just 0.0, you would get 60% of that saving at a small fraction of the cost and considerably greater generality. As Michael Hudson observed, this is difficult to implement, though: You can't distinguish between -0.0 and +0.0 easily, yet you should. Regards, Martin ___ 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] what's really new in python 2.5 ?
just noticed that the first google hit for what's new in python 2.5: http://docs.python.org/dev/whatsnew/whatsnew25.html points to a document that's a weird mix between that actual document, and a placeholder for what's new in python 2.6. /F ___ 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] Caching float(0.0)
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: The total count of floating point numbers allocated at this point is 985794. Without the reuse, they would be 1317145, so this is a saving of 25%, and of 5Mb. And, if you optimised just 0.0, you would get 60% of that saving at a small fraction of the cost and considerably greater generality. As Michael Hudson observed, this is difficult to implement, though: You can't distinguish between -0.0 and +0.0 easily, yet you should. That was the point of a previous posting of mine in this thread :-( You shouldn't, despite what IEEE 754 says, at least if you are allowing for either portability or numeric validation. There are a huge number of good reasons why IEEE 754 signed zeroes fit extremely badly into any normal programming language and are seriously incompatible with numeric validation, but Python adds more. Is there any other type where there are two values that are required to be different, but where both the hash is required to be zero and both are required to evaluate to False in truth value context? Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] 2.4.4 fixes
I've gone through the 'backport candidate' bugs listed on http://wiki.python.org/moin/Python24Fixes and applied most of them. Some I didn't apply because I don't understand them well enough to determine if they're correct for 2.4: * r47061 (recursionerror fix) * r46602 (tokenizer.c bug; patch doesn't apply cleanly) * r46589 (let dicts propagate eq errors; dictresize bug -- this led to a big long 2.5 discussion, so I won't backport. Maybe someone can extract just the dictresize bugfix.) * r39044 (A C threading API bug) There are also some other bugs listed on the wiki page that involve metaclasses; I'm not going to touch them. subprocess.py received a number of bugfixes in 2.5, but also some API additions. Can someone please look at these and apply the fixes? The wiki page now lists all the revisions stemming from valgrind and Klocwork errors. There are a lot of them; more volunteers will be necessary if they're all to get looked at and possibly backported. --amk ___ 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] PEP 315 - do while
Fuzzyman wrote: Nick Coghlan wrote: In my example, the 3 sections (setup code, loop body and loop completion code are all optional. A basic do-while loop would look like this: do: setup code while condition (That is, setup code is still repeated each time around the loop - it's called that because it is run before the loop evaluated condition is evaluated) +1 This looks good. I'm pretty sure it was proposed by someone else a long time ago - I was surprised to find it wasn't mentioned in PEP 315. That said, Guido's observation on PEP 315 from earlier this year holds for me too: I kind of like it but it doesn't strike me as super important [1] The current idiom works fine, but looks unnatural : while True: if condition: break There's the rationale for the PEP in a whole 5 lines counting whitespace ;) Would a 'while' outside of a 'do' block (but without the colon) then be a syntax error ? 'do:' would just be syntactic sugar for 'while True:' I guess. That's the slight issue I still have with the idea - you could end up with multiple ways of spelling some of the basic loop forms, such as these 3 flavours of infinite loop: do: pass # Is there an implicit 'while True' at the end of the loop body? do: while True while True: pass The other issue I have is that I'm not yet 100% certain it's implementable with Python's parser and grammar. I *think* changing the definition of the while statement from: while_stmt ::= while expression : suite [else : suite] to while_stmt ::= while expression [: suite [else : suite]] And adding a new AST node and a new type of compiler frame block DO_LOOP would do the trick (the compilation of a while statement without a trailing colon would then check that it was in a DO_LOOP block and raise an error if not). Cheers, Nick. [1] http://mail.python.org/pipermail/python-dev/2006-February/060711.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Caching float(0.0)
Nick Maclaren schrieb: That was the point of a previous posting of mine in this thread :-( You shouldn't, despite what IEEE 754 says, at least if you are allowing for either portability or numeric validation. There are a huge number of good reasons why IEEE 754 signed zeroes fit extremely badly into any normal programming language and are seriously incompatible with numeric validation, but Python adds more. Is there any other type where there are two values that are required to be different, but where both the hash is required to be zero and both are required to evaluate to False in truth value context? Ah, you are proposing a semantic change, then: -0.0 will become unrepresentable, right? Regards, Martin ___ 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] what's really new in python 2.5 ?
On Tuesday 03 October 2006 08:56, Fredrik Lundh wrote: just noticed that the first google hit for what's new in python 2.5: http://docs.python.org/dev/whatsnew/whatsnew25.html points to a document that's a weird mix between that actual document, and a placeholder for what's new in python 2.6. I suspect Google (and all other search engines) should be warded off from docs.python.org/dev/. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] PEP 315 - do while
Nick Coghlan wrote: [snip..] The current idiom works fine, but looks unnatural : while True: if condition: break There's the rationale for the PEP in a whole 5 lines counting whitespace ;) Would a 'while' outside of a 'do' block (but without the colon) then be a syntax error ? 'do:' would just be syntactic sugar for 'while True:' I guess. That's the slight issue I still have with the idea - you could end up with multiple ways of spelling some of the basic loop forms, such as these 3 flavours of infinite loop: do: pass # Is there an implicit 'while True' at the end of the loop body? do: while True while True: pass Following the current idiom, isn't it more natural to repeat the loop 'until' a condition is met. If we introduced two new keywords, it would avoid ambiguity in the use of 'while'. do: loop body until condition A do loop could require an 'until', meaning 'do' is not *just* a replacement for an infinite loop. (Assuming the parser can be coerced into co-operation.) It is obviously still a new construct in terms of Python syntax (not requiring a colon after 'condition'.) I'm sure this has been suggested, but wonder if it has already been ruled out. An 'else' block could then retain its current meaning (execute if the loop is not terminated early by an explicit break.) Michael Foord http://www.voidspace.org.uk ___ 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] what's really new in python 2.5 ?
Fredrik Lundh wrote: just noticed that the first google hit for what's new in python 2.5: http://docs.python.org/dev/whatsnew/whatsnew25.html points to a document that's a weird mix between that actual document, and a placeholder for what's new in python 2.6. D'oh. It's going to take a while for the stable docs to catch up to that one given the large number of external links to that page using that title :( Since the URL for the actual Python 2.6 What's New finishes with whatsnew26.html, perhaps this URL could be updated to redirect users to the stable version instead? Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] what's really new in python 2.5 ?
On Tue, Oct 03, 2006 at 02:56:54PM +0200, Fredrik Lundh wrote:
just noticed that the first google hit for what's new in python 2.5:
http://docs.python.org/dev/whatsnew/whatsnew25.html
points to a document that's a weird mix between that actual document, and
a placeholder for what's new in python 2.6.
Thanks for pointing this out! I've added a redirect from
/whatsnew25.html to the correct location, but am puzzled by the 2.6
document; it has section names like 'pep-308.html', which are set by a
\label{pep-308} directive in the LaTeX, but no such \label exists in
the 2.6 document.
Neal, could you please delete all the temp files in whatever directory
is used to build the documentation? I wonder if there's a *.aux file
or something that still has labels from the 2.5 document. It might be
easiest to just delete the whatsnew/ directory and then do an 'svn up'
to get it back.
--amk
___
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] 2.4.4 fixes
On Tue, Oct 03, 2006 at 09:40:51AM -0400, A.M. Kuchling wrote: The wiki page now lists all the revisions stemming from valgrind and Klocwork errors. There are a lot of them; more volunteers will be necessary if they're all to get looked at and possibly backported. I've now looked at the Valgrind errors; most of them were already in 2.4 or don't matter (ctypes, sqlite3 fixes). One revision remains, changing the size of strings allocated in the confstr() wrapper in posixmodule.c. The patch doesn't apply cleanly -- can someone please look at this? --amk ___ 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] what's really new in python 2.5 ?
On Tuesday 03 October 2006 10:30, A.M. Kuchling wrote: Neal, could you please delete all the temp files in whatever directory is used to build the documentation? I wonder if there's a *.aux file or something that still has labels from the 2.5 document. It might be easiest to just delete the whatsnew/ directory and then do an 'svn up' to get it back. I would guess this has everything to do with how the updated docs are deployed and little or nothing about the cleanliness of the working area. The mkhowto script should be cleaning out the old HTML before generating the new. I'm guessing the deployment simply unpacks the new on top of the old; the old should be removed first. For the /dev/ area, I don't think redirects are warranted. I'd rather see the crawlers just not bother with that, since those are more likely decoys than usable end-user docs. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Caching float(0.0)
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: Ah, you are proposing a semantic change, then: -0.0 will become unrepresentable, right? Well, it is and it isn't. Python currently supports only some of IEEE 754, and that is more by accident than design - because that is exactly what C90 implementations do! There is code in floatobject.c that assumes IEEE 754, but Python does NOT attempt to support it in toto (it is not clear if it could), not least because it uses C90. And, as far as I know, none of that is in the specification, because Python is at least in theory portable to systems that use other arithmetics and there is no current way to distinguish -0.0 from 0.0 except by comparing their representations! And even THAT depends entirely on whether the C library distinguishes the cases, as far as I can see. So distinguishing -0.0 from 0.0 isn't really in Python's current semantics at all. And, for reasons that we could go into, I assert that it should not be - which is NOT the same as not supporting branch cuts in cmath. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Caching float(0.0)
Nick Maclaren schrieb: So distinguishing -0.0 from 0.0 isn't really in Python's current semantics at all. And, for reasons that we could go into, I assert that it should not be - which is NOT the same as not supporting branch cuts in cmath. Are you talking about Python the language specification or Python the implementation here? It is not a change to the language specification, as this aspect of the behavior (as you point out) is unspecified. However, it is certainly a change to the observable behavior of the Python implementation, and no amount of arguing can change that. Regards, Martin P.S. For that matter, *any* kind of changes to the singleton nature of certain immutable values is a change in semantics. It's just that dropping -0.0 is an *additional* change (on top of the change that 1.0-1.0 is 0.0 would change from False to True). ___ 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] Caching float(0.0)
On 3 Oct 2006, at 15:10, Martin v. Löwis wrote: Nick Maclaren schrieb: That was the point of a previous posting of mine in this thread :-( You shouldn't, despite what IEEE 754 says, at least if you are allowing for either portability or numeric validation. There are a huge number of good reasons why IEEE 754 signed zeroes fit extremely badly into any normal programming language and are seriously incompatible with numeric validation, but Python adds more. Is there any other type where there are two values that are required to be different, but where both the hash is required to be zero and both are required to evaluate to False in truth value context? Ah, you are proposing a semantic change, then: -0.0 will become unrepresentable, right? It's only a semantic change on platforms that happen to use IEEE 754 float representations, or some other representation that exposes the sign of zero. The Python docs have for many years stated with regard to the float type: All bets on their precision are off unless you happen to know the machine you are working with. and that You are at the mercy of the underlying machine architecture Not all floating point representations support sign of zero, though in the modern world it's true that the vast majority do. It would be instructive to understand how much, if any, python code would break if we lost -0.0. I'm do not believe that there is any reliable way for python code to tell the difference between all of the different types of IEEE 754 zeros and in the special case of -0.0 the best test I can come up with is repr(n)[0]=='-'. Is there an compelling case, to do with compatibility or otherwise, for exposing the sign of a zero? It seems like a numerical anomaly to me. Nicko ___ 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] PSF Infrastructure Committee's recommendation for a new issue tracker
If nothing else, Brett deserves a hearty round of applause for this work: Three cheers for Brett! -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ LL YR VWL R BLNG T S -- www.nancybuttons.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] PSF Infrastructure Committee's recommendation for a new issue tracker
On 10/3/06, Aahz [EMAIL PROTECTED] wrote: If nothing else, Brett deserves a hearty round of applause for this work: Three cheers for Brett! Definitely. Paul ___ 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] Caching float(0.0)
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is assuming that a double is 64 bits.
Practically speaking, that is true on all architectures I know of,
and if it's not guaranteed, it could easily be a 'configure' time check.
typedef union {
double d;
uint64_t i;
} rawdouble;
int isposzero(double a) {
rawdouble zero;
zero.d = 0.0;
rawdouble aa;
aa.d = a;
return aa.i == zero.i;
}
int main() {
if (sizeof(double) != sizeof(uint64_t))
return 1;
printf(%d\n, isposzero(0.0));
printf(%d\n, isposzero(-0.0));
}
James
___
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] Caching float(0.0)
Nicko van Someren schrieb: It's only a semantic change on platforms that happen to use IEEE 754 float representations, or some other representation that exposes the sign of zero. Right. Later, you admit that this is vast majority of modern machines. It would be instructive to understand how much, if any, python code would break if we lost -0.0. I'm do not believe that there is any reliable way for python code to tell the difference between all of the different types of IEEE 754 zeros and in the special case of -0.0 the best test I can come up with is repr(n)[0]=='-'. Is there an compelling case, to do with compatibility or otherwise, for exposing the sign of a zero? It seems like a numerical anomaly to me. I think it is reasonable to admit that a) this change is a change in semantics for the majority of the machines b) it is likely that this change won't affect a significant number of applications (I'm pretty sure someone will notice, though; someone always notices). Regards, Martin ___ 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] Caching float(0.0)
Martin However, it is certainly a change to the observable behavior of Martin the Python implementation, and no amount of arguing can change Martin that. If C90 doesn't distinguish -0.0 and +0.0, how can Python? Can you give a simple example where the difference between the two is apparent to the Python programmer? Skip ___ 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] Caching float(0.0)
Martin b) it is likely that this change won't affect a significant Martinnumber of applications (I'm pretty sure someone will notice, Martinthough; someone always notices). +1 QOTF. Skip ___ 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] Caching float(0.0)
James Y Knight wrote:
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is assuming that a double is 64 bits.
Practically speaking, that is true on all architectures I know of,
and if it's not guaranteed, it could easily be a 'configure' time check.
typedef union {
double d;
uint64_t i;
} rawdouble;
int isposzero(double a) {
rawdouble zero;
zero.d = 0.0;
rawdouble aa;
aa.d = a;
return aa.i == zero.i;
}
int main() {
if (sizeof(double) != sizeof(uint64_t))
return 1;
printf(%d\n, isposzero(0.0));
printf(%d\n, isposzero(-0.0));
}
And you should be able to cache the single positive zero
with something vaguely like:
PyObject *
PyFloat_FromDouble(double fval)
{ ...
if (fval == 0.0 raw_match(fval, cached)) {
PY_INCREF(cached);
return cached;
}
...
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] Caching float(0.0)
[EMAIL PROTECTED] schrieb:
If C90 doesn't distinguish -0.0 and +0.0, how can Python? Can you give a
simple example where the difference between the two is apparent to the
Python programmer?
Sure:
py x=-0.0
py y=0.0
py x,y
(-0.0, 0.0)
py hash(x),hash(y)
(0, 0)
py x==y
True
py str(x)==str(y)
False
py str(x),str(y)
('-0.0', '0.0')
py float(str(x)),float(str(y))
(-0.0, 0.0)
Imagine an application that reads floats from a text file, manipulates
some of them, and then writes back the complete list of floats. Further
assume that somehow, -0.0 got into the file. Currently, the sign
round-trips; under the proposed change, it would stop doing so.
Of course, there likely wouldn't be any real change to value, as
the sign of 0 is likely of no significance to the application.
Regards,
Martin
___
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] what's really new in python 2.5 ?
On Tue, Oct 03, 2006 at 10:39:52AM -0400, Fred L. Drake, Jr. wrote: and little or nothing about the cleanliness of the working area. The mkhowto script should be cleaning out the old HTML before generating the new. I'm guessing the deployment simply unpacks the new on top of the old; the old should be removed first. That doesn't explain it, though; the contents of whatsnew26.html contain references to pep-308.html. It's not simply a matter of new files being untarred on top of old. I've added a robots.txt to keep crawlers out of /dev/. --amk ___ 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] what's really new in python 2.5 ?
On Tuesday 03 October 2006 14:08, A.M. Kuchling wrote: That doesn't explain it, though; the contents of whatsnew26.html contain references to pep-308.html. It's not simply a matter of new files being untarred on top of old. Ah; I missed that the new HTML file was referring to an old heading. That does sound like a .aux file got left around. I don't know what the build process is for the material in docs.python.org/dev/; I think the right thing would be to start each build with a fresh checkout/export. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Caching float(0.0)
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: py x=-0.0 py y=0.0 py x,y Nobody is denying that SOME C90 implementations distinguish them, but it is no part of the standard - indeed, a C90 implementation is permitted to use ANY criterion for deciding when to display -0.0 and 0.0. C99 is ambiguous to the point of internal inconsistency, except when __STDC_IEC_559__ is set to 1, though the intent is clear. And my reading of Python's code is that it relies on C's handling of such values. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Caching float(0.0)
On Oct 3, 2006, at 2:26 PM, Nick Maclaren wrote: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= [EMAIL PROTECTED] wrote: py x=-0.0 py y=0.0 py x,y Nobody is denying that SOME C90 implementations distinguish them, but it is no part of the standard - indeed, a C90 implementation is permitted to use ANY criterion for deciding when to display -0.0 and 0.0. C99 is ambiguous to the point of internal inconsistency, except when __STDC_IEC_559__ is set to 1, though the intent is clear. And my reading of Python's code is that it relies on C's handling of such values. This is a really poor argument. Python should be moving *towards* proper '754 fp support, not away from it. On the platforms that are most important, the C implementations distinguish positive and negative 0. That the current python implementation may be defective when the underlying C implementation is defective doesn't excuse a change to intentionally break python on the common platforms. IEEE 754 is so widely implemented that IMO it would make sense to make Python's floating point specify it, and simply declare floating point operations on non-IEEE 754 machines as use at own risk, may not conform to python language standard. (or if someone wants to use a software fp library for such machines, that's fine too). James ___ 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] Caching float(0.0)
Nick Maclaren schrieb: py x=-0.0 py y=0.0 py x,y Nobody is denying that SOME C90 implementations distinguish them, but it is no part of the standard - indeed, a C90 implementation is permitted to use ANY criterion for deciding when to display -0.0 and 0.0. C99 is ambiguous to the point of internal inconsistency, except when __STDC_IEC_559__ is set to 1, though the intent is clear. And my reading of Python's code is that it relies on C's handling of such values. So what is your conclusion? That applications will not break? People don't care that their code may break on a different platform, if they aren't using these platforms. They care if it breaks on their platform just because they use a new Python version. (Of course, they sometimes also complain that Python behaves differently on different platforms, and cannot really accept the explanation that the language didn't guarantee the same behavior on all systems. This explanation doesn't help them: they still need to modify the application). Regards, Martin ___ 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] PEP 315 - do while
Nick Coghlan wrote: Fuzzyman wrote: Nick Coghlan wrote: In my example, the 3 sections (setup code, loop body and loop completion code are all optional. A basic do-while loop would look like this: do: setup code while condition (That is, setup code is still repeated each time around the loop - it's called that because it is run before the loop evaluated condition is evaluated) +1 This looks good. I'm pretty sure it was proposed by someone else a long time ago - I was surprised to find it wasn't mentioned in PEP 315. That said, Guido's observation on PEP 315 from earlier this year holds for me too: I kind of like it but it doesn't strike me as super important [1] I looked though a few files in the library for different while usage patterns and there really wasn't as many while loops that would fit this pattern as I expected. There are much more while loops with one or more exit conditions in the middle as things in the loop are calculated or received. So it might be smart to find out just how many places in the library it would make a difference. Ron ___ 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] Caching float(0.0)
It would be instructive to understand how much, if any, python code would break if we lost -0.0. I'm do not believe that there is any reliable way for python code to tell the difference between all of the different types of IEEE 754 zeros and in the special case of -0.0 the best test I can come up with is repr(n)[0]=='-'. Is there an compelling case, to do with compatibility or otherwise, for exposing the sign of a zero? It seems like a numerical anomaly to me. I think it is reasonable to admit that a) this change is a change in semantics for the majority of the machines b) it is likely that this change won't affect a significant number of applications (I'm pretty sure someone will notice, though; someone always notices). If you're really going to bother doing this rather than just adding a note in the docs about testing for and reusing the most common float values to save memory when instantiating them from external input: Just do a binary comparison of the float with predefined + and - 0.0 float values or any other special values that you wish to catch rather than a floating point comparison. -g ___ 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] Caching float(0.0)
On 3 Oct 2006, at 17:47, James Y Knight wrote:
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is assuming that a double is 64 bits.
Practically speaking, that is true on all architectures I know of,
How about doing 1.0 / x, where x is the number you want to test? On
systems with sane semantics, it should result in an infinity, the
sign of which should depend on the sign of the zero. While I'm sure
there are any number of places where it will break, on those
platforms it seems to me that you're unlikely to care about the
difference between +0.0 and -0.0 anyway, since it's hard to otherwise
distinguish them.
e.g.
double value_to_test;
...
if (value_to_test == 0.0) {
double my_inf = 1.0 / value_to_test;
if (my_inf 0.0) {
/* We have a -ve zero */
} else if (my_inf 0.0) {
/* We have a +ve zero */
} else {
/* This platform might not support infinities (though we might
get a
signal or something rather than getting here in that
case...) */
}
}
(I should add that presently I've only tried it on a PowerPC, because
it's late and that's what's in front of me. It seems to work OK here.)
Kind regards,
Alastair
--
http://alastairs-place.net
___
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] Caching float(0.0)
Alastair Houghton [EMAIL PROTECTED] wrote:
On 3 Oct 2006, at 17:47, James Y Knight wrote:
On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote:
As Michael Hudson observed, this is difficult to implement, though:
You can't distinguish between -0.0 and +0.0 easily, yet you should.
Of course you can. It's absolutely trivial. The only part that's even
*the least bit* sketchy in this is assuming that a double is 64 bits.
Practically speaking, that is true on all architectures I know of,
How about doing 1.0 / x, where x is the number you want to test? On
systems with sane semantics, it should result in an infinity, the
sign of which should depend on the sign of the zero. While I'm sure
there are any number of places where it will break, on those
platforms it seems to me that you're unlikely to care about the
difference between +0.0 and -0.0 anyway, since it's hard to otherwise
distinguish them.
There is, of course, the option of examining their representations in
memory (I described the general technique in another posting on this
thread). From what I understand of IEEE 764 FP doubles, -0.0 and +0.0
have different representations, and if we look at the underlying
representation (perhaps by a *((uint64*)(float_input))), we can
easily distinguish all values we want to cache...
We can observe it directly, for example on x86:
import struct
struct.pack('d', -0.0)
'\x00\x00\x00\x00\x00\x00\x00\x80'
struct.pack('d', 0.0)
'\x00\x00\x00\x00\x00\x00\x00\x00'
And as I stated before, we can switch on those values. Alternatively,
if we can't switch on the 64 bit values directly...
uint32* p = (uint32*)(double_input)
if (!p[0]) { /* p[1] on big-endian platforms */
switch p[1] { /* p[0] on big-endian platforms */
...
}
}
- Josiah
___
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] 2.4.4 fix: Socketmodule Ctl-C patch
I've put a patch for 2.4.4 of the Socketmodule Ctl-C patch for 2.5, at the old closed bug http://www.python.org/sf/1519025 . It passes make EXTRAOPS-=unetwork test. Should I try to put this into the wiki at Python24Fixes? I haven't used the wiki before. -- TonyN.:'The Great Writ mailto:[EMAIL PROTECTED] ' is no more. http://www.georgeanelson.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] Caching float(0.0)
Josiah Carlson wrote: [yet more on this topic] If the brainpower already expended on this issue were proportional to its significance then we'd be reading about it on CNN news. This thread has disappeared down a rat-hole, never to re-emerge with anything of significant benefit to users. C'mon, guys, implement a patch or leave it alone :-) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Caching float(0.0)
On 10/3/06, Steve Holden [EMAIL PROTECTED] wrote: If the brainpower already expended on this issue were proportional to its significance then we'd be reading about it on CNN news. This thread has disappeared down a rat-hole, never to re-emerge with anything of significant benefit to users. C'mon, guys, implement a patch or leave it alone :-) Hear, hear. My proposal: only cache positive 0.0. My prediction: biggest bang for the buck, nobody's code will break. On platforms that don't distinguish between +/- 0.0, of course this would cache all zeros. On platforms that do distinguish them, -0.0 is left alone, which is just fine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] what's really new in python 2.5 ?
On 10/3/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Tuesday 03 October 2006 14:08, A.M. Kuchling wrote: That doesn't explain it, though; the contents of whatsnew26.html contain references to pep-308.html. It's not simply a matter of new files being untarred on top of old. Ah; I missed that the new HTML file was referring to an old heading. That does sound like a .aux file got left around. I don't know what the build process is for the material in docs.python.org/dev/; I think the right thing would be to start each build with a fresh checkout/export. I probably did not do that to begin with. I did rm -rf Doc svn up Doc cd Doc make. Let me know if there's anything else I should do. I did this for both the 2.5 and 2.6 versions. Let me know if you see anything screwed up after an hour or so. The new versions should be up by then. n ___ 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] Caching float(0.0)
[EMAIL PROTECTED] If C90 doesn't distinguish -0.0 and +0.0, how can Python? With liberal applications of piss vinegar ;-) Can you give a simple example where the difference between the two is apparent to the Python programmer? Perhaps surprsingly, many (well, comparatively many, compared to none ) people have noticed that the platform atan2 cares a lot: from math import atan2 as a z = 0.0 # postive zero m = -z # minus zero a(z, z) # the result here is actually +0.0 0.0 a(z, m) 3.1415926535897931 a(m, z)# the result here is actually -0.0 0.0 a(m, m) -3.1415926535897931 It work like that even on Windows, and these are the results C99's 754-happy appendix mandates for atan2 applied to signed zeroes. I've even seen a /complaint/ on c.l.py that atan2 doesn't do the same when z = 0.0 is replaced by z = 0 That is, at least one person thought it was a bug that integer zeroes didn't deliver the same behaviors. Do people actually rely on this? I know I don't, but given that more than just 2 people have remarked on it seeming to like it, I expect that changing this would break /some/ code out there. BTW, on /some/ platforms all those examples trigger EDOM from the platform libm instead -- which is also fine by C99, for implementations ignoring C99's optional 754-happy appendix. ___ 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] Caching float(0.0)
[EMAIL PROTECTED] Can you give a simple example where the difference between the two is apparent to the Python programmer? BTW, I don't recall the details and don't care enough to reconstruct them, but when Python's front end was first changed to recognize negative literals, it treated +0.0 and -0.0 the same, and we did get bug reports as a result. A bit more detail, because it's necessary to understand that even minimally. Python's grammar doesn't have negative numeric literals; e.g., according to the grammar, -1 and -1.1 are applications of the unary minus operator to the positive numeric literals 1 and 1.1. And for years Python generated code accordingly: LOAD_CONST followed by the unary minus opcode. Someone (Fred, I think) introduced a front-end optimization to collapse that to plain LOAD_CONST, doing the negation at compile time. The code object contains a vector of compile-time constants, and the optimized code initially didn't distinguish between +0.0 and -0.0. As a result, if the first float 0.0 in a code block looked postive, /all/ float zeroes in the code block were in effect treated as positive; and similarly if the first float zero was -0.0, all float zeroes were in effect treated as negative. That did break code. IIRC, it was fixed by special-casing the snot out of -0.0, leaving that single case as a LOAD_CONST followed by UNARY_NEGATIVE. ___ 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] what's really new in python 2.5 ?
On Wednesday 04 October 2006 00:32, Neal Norwitz wrote: I probably did not do that to begin with. I did rm -rf Doc svn up Doc cd Doc make. Let me know if there's anything else I should do. I did this for both the 2.5 and 2.6 versions. That certainly sounds like it should be sufficient. The doc build should never write anywhere but within the Doc/ tree; it doesn't even use the tempfile module to pick up any other temporary scratch space. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Caching float(0.0)
On Wednesday 04 October 2006 00:53, Tim Peters wrote: Someone (Fred, I think) introduced a front-end optimization to collapse that to plain LOAD_CONST, doing the negation at compile time. I did the original change to make negative integers use just LOAD_CONST, but I don't think I changed what was generated for float literals. That could be my memory going bad, though. The code changed several times as people with more numeric-fu that myself fixed all sorts of border cases. I've tried really hard to stay away from the code generator since then. :-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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] Created branch for PEP 302 phase 2 work (in C)
On 10/2/06, Brett Cannon [EMAIL PROTECTED] wrote: This is why I asked for input from people on which would take less time. Almost all the answers I got was that the the C code was delicate but that it was workable. Several people said they wished for a Python implementation, but hardly anyone said flat-out, don't waste your time, the Python version will be faster to do. I didn't respond mostly because I pushed this direction to begin with. That and I'm lazy. :-) There is a lot of string manipulation and some list manipulation that is a royal pain in C and trivial in python. Caching will be much easier to experiement with in Python too. The Python version will be much smaller. It will take far less time to code it in Python and recode in C, than to try to get it right in C the first time. If the code is fast enough, there's no reason to rewrite in C. It will probably be easier to subclass a Python based version that a C based version. As for the bootstrapping, I am sure it is resolvable as well. There are several ways to go about it that are all tractable. Right, I had bootstrapping with implementing xrange in Python, but it was pretty easy to resolve in the end. You might even want to use part of that patch (from pythonrun.c?). There was some re-org to make bootstrapping easier/possible (I don't remember exactly right now). n ___ 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] Caching float(0.0)
[Tim] Someone (Fred, I think) introduced a front-end optimization to collapse that to plain LOAD_CONST, doing the negation at compile time. I did the original change to make negative integers use just LOAD_CONST, but I don't think I changed what was generated for float literals. That could be my memory going bad, though. It is ;-) Here under Python 2.2.3: from dis import dis def f(): return 0.0 + -0.0 + 1.0 + -1.0 ... dis(f) 0 SET_LINENO 1 3 SET_LINENO 1 6 LOAD_CONST 1 (0.0) 9 LOAD_CONST 1 (0.0) 12 UNARY_NEGATIVE 13 BINARY_ADD 14 LOAD_CONST 2 (1.0) 17 BINARY_ADD 18 LOAD_CONST 3 (-1.0) 21 BINARY_ADD 22 RETURN_VALUE 23 LOAD_CONST 0 (None) 26 RETURN_VALUE Note there that 0.0, 1.0, and -1.0 were all treated as literals, but that -0.0 still triggered a UNARY_NEGATIVE opcode. That was after the fix. You don't remember this as well as I do since I probably had to fix it, /and/ I ate enormous quantities of chopped, pressed, smoked, preservative-laden bag o' ham at the time. You really need to do both to remember floating-point trivia. Indeed, since I gave up my bag o' ham habit, I hardly ever jump into threads about fp trivia anymore. Mostly it's because I'm too weak from not eating anything, though -- how about lunch tomorrow? The code changed several times as people with more numeric-fu that myself fixed all sorts of border cases. I've tried really hard to stay away from the code generator since then. :-) Successfully, too! It's admirable. ___ 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] Caching float(0.0)
Steve Holden [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
[yet more on this topic]
If the brainpower already expended on this issue were proportional to
its significance then we'd be reading about it on CNN news.
Goodness, I wasn't aware that pointer manipulation took that much
brainpower. I presume you mean what others have spent time thinking
about with regards to this topic.
This thread has disappeared down a rat-hole, never to re-emerge with
anything of significant benefit to users. C'mon, guys, implement a patch
or leave it alone :-)
Heh. So be it. The following is untested (I lack a build system for
the Python trunk). It adds a new global cache for floats, a new 'fill
the global cache' function, and an updated PyFloat_FromDouble() function.
All in all, it took about 10 minutes to generate, and understands the
difference between fp +0.0 and -0.0 (assuming sane IEEE 754 fp double
behavior on non-x86 platforms).
- Josiah
/* This should go into floatobject.c */
static PyFloatObject *cached_list = NULL;
static PyFloatObject *
fill_cached_list(void)
{
cached_list = (PyFloatObject *) 1;
PyFloatObject *p;
int i;
p = (PyFloatObject *) PyMem_MALLOC(sizeof(PyFloatObject)*22);
if (p == NULL) {
cached_list = NULL;
return (PyFloatObject *) PyErr_NoMemory();
}
for (i=0;i=10;i++) {
p[i] = (PyFloatObject*) PyFloat_fromDouble((double) i);
p[21-i] = (PyFloatObject*) PyFloat_fromDouble(-((double) i));
}
cached_list = NULL;
return p;
}
PyObject *
PyFloat_FromDouble(double fval)
{
register PyFloatObject *op;
register long* fvali = (int*)(fval);
if (free_list == NULL) {
if ((free_list = fill_free_list()) == NULL)
return NULL;
}
#ifdef LITTLE_ENDIAN
if (!p[0])
#else
if (!p[1])
#endif
{
if (cached_list == NULL) {
if ((cached_list = fill_cached_list()) == NULL)
return NULL;
}
if ((cached_list != 1) (cached_list != NULL)) {
#ifdef LITTLE_ENDIAN
switch p[1]
#else
switch p[0]
#endif
{
case 0: PY_INCREF(cached_list[0]); return
cached_list[0];
case 1072693248: PY_INCREF(cached_list[1]); return
cached_list[1];
case 1073741824: PY_INCREF(cached_list[2]); return
cached_list[2];
case 1074266112: PY_INCREF(cached_list[3]); return
cached_list[3];
case 1074790400: PY_INCREF(cached_list[4]); return
cached_list[4];
case 1075052544: PY_INCREF(cached_list[5]); return
cached_list[5];
case 1075314688: PY_INCREF(cached_list[6]); return
cached_list[6];
case 1075576832: PY_INCREF(cached_list[7]); return
cached_list[7];
case 1075838976: PY_INCREF(cached_list[8]); return
cached_list[8];
case 1075970048: PY_INCREF(cached_list[9]); return
cached_list[9];
case 1076101120: PY_INCREF(cached_list[10]); return
cached_list[10];
case -1071382528: PY_INCREF(cached_list[11]); return
cached_list[11];
case -1071513600: PY_INCREF(cached_list[12]); return
cached_list[12];
case -1071644672: PY_INCREF(cached_list[13]); return
cached_list[13];
case -1071906816: PY_INCREF(cached_list[14]); return
cached_list[14];
case -1072168960: PY_INCREF(cached_list[15]); return
cached_list[15];
case -1072431104: PY_INCREF(cached_list[16]); return
cached_list[16];
case -1072693248: PY_INCREF(cached_list[17]); return
cached_list[17];
case -1073217536: PY_INCREF(cached_list[18]); return
cached_list[18];
case -1073741824: PY_INCREF(cached_list[19]); return
cached_list[19];
case -1074790400: PY_INCREF(cached_list[20]); return
cached_list[20];
case -2147483648: PY_INCREF(cached_list[21]); return
cached_list[21];
default:
}
}
}
/* Inline PyObject_New */
op = free_list;
free_list = (PyFloatObject *)op-ob_type;
PyObject_INIT(op, PyFloat_Type);
op-ob_fval = fval;
return (PyObject *) op;
}
___
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] Caching float(0.0)
Alastair Houghton schrieb: On 3 Oct 2006, at 17:47, James Y Knight wrote: On Oct 3, 2006, at 8:30 AM, Martin v. Löwis wrote: As Michael Hudson observed, this is difficult to implement, though: You can't distinguish between -0.0 and +0.0 easily, yet you should. Of course you can. It's absolutely trivial. The only part that's even *the least bit* sketchy in this is assuming that a double is 64 bits. Practically speaking, that is true on all architectures I know of, How about doing 1.0 / x, where x is the number you want to test? This is a bad idea. It may cause a trap, leading to program termination. Regards, Martin ___ 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
