Re: [Python-Dev] Caching float(0.0)
On 4 Oct 2006, at 06:34, Martin v. Löwis wrote: > 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. AFAIK few systems have floating point traps enabled by default (in fact, isn't that what IEEE 754 specifies?), because they often aren't very useful. And in the specific case of the Python interpreter, why would you ever want them turned on? Surely in order to get consistent floating point semantics, they need to be *off* and Python needs to handle any exceptional cases itself; even if they're on, by your argument Python must do that to avoid being terminated. (Not to mention the problem that floating point traps are typically delivered by a signal, the problems with which were discussed extensively in a recent thread on this list.) And it does have two advantages over the other methods proposed: 1. You don't have to write the value to memory; this test will work entirely in the machine's floating point registers. 2. It doesn't rely on the machine using IEEE floating point. (Of course, neither does the binary comparison method, but it still involves a trip to memory, and assumes that the machine doesn't have multiple representations for +0.0 or -0.0.) Even if you're saying that there's a significant chance of a trap (which I don't believe, not on common platforms anyway), the configure script could test to see if this will happen and fall back to one of the other approaches, or see if it can't turn them off using the C99 APIs. (I think I'd agree with you that handling SIGFPE is undesirable, which is perhaps what you were driving at.) Anyway, it's only an idea, and I thought I'd point it out as nobody else had yet. If 0.0 is going to be cached, then I certainly think -0.0 and +0.0 should be two separate values if they exist on a given machine. I'm less concerned about exactly how that comes about. Kind regards, Alastair. -- http://alastairs-place.net ___ Python-Dev mailing list [email protected] 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 4 Oct 2006, at 02:38, Josiah Carlson wrote:
> Alastair Houghton <[EMAIL PROTECTED]> wrote:
>
> 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...
Yes, though a trip via memory isn't necessarily cheap, and you're
also assuming that the machine doesn't use an FP representation with
multiple +0s or -0s. Perhaps they should be different anyway though,
I suppose.
> 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 */
> ...
> }
> }
That's worse, IMHO, because it assumes more about the
representation. If you're going to look directly at the binary, I
think all you can reasonably do is a straight binary comparison. I
don't think you should poke at the bits without first knowing that
the platform uses IEEE floating point.
The reason I suggested 1.0/x is that it's one of the few ways (maybe
the only way?) to distinguish -0.0 and +0.0 using arithmetic, which
is what people that care about the difference between the two are
going to care about.
Kind regards,
Alastair.
--
http://alastairs-place.net
___
Python-Dev mailing list
[email protected]
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
Hi Nick,
Yep, PEP 315. Sorry about that.
Now, about your suggestion
do:
while
else:
This is pythonic, but not logical. The 'do' will execute at least once, so
the else clause is not needed, nor is the . The should go before the while terminator.
I'm bound to reiterate my proposal:
do:
while
Example (if you know there will be at least one val).
source.open()
do:
val = source.read(1)
process(val)
while val != lastitem
source.close()
The c syntax is:
do
{
block of code
} while (condition is satisfied);
The VB syntax is:
do
block
loop while
Cheers & thanks for your reply,
Hans Polak.
-Original Message-
From: Nick Coghlan [mailto:[EMAIL PROTECTED]
Sent: domingo, 01 de octubre de 2006 6:18
To: Hans Polak
Cc: [email protected]
Subject: Re: [Python-Dev] PEP 351 - do while
Hans Polak wrote:
> Hi,
>
>
>
> Just an opinion, but many uses of the 'while true loop' are instances of
> a 'do loop'. I appreciate the language layout question, so I'll give you
> an alternative:
>
>
>
> do:
>
>
>
>
>
> while
>
I believe you meant to write PEP 315 in the subject line :)
To fully account for loop else clauses, this suggestion would probably need
to
be modified to look something like this:
Basic while loop:
while :
else:
Using break to avoid code duplication:
while True:
if not :
break
Current version of PEP 315:
do:
while :
else:
This suggestion:
do:
while
else:
I personally like that style, and if the compiler can dig through a function
looking for yield statements to identify generators, it should be able to
dig
through a do-loop looking for the termination condition.
As I recall, the main objection to this style was that it could hide the
loop
termination condition, but that isn't actually mentioned in the PEP (and in
the typical do-while case, the loop condition will still be clearly visible
at
the end of the loop body).
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
___
Python-Dev mailing list
[email protected]
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
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: while else: Cheers, Hans. -Original Message- From: Nick Coghlan [mailto:[EMAIL PROTECTED] Sent: lunes, 02 de octubre de 2006 12:48 To: Hans Polak Cc: [email protected] Subject: Re: [Python-Dev] PEP 315 - do while Hans Polak wrote: > Hi Nick, > > Yep, PEP 315. Sorry about that. > > Now, about your suggestion > do: > > while > > else: > > > This is pythonic, but not logical. The 'do' will execute at least once, so > the else clause is not needed, nor is the . The body> should go before the while terminator. This objection is based on a misunderstanding of what the else clause is for in a Python loop. The else clause is only executed if the loop terminated naturally (the exit condition became false) rather than being explicitly terminated using a break statement. This behaviour is most commonly useful when using a for loop to search through an iterable (breaking when the object is found, and using the else clause to handle the 'not found' case), but it is also defined for while loops. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Python-Dev mailing list [email protected] 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
Thanks for your reply Nick, and your support Michael. I'll leave the PEP talk to you guys :) Cheers, Hans -Original Message- From: Michael Foord [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: martes, 03 de octubre de 2006 12:00 To: Nick Coghlan Cc: Hans Polak; [email protected] Subject: 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: >> >> >> while >> else: >> >> >> > >In my example, the 3 sections (, and code> are all optional. A basic do-while loop would look like this: > > do: > > while > >(That is, 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 : 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. > > > This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Python-Dev mailing list [email protected] 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
I'm against infinite loops -something religious :), which explains the call for the do loop. The issue about the parser is over my head, but the thought had occurred to me. Now, it would not affect while loops inside do loops, wouldn't it? Cheers, Hans. -Original Message- From: Nick Coghlan [mailto:[EMAIL PROTECTED] Sent: martes, 03 de octubre de 2006 15:51 To: Fuzzyman Cc: Hans Polak; [email protected] Subject: Re: [Python-Dev] PEP 315 - do while Fuzzyman wrote: > Nick Coghlan wrote: >> In my example, the 3 sections (, and > code> are all optional. A basic do-while loop would look like this: >> >> do: >> >> while >> >> (That is, 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 : >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 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Python-Dev mailing list [email protected] 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
Please note that until <==> while not. do: until count > 10 do: while count <= 10 Cheers, Hans. -Original Message- From: Michael Foord [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: martes, 03 de octubre de 2006 16:29 To: Nick Coghlan Cc: Hans Polak; [email protected] Subject: Re: [Python-Dev] PEP 315 - do while Nick Coghlan wrote: > [snip..] > >> The current idiom works fine, but looks unnatural : >> >> while True: >> if : >>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: until 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 ''.) 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 This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ Python-Dev mailing list [email protected] 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: > > AFAIK few systems have floating point traps enabled by default (in > fact, isn't that what IEEE 754 specifies?), because they often aren't > very useful. The first two statements are true; the last isn't. They are extremely useful, not least because they are the only practical way to locate numeric errors in most 3 GL programs (including C, Fortran etc.) > And in the specific case of the Python interpreter, why > would you ever want them turned on? Surely in order to get > consistent floating point semantics, they need to be *off* and Python > needs to handle any exceptional cases itself; even if they're on, by > your argument Python must do that to avoid being terminated. Grrk. Why are you assuming that turning them off means that the result is what you expect? That isn't always so - sometimes it merely means that you get wrong answers but no indication of that. > or see if it can't turn them off using the C99 APIs. That is a REALLY bad idea. You have no idea how broken that is, and what the impact it would be on Python. 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 [email protected] 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 <[EMAIL PROTECTED]> wrote: > > 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. Perhaps you might like to think why only IBM POWERx (and NOT the Cell or most embedded POWERs) is the ONLY mainstream system to have implemented all of IEEE 754 in hardware after 22 years? Or why NO programming language has provided support in those 22 years, and only Java and C have even claimed to? See Kahan's "How Javas Floating-Point Hurts Everyone Everywhere", note that C99 is much WORSE, and then note that Java and C99 are the only languages that have even attempted to include IEEE 754. You have also misunderstood the issue. The fact that a C implementation doesn't support it does NOT mean that the implementation is defective; quite the contrary. The issue always has been that IEEE 754's basic model is incompatible with the basic models of all programming languages that I am familiar with (which is a lot). And the specific problems with C99 are in the STANDARD, not the IMPLEMENTATIONS. > 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). Firstly, see the above. Secondly, Python would need MAJOR semantic changes to conform to IEEE 754R. Thirdly, what would you say to the people who want reliable error detection on floating-point of the form that Python currently provides? 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 [email protected] 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 Wed, Oct 04, 2006 at 12:42:04AM -0400, Tim Peters wrote:
> [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
This actually returns -0.0 under linux...
> >>> 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.
Probably!
It surely isn't a big problem though is it?
instead of writing
if (result == 0.0)
returned cached_float_0;
we just write something like
if (memcmp((&result, &static_zero, sizeof(double)) == 0))
returned cached_float_0;
Eg the below prints (gcc/linux)
The memcmp() way
1: 0 == 0.0
2: -0 != 0.0
The == way
3: 0 == 0.0
4: -0 == 0.0
#include
#include
int main(void)
{
static double zero_value = 0.0;
double result;
printf("The memcmp() way\n");
result = 0.0;
if (memcmp(&result, &zero_value, sizeof(double)) == 0)
printf("1: %g == 0.0\n", result);
else
printf("1: %g != 0.0\n", result);
result = -0.0;
if (memcmp(&result, &zero_value, sizeof(double)) == 0)
printf("2: %g == 0.0\n", result);
else
printf("2: %g != 0.0\n", result);
printf("The == way\n");
result = 0.0;
if (result == 0.0)
printf("3: %g == 0.0\n", result);
else
printf("3: %g != 0.0\n", result);
result = -0.0;
if (result == 0.0)
printf("4: %g == 0.0\n", result);
else
printf("4: %g != 0.0\n", result);
return 0;
}
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
___
Python-Dev mailing list
[email protected]
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)
Hm, doesn´t seem to be so for my regular python. Python 2.3.3 Stackless 3.0 040407 (#51, Apr 7 2004, 19:28:46) [MSC v.1200 32 bi t (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> x = -0.0 >>> y = 0.0 >>> x,y (0.0, 0.0) >>> maybe it is 2.3.3, or maybe it is stackless from back then. K > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of "Martin v. Löwis" > Sent: 3. október 2006 17:56 > To: [EMAIL PROTECTED] > Cc: Nick Maclaren; [email protected] > Subject: 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 ___ Python-Dev mailing list [email protected] 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 Wed, Oct 04, 2006 at 12:42:04AM -0400, Tim Peters wrote: > > > 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? > > Perhaps surprsingly, many (well, comparatively many, compared to none > ) people have noticed that the platform atan2 cares a lot: Once upon a time, floating-point was used as an approximation to mathematical real numbers, and anything which was mathematically undefined in real arithmetic was regarded as an error in floating- point. This allowed a reasonable amount of numeric validation, because the main remaining discrepancy was that floating-point has only limited precision and range. Most of the numerical experts that I know of still favour that approach, and it is the one standardised by the ISO LIA-1, LIA-2 and LIA-3 standards for floating-point arithmetic. atan2(0.0,0.0) should be an error. But C99 differs. While words do not fail me, they are inappropriate for this mailing list :-( 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 [email protected] 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 09:32:43PM -0700, Neal Norwitz wrote: > Let me know if you see anything screwed up after an hour or so. The > new versions should be up by then. Thanks! That seems to have cleared things up -- the section names are now node2.html, node3.html, ..., which is what I'd expect for the 2.6 document. --amk ___ Python-Dev mailing list [email protected] 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
You are all wasting your time on this. It won't go in. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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
On 10/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > You are all wasting your time on this. It won't go in. +1 from me. Should you mark PEP 315 as rejected? Jeremy > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] 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
I'll mark it as withdrawn. Raymond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Hylton Sent: Wednesday, October 04, 2006 8:44 AM To: Guido van Rossum Cc: Hans Polak; [email protected] Subject: Re: [Python-Dev] PEP 315 - do while On 10/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > You are all wasting your time on this. It won't go in. +1 from me. Should you mark PEP 315 as rejected? Jeremy > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/rhettinger%40ewtllc.co m ___ Python-Dev mailing list [email protected] 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/3/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: 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. :-)But couldn't you be lazy in a timely fashion? There is a lot of string manipulation and some list manipulation thatis a royal pain in C and trivial in python. Caching will be mucheasier to experiement with in Python too. The Python version will bemuch 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 thecode is fast enough, there's no reason to rewrite in C. It willprobably be easier to subclass a Python based version that a C basedversion. > 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 usepart of that patch (from pythonrun.c?). There was some re-org to makebootstrapping easier/possible (I don't remember exactly right now). OK, OK, I get the hint. I will rewrite import in Python and just make it my research work and personal project. Probably will do the initial pure Python stuff in the sandbox to really isolate it and then move it over to the pep302_phase2 branch when C code has to be changed. -Brett ___ Python-Dev mailing list [email protected] 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: > AFAIK few systems have floating point traps enabled by default (in fact, > isn't that what IEEE 754 specifies?), because they often aren't very > useful. And in the specific case of the Python interpreter, why would > you ever want them turned on? That reasoning is irrelevant. If it breaks a few systems, that already is some systems too many. Python should never crash; and we have no control over the floating point exception handling in any portable manner. Regards, Martin ___ Python-Dev mailing list [email protected] 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)
Kristján V. Jónsson schrieb: > Hm, doesn´t seem to be so for my regular python. > > maybe it is 2.3.3, or maybe it is stackless from back then. It's because you are using Windows. The way -0.0 gets rendered depends on the platform. As Tim points out, try math.atan2(0.0, -0.0) vs math.atan2(0.0, 0.0). Regards, Martin ___ Python-Dev mailing list [email protected] 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 4, 2006, at 8:14 PM, Martin v. Löwis wrote: > If it breaks a few systems, that already is some systems too many. > Python should never crash; and we have no control over the floating > point exception handling in any portable manner. You're quite right, though there is already plenty of platform dependent code in Python for just that purpose (see fpectlmodule.c, for instance). Anyway, all I originally wanted was to point out that using division was one possible way to tell the difference that didn't involve relying on the representation being IEEE compliant. It's true that there are problems with FP exceptions. Kind regards, Alastair. -- http://alastairs-place.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: [ python-Feature Requests-1567948 ] poplib.py list interface
I've made some changes to poplib.py, submitted them to Sourceforge, and emailed Piers regarding taking over maintenance of the module. I have his support to do so, along with Guido's. However, I would like to ask one of the more senior developers to review the change and commit it. Many thanks for your kind assistance! -- Forwarded message --From: SourceForge.net < [EMAIL PROTECTED]>Date: 04-Oct-2006 13:29 Subject: [ python-Feature Requests-1567948 ] poplib.py list interfaceTo: [EMAIL PROTECTED] Feature Requests item #1567948, was opened at 2006-09-29 11:51 Message generated for change (Comment added) made by hdiwan650You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470 Please note that this message will contain a full copy of the comment thread,including the initial issue submission, for this request,not just the latest update.Category: Python LibraryGroup: Python 2.6Status: OpenResolution: NonePriority: 5Submitted By: Hasan Diwan (hdiwan650)Assigned to: Nobody/Anonymous (nobody)Summary: poplib.py list interfaceInitial Comment:Adds a list-like interface to poplib.py, poplib_as_list.-->Comment By: Hasan Diwan (hdiwan650)Date: 2006-10-04 13:29Message:Logged In: YESuser_id=1185570 I changed it a little bit, added my name at the top of thefile as the maintainer.--You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567948&group_id=5470-- Cheers,Hasan Diwan < [EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom
I've never liked the "".join([]) idiom for string concatenation; in my opinion it violates the principles "Beautiful is better than ugly." and "There should be one-- and preferably only one --obvious way to do it.". (And perhaps several others.) To that end I've submitted patch #1569040 to SourceForge: http://sourceforge.net/tracker/index.php?func=detail&aid=1569040&group_id=5470&atid=305470 This patch speeds up using + for string concatenation. It's been in discussion on c.l.p for about a week, here: http://groups.google.com/group/comp.lang.python/browse_frm/thread/b8a8f20bc3c81bcf I'm not a Python guru, and my initial benchmark had many mistakes. With help from the community correct benchmarks emerged: + for string concatenation is now roughly as fast as the usual "".join() idiom when appending. (It appears to be *much* faster for prepending.) The patched Python passes all the tests in regrtest.py for which I have source; I didn't install external packages such as bsddb and sqlite3. My approach was to add a "string concatenation" object; I have since learned this is also called a "rope". Internally, a PyStringConcatationObject is exactly like a PyStringObject but with a few extra members taking an additional thirty-six bytes of storage. When you add two PyStringObjects together, string_concat() returns a PyStringConcatationObject which contains references to the two strings. Concatenating any mixture of PyStringObjects and PyStringConcatationObjects works similarly, though there are some internal optimizations. These changes are almost entirely contained within Objects/stringobject.c and Include/stringobject.h. There is one major externally-visible change in this patch: PyStringObject.ob_sval is no longer a char[1] array, but a char *. Happily, this only requires a recompile, because the CPython source is *marvelously* consistent about using the macro PyString_AS_STRING(). (One hopes extension authors are as consistent.) I only had to touch two other files (Python/ceval.c and Objects/codeobject.c) and those were one-line changes. There is one remaining place that still needs fixing: the self-described "hack" in Mac/Modules/MacOS.c. Fixing that is beyond my pay grade. I changed the representation of ob_sval for two reasons: first, it is initially NULL for a string concatenation object, and second, because it may point to separately-allocated memory. That's where the speedup came from--it doesn't render the string until someone asks for the string's value. It is telling to see my new implementation of PyString_AS_STRING, as follows (casts and extra parentheses removed for legibility): #define PyString_AS_STRING(x) ( x->ob_sval ? x->ob_sval : PyString_AsString(x) ) This adds a layer of indirection for the string and a branch, adding a tiny (but measurable) slowdown to the general case. Again, because the changes to PyStringObject are hidden by this macro, external users of these objects don't notice the difference. The patch is posted, and I have donned the thickest skin I have handy. I look forward to your feedback. Cheers, /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
