X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Michael Hoffman <b3i4old02 AT sneakemail DOT com>
Subject:  Re: Python 2.5.1: Potential Bug in "print"
Date:  Sat, 22 Sep 2007 08:35:15 +0100
Lines: 66
Message-ID: <fd2gk5$bel$1@sea.gmane.org>
References:  <20070920002241 DOT AHA56826 AT riddler DOT int DOT colorado DOT edu>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
In-Reply-To: <20070920002241.AHA56826@riddler.int.colorado.edu>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Mike MacFerrin wrote:
> I'm a grad student in a Compiler Tools course, and (as part of the course) we're compiling a subset of the Python language down to C, and from there to x86 Assmebly.  Our code has to pass a lengthy series of test-suites for correctness (comparing the output of our compiled C Code with that of native Python code), and I stumbled across what seems to be a quirky bug in Cygwin Python 2.5.1 (the most recent install). 
> 
> To the point.  If I run a simple two-line Python module: 
> 
>   print 0.0 
>   print -0.0 
> 
> ...it gives the following output (as you'd expect): 
> 
>   0.0 
>   0.0 

Not what I would expect or want given that IEEE 754 supports negative zero.

> However, if I remove the first line: 
> 
>   print -0.0 
> 
> ...I get... 
> 
>   -0.0 
> 
> It seems to matter whether I've previously called "print 0.0" in the module.

There is a bug in the Python optimizer 
<http://bugs.python.org/issue1678380> and patch at 
<http://bugs.python.org/issue1678668>.

> No other "print <float>" commands make a difference.

It's not the printing that does it, it's the compilation. When a unit of 
code is compiled in Python 2.5, all the things that compare equal to 0.0 
are collapsed. If you had another sign-sensitive function, you could 
call it and get the same results.

> Obviously, that seems strange (and doesn't follow the Python language definition).

Where is this "Python language definition" and where does this behavior 
contradict it? I believe that this behavior is platform-specific and 
undefined for Python.

> Run python and check for yourself if you wanna see it (from the shell it always prints "-0.0", but from a file it's inconsistent.

Not really. This is from the shell:

 >>> print 0.0, -0.0
0.0 0.0

> Either way, it should just spit out "0.0"). 

I disagree. In the future you should expect -0.0 to consistently spit 
out -0.0.

> In the meantime, I'm a bit frustrated that my code fails certain tests at home on Cygwin (due to no error of my own),

The error is in the tests that expect 0.0 and -0.0 to produce the same 
results. Once this bug is fixed, I don't think they will on Linux 
anymore either.

> Any suggestions or workarounds? 

You can incorporate the patch I've linked, or you can get consistent 
results if you use -(0.0). Also, dealing with IEEE 754 negative zeros 
seems like something that would be useful in a compiler course so you 
should bring it up with your professor.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/