[issue9980] str(float) failure

Mark Dickinson added the comment: Closing as "won't fix", for reasons given above. -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ _

[issue9980] str(float) failure

Mark Dickinson added the comment: > For example C# uses 80 bit precision No, I don't think that's true. It uses the x87, with its 64-bit internal precision, but I'm fairly sure that (as is almost always true in a Windows environment, except if you're using Delphi, apparently) the FPU precisi

[issue9980] str(float) failure

Muhammad Alkarouri added the comment: On 15 October 2010 06:52, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > Interesting. I'd like to propose than that this is resolved as "won't fix", > i.e. embedding Python into Delphi is declared as just not supported (or using > floa

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: I would like to say that these are two separate issues. One is about the precision flag and the second about the exception masking flags of the FPU control words. Both issues affect a wider number of users than Python embedders using Delphi. For example C#

[issue9980] str(float) failure

Martin v. Löwis added the comment: Interesting. I'd like to propose than that this is resolved as "won't fix", i.e. embedding Python into Delphi is declared as just not supported (or using floating-point operations in such an environment is not supported). --

[issue9980] str(float) failure

Muhammad Alkarouri added the comment: I cam across another issue that was triggered by the same problem. I am explaining it here though I am not sure if it is going to affect the solution one way or the other. The issue is explained in the post http://stackoverflow.com/questions/3933851/nan-

[issue9980] str(float) failure

Changes by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: >>How about doing the check in Py_Initialize() instead? Then it will >>work for >>embedders too. It is not good practice for DLLs to change the FPU control word when loaded, because the host application may have set it to a specific value for a good reason.

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: >>How about doing the check in Py_Initialize() instead? Then it will >>work for >>embedders too. It is not good practice for DLLs to change the FPU control word when loaded, because the host application may have set it to a specific value for a good reason.

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: >>For PyScripter, can you alter your Delphi layer to drop back to the >>normal >>default 53-bit precision before calling any Python stuff? Yes sure. That is how I traced the source of the problem. -- ___ Python t

[issue9980] str(float) failure

Antoine Pitrou added the comment: > There's a configure-time check that works out whether resetting the > precision is necessary; if so, the precision is changed before each > conversion and reverted again afterwards How about doing the check in Py_Initialize() instead? Then it will work for

[issue9980] str(float) failure

Tim Peters added the comment: About thread state, the C standard is no help. That's an OS decision. All OSes I'm aware of do save/restore FPU state across thread switches. Doesn't mean all OSes do, just that I don't know of an exception. -- nosy: +tim_one _

[issue9980] str(float) failure

