Re: [Python-Dev] Caching float(0.0)

[Nick Craig-Wood]

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)

[Nick Craig-Wood]

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)

[Fredrik Lundh]

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").



___
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]

"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

[Nick Coghlan]

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  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)

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

[Fuzzyman]

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.
>
>  
>

___
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)

[Kristján V . Jónsson]

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)

[Nick Maclaren]

=?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)

[skip]

>> 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 Maclaren]

[EMAIL PROTECTED] wrote:
>
> Doesn't that presume that optimizing just 0.0 could be done easily?  Suppose
> 0.0 is generated all over the place in EVE?

Yes, and it isn't, respectively!  The changes in floatobject.c would
be trivial (if tedious), and my recollection of my scan is that
floating values are not generated elsewhere.

It would be equally easy to add a general caching algorithm, but
that would be a LOT slower than a simple floating-point comparison.
The problem (in Python) isn't hooking the checks into place,
though it could be if Python were implemented differently.


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)

[Martin v. Löwis]

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)

[Martin v. Löwis]

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 ?

[Fredrik Lundh]

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".

 



___
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]

=?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

[A.M. Kuchling]

I've gone through the 'backport candidate' bugs listed on
 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

[Nick Coghlan]

Fuzzyman wrote:
> Nick Coghlan wrote:
>> In my example, the 3 sections (,  and > completion 
>> 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
___
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 v. Löwis]

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 ?

[Fred L. Drake, Jr.]

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.   
___
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]

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
___
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 ?

[Nick Coghlan]

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 ?

[A.M. Kuchling]

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

[A.M. Kuchling]

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 ?

[Fred L. Drake, Jr.]

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.   
___
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]

=?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)

[Martin v. Löwis]

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)

[Nicko van Someren]

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

[Aahz]

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

[Paul Moore]

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)

[James Y Knight]

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)

[Martin v. Löwis]

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)

[skip]

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)

[skip]

Martin> b) it is likely that this change won't affect a significant
Martin>number of applications (I'm pretty sure someone will notice,
Martin>though; 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)

[Scott David Daniels]

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)

[Martin v. Löwis]

[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 ?

[A.M. Kuchling]

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 ?

[Fred L. Drake, Jr.]

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.   
___
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]

=?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)

[James Y Knight]

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)

[Martin v. Löwis]

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

[Ron Adam]

Nick Coghlan wrote:
> Fuzzyman wrote:
>> Nick Coghlan wrote:
>>> In my example, the 3 sections (,  and >> completion 
>>> 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]

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)

[Gregory P. Smith]

> > 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)

[Alastair Houghton]

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)

[Josiah Carlson]

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

[Tony Nelson]

I've put a patch for 2.4.4 of the Socketmodule Ctl-C patch for 2.5, at the
old closed bug  .  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 
  '  is no more. 
___
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]

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)

[Guido van Rossum]

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 ?

[Neal Norwitz]

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)

[Tim Peters]

[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)

[Tim Peters]

[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 ?

[Fred L. Drake, Jr.]

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.   
___
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)

[Fred L. Drake, Jr.]

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.   
___
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)

[Neal Norwitz]

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 Peters]

[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)

[Josiah Carlson]

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)

[Martin v. Löwis]

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

Re: [Python-Dev] [Python-checkins] r51862 - python/branches/release25-maint/Tools/msi/msi.py

[Neal Norwitz]

On 9/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> If you wonder how this all happened: Neal added sgml_input.html after
> c1, but didn't edit msi.py to make it included on Windows. I found out
> after running the test suite on the installed version, edited msi.py,
> and rebuilt the installer.

Is there an easy to fix this sort of problem so it doesn't happen in
the future (other than revoke my checkin privileges :-) ?

There are already so many things to remember for changes.  If we can
automate finding these sorts of problems (installation, fixing
something for one platform, but not another, etc), the submitter can
fix these things with a little prodding from the buildbots.  Or is
this too minor to worry about?

It would also be great if we could automate complaint emails about
missing NEWS entries, doc, and tests so I wouldn't have to do it. :-)
Unless anyone has better ideas how to improve Python.

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] [Python-checkins] r51862 - python/branches/release25-maint/Tools/msi/msi.py

[Martin v. Löwis]

Neal Norwitz schrieb:
> Is there an easy to fix this sort of problem so it doesn't happen in
> the future (other than revoke my checkin privileges :-) ?

Sure: Don't make changes after a release candidate. That files are
missing can only be detected by actually producing the installer and
testing whether it works; the closer the release, the less testing
recent changes get.

It might be possible to improve msi.py to better guess what files
are test files, but I'd rather package too little than too much.
One thing it *should* do is to report files that it skipped - but
that really just helps me, since you have to run msi.py to see
these messages.

> There are already so many things to remember for changes.  If we can
> automate finding these sorts of problems (installation, fixing
> something for one platform, but not another, etc), the submitter can
> fix these things with a little prodding from the buildbots.  Or is
> this too minor to worry about?

This specific instance is not to worry about. I noticed before making
the release, and fixed it; me changing the branch while it is frozen
is not even a policy violation. It's unfortunate that you can't
recreate the installer from the tag that had been made, but it's just
a release candidate, so that's a really minor issue.

> It would also be great if we could automate complaint emails about
> missing NEWS entries, doc, and tests so I wouldn't have to do it. :-)
> Unless anyone has better ideas how to improve Python.

I don't think this can be automated in a reasonable way. People
apparently have different views on what is good policy and what
is overkill; in a free software project, you can only have so
much policy enforcement. If there is a wide consensus on some
issue, committers will pick up the consensus; if they don't,
it typically means they disagree.

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