Strange numpy.float96 behaviour

What am I missing:

In [66]: import numpy as np

In [67]: np.float(7.0 / 8)
Out[67]: 0.875 #OK

In [68]: np.float32(7.0 / 8)
Out[68]: 0.875 #OK

In [69]: np.float96(7.0 / 8)
Out[69]: -2.6815615859885194e+154 #WTF

In [70]: sys.version
Out[70]: '2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]'

Edit. On cygwin the above code works OK:

$ python
Python 2.5.2 (r252:60911, Dec  2 2008, 09:26:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.float(7.0 / 8)
0.875
>>> np.float96(7.0 / 8)
0.875

For the completeness, I checked this code in plain python (not Ipython):

C:\temp>python
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more informati开发者_运维问答on.
>>> import numpy as np
>>> np.float(7.0 / 8)
0.875
>>> np.float96(7.0 / 8)
-2.6815615859885194e+154
>>>

EDIT

I saw three bug reports on Numpy's trac site (976, 902, and 884), but this one doesn't seem to be related to string representation. Therefore I have opened a new bug (1263). Will update here the progress

---

This works fine for me:

In [1]: import numpy as np

In [2]: np.float(7.0/8)
Out[2]: 0.875

In [3]: np.float96(7.0/8)
Out[3]: 0.875

What Numpy are you using? I'm using Python 2.6.2 and Numpy 1.3.0 and I'm on 64 bit Vista.

I tried this same thing on another computer that is running 32 bit XP with Python 2.5.2 and Numpy 1.2.1 and to my surprise I get:

In [2]: np.float96(7.0/8)
Out[2]: -2.6815615859885194e+154

After some investigation, installing Python 2.6.3 and Numpy 1.3.0 on 32 bit XP, I've found:

In [2]: np.float96(7.0/8)
Out[2]: 0.875

So it must be a bug in either the old version of Numpy or a bug in the old version of Python...

---

The problem is caused by incompatibilities between mingw compiler (the one used for the official numpy binary) and the MS runtime (the one printf is coming from).

MS compiler consider long double and double to be equivalent types, and so does the MS C runtime (printf included). Mingw, for some reason, define long double as big enough to hold 80 bits extended precision numbers, but of course the MS printf does not know about it, and cannot print long double correctly.

We circumvented around some problems by using our own formatting functions, but I think the real fix is to force long double to be a synonym to double when built with mingw. This will be done for numpy 1.5.0, I think.

---

There were a few fixes for long double formatting issues on Windows in 1.3.0; at least http://projects.scipy.org/numpy/changeset/6219 http://projects.scipy.org/numpy/changeset/6218 http://projects.scipy.org/numpy/changeset/6217