[issue6198] test_float fails on Windows

2009-06-09 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

In r73314, I restored the one test erroneously removed (%#.0f 1.5 - 2.).

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Antoine Pitrou

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +marketdickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Changes by Eric Smith e...@trueblade.com:


--
nosy: +eric.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

I can duplicate this with Visual C++ 9.0 Express Edition on XP.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

Thanks for the report.  It sounds as though I might have backported
some tests from py3k to trunk that shouldn't have been backported.

abbeyj or eric, do you know whether py3k also has this failure on your 
machine?  I'm hoping not:  py3k doesn't use the CRT *printf functions for 
float formatting, so the test should pass there.

--
assignee:  - marketdickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

Yes, this test passes on py3k on my Windows box. That would be a
nightmare if it didn't!

I agree that this is a test problem, not a code problem. I suggest we
just remove the offending line from formatfloat_testcases.txt in trunk.
I can do this and verify it works on Windows before checking in, if
you'd like.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

[Eric]
 I can do this and verify it works on Windows before checking in, if
 you'd like.

That would be great---yes, please!  My main computer died yesterday, 
taking my Windows access and my python svn access with it. :-(

--
assignee: marketdickinson - eric.smith

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

I had to remove a bunch of tests. Some were of the form
even-number5, rounded to before the 5. Some were comparing a large
number of digits.

Then there's these:
%#.0g 0 - 0. Got '0.0'
%#.1g 0 - 0. Got '0.0'
%#.2g 0 - 0.0Got '0.00'
%#.3g 0 - 0.00   Got '0.000'
%#.4g 0 - 0.000  Got '0.'

I'm going to remove these, too, since they're all based on underlying
printf differences. But they seem like a bigger problem than the other
cases.

--
assignee: eric.smith - marketdickinson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

Checked in to trunk in r73240.

--
assignee: marketdickinson - eric.smith
resolution:  - fixed
stage:  - committed/rejected
status: open - closed
type:  - behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

Thanks, Eric.  All those changes look good to me.

Out of interest, what does '%#.0f' % 1.5 produce on
Python 2.7/Windows?  I'd expect to get '2.' both for
round-half-to-even and round-half-away-from-zero.
Does Windows round this down to '1.' instead?

I'm surprised by the %#.ng results for 0;  this looks
like questionable behaviour (producing n+1 digits when
only n significant digits were requested).  Is the MS
implementation of printf directly responsible for this,
or is the CPython code somehow adding the extra 0?
If this is just the way that Windows behaves for formatting
of zeros, then I suppose we could add code to work around
this, but it's not clear that it's really worth it.

I suspect that we're in for some complaints when
Windows users discover that Python 3.1 string formatting
does round-half-to-even rather than the round-half-up
they're used to in Python 2.x.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Tim Peters

Tim Peters tim.pet...@gmail.com added the comment:

 Out of interest, what does '%#.0f' % 1.5 produce on
 Python 2.7/Windows?

Microsoft's float-string routines have always done add a half and
chop rounding.  So, yes, 1.5 rounds to 2 there.

 ...
 I suspect that we're in for some complaints when
 Windows users discover that Python 3.1 string
 formatting does round-half-to-even rather than
 the round-half-up they're used to in Python 2.x.

Historically, overall we've had more gripes from non-Windows users
complaining that, e.g., 2.5 does /not/ round up to 3 -- you can't win
here, so don't worry about it.  X-platform consistency is incompatible
with platform-specific behavior, and most users will agree consistency
is overwhelmingly more important.  Of course that won't deter them from
complaining ;-)

--
nosy: +tim_one

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

Mark Dickinson wrote:
 Out of interest, what does '%#.0f' % 1.5 produce on
 Python 2.7/Windows?  I'd expect to get '2.' both for
 round-half-to-even and round-half-away-from-zero.
 Does Windows round this down to '1.' instead?

Windows in trunk gives '2.'.

 I'm surprised by the %#.ng results for 0;  this looks
 like questionable behaviour (producing n+1 digits when
 only n significant digits were requested).  Is the MS
 implementation of printf directly responsible for this,
 or is the CPython code somehow adding the extra 0?
 If this is just the way that Windows behaves for formatting
 of zeros, then I suppose we could add code to work around
 this, but it's not clear that it's really worth it.

This is from a C program on Windows, using printf:
%#.0g: 0.0
%#.1g: 0.0
%#.2g: 0.00
%#.3g: 0.000

Same program on Linux:
%#.0g: 0.
%#.1g: 0.
%#.2g: 0.0
%#.3g: 0.00

In 2.6 on Windows:
  '%#.1g' % 0.0
'0.0'
  '%#.2g' % 0.0
'0.00'

In 2.6 on Linux:
  '%#.1g' % 0.0
'0.'
  '%#.2g' % 0.0
'0.0'

So this isn't a problem we caused with the short repr work, it's 
pre-existing. I don't think it's worth working around, but that's me. 
%-formatting should just die.

 I suspect that we're in for some complaints when
 Windows users discover that Python 3.1 string formatting
 does round-half-to-even rather than the round-half-up
 they're used to in Python 2.x.

But at least in 3.1 it will now be consistent cross-platform. Can't have 
it both ways!

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Mark Dickinson

Mark Dickinson dicki...@gmail.com added the comment:

[Mark]
 Out of interest, what does '%#.0f' % 1.5 produce on
 Python 2.7/Windows?  I'd expect to get '2.' both for
 round-half-to-even and round-half-away-from-zero.
 Does Windows round this down to '1.' instead?

[Eric]
 Windows in trunk gives '2.'.

Thanks.  I was mainly wondering why you'd commented out the
line %#.0f 1.5 - 2. in the formatfloat_testcases.txt
file.

[Eric, about zero formatting on Windows]
 So this isn't a problem we caused with the short repr work, it's 
 pre-existing. I don't think it's worth working around, but that's me.

I agree it doesn't seem worth working around.  Let's wait until
somebody complains. :-)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-05 Thread Eric Smith

