Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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 pyscrip...@gmail.com 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 pyscrip...@gmail.com 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 pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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 pyscrip...@gmail.com 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 rep
Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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
Kiriakos Vlahos pyscrip...@gmail.com 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
New submission from Kiriakos Vlahos pyscrip...@gmail.com:
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
14 matches
Mail list logo
