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
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
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
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.
--
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
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
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&#x
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
<http://bugs.python.
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
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
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
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
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
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&#x
14 matches
Mail list logo