Eric Smith e...@trueblade.com added the comment:

 [Mark]
 Out of interest, what does '%#.0f' % 1.5 produce on
 Python 2.7/Windows?  I'd expect to get '2.' both for
 round-half-to-even and round-half-away-from-zero.
 Does Windows round this down to '1.' instead?
 
 [Eric]
 Windows in trunk gives '2.'.
 
[Mark]
 Thanks.  I was mainly wondering why you'd commented out the
 line %#.0f 1.5 - 2. in the formatfloat_testcases.txt
 file.

Over-zealous commenting out on my part. I'm away from my Windows box,
but I'll correct this next week and check it back in with that line
re-enabled.

Thanks for catching that.

--
resolution: fixed - 
status: closed - open

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue6198] test_float fails on Windows

2009-06-04 Thread James Abbatiello

New submission from James Abbatiello abb...@gmail.com:

test_float fails on Windows with:
==
FAIL: test_format_testfile (test.test_float.IEEEFormatTestCase)
--
Traceback (most recent call last):
  File C:\Projects\python-trunk\lib\test\test_float.py, line 319, in
test_format_testfile
self.assertEqual(fmt % float(arg), rhs)
AssertionError: '3' != '2'

--


The problematic line from formatfloat_testcases.txt is:
%.0f 2.5 - 2


On some systems *printf() uses round-to-even.  But the Windows CRT uses
round-half-away-from-zero.  Consider the following C code:
printf(%+.1f - %+.0f\n, -2.5, -2.5);
printf(%+.1f - %+.0f\n, -1.5, -1.5);
printf(%+.1f - %+.0f\n, +1.5, +1.5);
printf(%+.1f - %+.0f\n, +2.5, +2.5);

On Linux this will produce:
-2.5 - -2
-1.5 - -2
+1.5 - +2
+2.5 - +2

And on Windows:
-2.5 - -3
-1.5 - -2
+1.5 - +2
+2.5 - +3

--
components: Tests, Windows
messages: 88922
nosy: abbeyj
severity: normal
status: open
title: test_float fails on Windows
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6198
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com