[issue13889] str(float) and round(float) issues with FPU precision

Change by Mark Dickinson : -- pull_requests: -13812 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue13889] str(float) and round(float) issues with FPU precision

Change by STINNER Victor : -- pull_requests: +13812 pull_request: https://github.com/python/cpython/pull/13946 ___ Python tracker ___ __

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Mark Dickinson : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue13889] str(float) and round(float) issues with FPU precision

Roundup Robot added the comment: New changeset bf3b77722c9f by Mark Dickinson in branch '2.7': Issue #13889: On MSVC builds, set FPU control word at runtime for all string <-> float conversions. Patch by Samuel Iseli and Stefan Krah. http://hg.python.org/cpython/rev/bf3b77722c9f -- _

[issue13889] str(float) and round(float) issues with FPU precision

Roundup Robot added the comment: New changeset dfc9a98a5fef by Mark Dickinson in branch '3.2': Issue #13889: On MSVC builds, set FPU control word at runtime for all string <-> float conversions. Patch by Samuel Iseli and Stefan Krah. http://hg.python.org/cpython/rev/dfc9a98a5fef New changeset

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: Slightly reworked patch. I plan to apply this shortly. - Use ~(_MCW_PC | _MCW_RC) rather than (_MCW_DN | ...), since this seems more future proof: there's a possibility that more flags could be added later. - Put the usual do { ... } while (0) around the _P

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: Thanks for the responses. As far as I'm concerned, this is good to go into all 3 maintained branches. Having said that, the 2.7 and 3.2 branches are currently at release candidate stage, so I think we should wait until after the releases. -- __

[issue13889] str(float) and round(float) issues with FPU precision

Stefan Krah added the comment: Stefan Krah wrote: > > Stefan Krah added the comment: > > Mark Dickinson wrote: > > http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.100).aspx > > Question 1: when doing __control87_2(new, mask, &old, NULL), does the > > resulting value in old reflect th

[issue13889] str(float) and round(float) issues with FPU precision

Stefan Krah added the comment: Mark Dickinson wrote: > http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.100).aspx > Question 1: when doing __control87_2(new, mask, &old, NULL), does the > resulting value in old reflect the *new* FPU state or the old one? The new one, but I had to test th

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: BTW, the MSDN documentation at http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.100).aspx is a bit confusing. Question 1: when doing __control87_2(new, mask, &old, NULL), does the resulting value in old reflect the *new* FPU state or the old one? Que

[issue13889] str(float) and round(float) issues with FPU precision

Stefan Krah added the comment: I've looked at the latest patch: It seems that new_387controlword is not set if old_387controlword already has the desired precision and rounding mode. Attached is a revised patch that uses the same logic as the Linux version. A couple of remarks: - It would be

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: Patch looks fine to me. A couple of minor points (which I'm happy to fix at commit time if you agree, and don't want to create a new patch): - it looks to me as though the #ifdef _WIN32 isn't necessary any more; it's enough that we're on MSVC and that this

[issue13889] str(float) and round(float) issues with FPU precision