Stefan Krah added the comment: On an older Celeron platform the differences are up to 7%, but again, the number that is converted has a far greater impact: None: = >>> s = "str(38210.0)" >>> t = timeit.Timer(stmt=s) >>> >>> t.timeit(number=100) 3.277189016342163 >>> t.timeit(number=1

[issue9980] str(float) failure

Stefan Krah added the comment: The tracker swallowed some parts of my mail: In general, execution times for _Py_dg_dtoa vary quite a bit depending on the number that is converted: >>> s = "str(1.5e300)" >>> t = timeit.Timer(stmt=s) >>> t.timeit(number=1000) 5.09749007225036

[issue9980] str(float) failure

Stefan Krah added the comment: Mark Dickinson wrote: > Whoops; that *was* string to float. How about float to string? These are the results for format_float_short. The first one is quite funny: If the control word is left as is (64-bit prec on Linux), _Py_dg_dtoa apparently requires more it

[issue9980] str(float) failure

Mark Dickinson added the comment: > I would feel more comfortable if the correct FPU state is guaranteed. I agree, in principle. In practice there are some thorny issues to deal with, and things to think about: (1) The method for getting and setting the FPU precision varies from platform to

[issue9980] str(float) failure

Mark Dickinson added the comment: Whoops; that *was* string to float. How about float to string? -- ___ Python tracker ___ ___ Pytho

[issue9980] str(float) failure

Mark Dickinson added the comment: Thanks for the numbers, Stefan. What about in the reverse direction (string to float)? I don't expect any real difference there, either, but it would be good to check. -- ___ Python tracker

[issue9980] str(float) failure

Stefan Krah added the comment: I benchmarked _PyOS_ascii_strtod without the macros, with the macros and with always calling both fnstcw/fldcw. There is no real difference: import timeit s = "str(38210.0)" t = timeit.Timer(stmt=s) t.timeit(number=1000) t.timeit(number=1000) t.timeit(n

[issue9980] str(float) failure

Stefan Krah added the comment: I wonder if calling _Py_SET_53BIT_PRECISION_START/_Py_SET_53BIT_PRECISION_END every time will have any measurable effect on performance. First, string conversions have a lot of overhead already. Then, for compilers that already set the correct control word, only

[issue9980] str(float) failure

Mark Dickinson added the comment: > It looks like you may need to override these macros for PyScripter. Stupid. Of course, this isn't an option if you're using the existing Python dll directly. For PyScripter, can you alter your Delphi layer to drop back to the normal default 53-bit precisi

[issue9980] str(float) failure

Mark Dickinson added the comment: [Eric] > There's no doubt a performance issue with doing so, although someone > would have to measure that. It may well be swamped by the memory > allocation, etc. that is going on at the same time and so won't matter. Yes, I think changing the FPU state involv

[issue9980] str(float) failure

Mark Dickinson added the comment: > Delphi uses the following code at initialization. Yep. That would explain the problem. On x86 machines, Python's string-to-float and float-to-string conversions require that the x87 FPU has precision set to 53 bits rather than 64 bits (and also that the F

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: I found out that $x2xx (test both $12xx and $02xx) gives identical results to python. Here is what it means. The PC field (bits 9 and 8) or Precision Control determines to what precision the FPU rounds results after each arithmetic instruction in one of thr

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: Also note that different compilers initialize the FPU control word with different values. This creates a problem with embedded python that behaves differently or even produces wrong results depending on which language/compiler is used to embed it. At least

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: Actually with control word $0032 or $3F I still do not get identical results to python.exe. PyScripter >>> '%.12g' % 38210.0 '38210.0009918' >>> str(38210.0) '38210.0009918' Python >>> '%.12g' % 38210.0 '38210' >>> str(38210.0) '38210.0' Does anybody know w

[issue9980] str(float) failure

Eric Smith added the comment: I agree that in an ideal world there would not be a dependency on global flags. There's no doubt a performance issue with doing so, although someone would have to measure that. It may well be swamped by the memory allocation, etc. that is going on at the same tim

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: If _Py_dg_dtoa requires a specific FPU control word to work correctly, it should save its state, set it to the desired state and restore it after finishing. -- ___ Python tracker

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: OK problem solved! If I set the FPU control word to $00xx I get the correct answers. Now I think that if _Py_dg_dtoa depends on specific values for the FPU control word that is bad design and likely to lead to such problems. --

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: Let me that add that it is impossible to fully unit test for the correctness of the str(float). I only found out by accident, because one of the users bumped into such a case. I tried to find a pattern in the misbehaved cased and it was rather difficult.

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: Does _Py_dg_dtoa depend on FPU flags that affect rounding or exceptions? I failed to mention that python is embedded in a Delphi executable. Delphi uses the following code at initialization. procedure _FpuInit; asm FNINIT FWAIT {$IFDE

[issue9980] str(float) failure

Changes by Martin v. Löwis : -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue9980] str(float) failure

Stefan Krah added the comment: I can reproduce this using the internal (embedded python) of PyScripter (nice work BTW!). I can't reproduce it under any other circumstances. The test case from #9215 runs fine in VS, and also this produces the correct output: #include int main(int argc, char

[issue9980] str(float) failure

Mark Dickinson added the comment: Added the extra test cases (for py3k only) in r85119. -- ___ Python tracker ___ ___ Python-bugs-list

[issue9980] str(float) failure

Mark Dickinson added the comment: > It's interesting to note that '9' is ascii 57, and ':' is 58. Right; it's that part that convinces me that the problem is somewhere deep in _Py_dg_dtoa, in the guts of the float to string conversion, where a xxx99... result is rounded up to xx(x+1)

[issue9980] str(float) failure

Brian Curtin added the comment: I get different results than Kiriakos' last example. >PCbuild\amd64\python_d.exe Python 3.2a2+ (py3k, Sep 29 2010, 09:43:42) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> '%.12g' % 38210.0 '38210

[issue9980] str(float) failure

Eric Smith added the comment: It's interesting to note that '9' is ascii 57, and ':' is 58. It's like the code is incrementing the wrong digit. If it's related to that, that indeed sounds like a compiler optimization bug to me, but of course I'm just guessing. And I'm not sure that conclusion

[issue9980] str(float) failure

Changes by Mark Dickinson : -- versions: +Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue9980] str(float) failure

Mark Dickinson added the comment: > The puzzling thing is that the same Python.dll when used by python.exe and > not PyScripter produces correct results. Yes, this is indeed puzzling. Are you absolutely sure that both python.exe and PyScripter are using the exact same Python.dll file? E.g.,

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: Answer to Mark's question: *** Python 3.2a2 (r32a2:84522, Sep 5 2010, 22:35:34) [MSC v.1500 32 bit (Intel)] on win32. *** >>> '%.12g' % 38210.0 '3820:' So indeed the error still exists in _Py_dg_dtoa. The internal engine uses an embedded python.dll. The r

[issue9980] str(float) failure

Kiriakos Vlahos added the comment: PyScripter is a Windows only IDE. I am using the official release *** Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32. *** Python 3.2a2 fixes this since, according to SVN, str is now using the same code (or at least the s

[issue9980] str(float) failure

Eric Smith added the comment: >From their web page, it looks like PyScripter only runs on Windows, so I >assume these results are generated there. I won't be able to test on Windows until tonight. Kiriakos: Does this only happen within PyScripter, or does it also happen when you use the pyth

[issue9980] str(float) failure

Mark Dickinson added the comment: > I'm surprised that 3.2 fixes this: the float-to-string conversion code > is > pretty much identical in both 3.1 and 3.2. Whoops---not quite. The conversion code *is* pretty much identical, but 3.2 now uses a different algorithm for str (it's equal to repr

[issue9980] str(float) failure

Mark Dickinson added the comment: This sounds similar to issue 9215, which was due to a compiler optimization bug. Certainly it points to something going wrong in _Py_dg_dtoa. What platform are these results from? Do you have minimal code that can be used to reproduce? I'm surprised that 3.

[issue9980] str(float) failure

Changes by R. David Murray : -- nosy: +eric.smith, mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9980] str(float) failure

Changes by John Machin : -- nosy: +sjmachin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue9980] str(float) failure

New submission from Kiriakos Vlahos : I am the author of PyScripter a popular python IDE (pyscripter.googlecode.com). Following a user report I found out that str(float) occasionally produces wrong results with Python 2.7 and 3.1. eg. >>> str(38210.0) //wrong '3820:.0' >>> str(37210.0) // co