Samuel Iseli added the comment: Completed the patch by adding the rounding-control bits to the mask (_MCW_RC) and making sure the macros only get defined for MS-VC compiler (#ifdef _MSC_VER). Ran the tests (python_d -m test.autotest) on win32. Seems OK. The tests that were skipped or failed

[issue13889] str(float) and round(float) issues with FPU precision

Stefan Krah added the comment: I can run the tests on win64, but it I think it would be nice to have a patch with exactly the same logic as the gcc-asm version (Mark already mentioned _MCW_PC | _MCW_RC). Another thing: _WIN32 might be defined on MinGW, but I'm not sure. If that's the case, it w

[issue13889] str(float) and round(float) issues with FPU precision

Samuel Iseli added the comment: I can run the tests on 32bit. Would be nice if somebody else could do this on 64bit (my VS2008 machine is currently on 32bit-Windows). -- ___ Python tracker ___

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Antoine Pitrou : -- components: +Windows stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: General shape of the patch looks good. I'd suggest using a mask of _MCW_PC | _MCW_RC instead of just _MCW_PC, so that the rounding mode is also set correctly. Probably rarely an issue in practice, but it's the same thing that we're doing on Linux. If this i

[issue13889] str(float) and round(float) issues with FPU precision

Samuel Iseli added the comment: There's an excess space after a line continuation backslash in my last patch, so it doesn't compile (pyport.h, line 567). Here's an additional patch that removes the space. Didn't find out how to combine the 2 revisions in one patch-file... Sorry about that. --

[issue13889] str(float) and round(float) issues with FPU precision

Samuel Iseli added the comment: I would definitely classify this as a bug in Python 2.7 as it breaks backwards-compatibility for embedding environments that default to 64bit FPU precision (e.g. Delphi). Additionally the bug is very hard to detect and leads to wrong values with possibly disas

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: > Hi Marc, the changes to the pythoncore.vcproj Visual-Studio file define > the > HAVE_VC_FUNC_FOR_X87 symbol. Okay, makes sense. I was distracted by the spurious reordering of in the diff for pythoncore.vcproj. Just to be clear, the intent of the patch is

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: > Should this bug be marked as "closed+committed"? No, the main issue is still under consideration. There were two issues here: (1) a clear bug, namely that the Py_SET_53BIT_PRECISION_* macros weren't being used for the dtoa calls when rounding, and (2) a p

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Jesús Cea Avión : -- assignee: -> mark.dickinson type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue13889] str(float) and round(float) issues with FPU precision

Jesús Cea Avión added the comment: Should this bug be marked as "closed+committed"? -- ___ Python tracker ___ ___ Python-bugs-list ma

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Jesús Cea Avión : -- assignee: mark.dickinson -> nosy: +jcea type: behavior -> ___ Python tracker ___ ___ Python-bugs-lis

[issue13889] str(float) and round(float) issues with FPU precision

Samuel Iseli added the comment: Hi Marc, the changes to the pythoncore.vcproj Visual-Studio file define the HAVE_VC_FUNC_FOR_X87 symbol. I use this symbol to enable the precision-setting macros in pyport.h. I made this similar to the existing code for gcc (linux). You can change this but curr

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Mark Dickinson : -- priority: high -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: > but none to floatobject.c Bah, reading comprehension fail. Now that I look at your patch again, the floatobject.c changes are there (and pretty much match what I just committed). I assume that the changes to pythoncore.vcproj can be disregarded, though?

[issue13889] str(float) and round(float) issues with FPU precision

Roundup Robot added the comment: New changeset 5b884955 by Mark Dickinson in branch '3.2': Issue #13889: Add missing _Py_SET_53BIT_PRECISION_* calls around uses of dtoa.c functions in float round. http://hg.python.org/cpython/rev/5b884955 New changeset 265d35e8fe82 by Mark Dickinson in

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Mark Dickinson : -- type: -> behavior versions: +Python 3.2, Python 3.3 -Python 3.1 ___ Python tracker ___ ___ Python-bugs

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Mark Dickinson : -- assignee: -> mark.dickinson priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list maili

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: I'm a bit disturbed that we're not using the _Py_SET_53BIT_PRECISION_* macros in _Py_double_round; unless I'm missing something, that seems like a major omission. -- ___ Python tracker

[issue13889] str(float) and round(float) issues with FPU precision

Mark Dickinson added the comment: Samuel, can you regenerate your patch? The contents don't look right---I see changes to pyport.h, but none to floatobject.c (and some other spurious-looking changes to the project file). -- ___ Python tracker

[issue13889] str(float) and round(float) issues with FPU precision

Changes by Eric V. Smith : -- nosy: +eric.smith, mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13889] str(float) and round(float) issues with FPU precision

New submission from Samuel Iseli : We are using python as an embedded scripting environment in our ERP-product. Since upgrading to python2.7 we have serious issues with floats: >>> 28710.0 '2870:.0' >>> round(28710.0) 2870.0 We are embedding Python in a Delphi-application. The problem was alre