Hi, Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits? If so, is it useful? Has anyone got a windows64 box to check float128 ? Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import numpy as np np.__version__ '1.6.1' info = np.finfo(np.float96) print info Machine parameters for float96
precision= 15 resolution= 1e-15 machep= -52 eps= 2.22044604925e-16 negep = -53 epsneg= 1.11022302463e-16 minexp=-16382 tiny= 0.0 maxexp= 16384 max= 1.#INF nexp = 15 min= -max ---------------------------------------------------------------------
info.nmant 52
Confirming 52 (+1 implicit) significand digits
np.float96(2**52)+1 4503599627370497.0 np.float96(2**53)+1 9007199254740992.0
float96 claims 15 exponent digits (nexp above), but in fact it appears to have 11, as does float64
np.float64(2**1022) * 2 8.9884656743115795e+307 np.float64(2**1022) * 4 __main__:1: RuntimeWarning: overflow encountered in double_scalars inf np.float96(2**1022) * 2 8.9884656743115795e+307 np.float96(2**1022) * 4 1.#INF
It does take up 12 bytes (96 bits)
np.dtype(np.float96).itemsize 12
Thanks, Matthew
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces you to have sizeof(long double) >= sizeof(double)).
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on windows 64. David
On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau <cournape@gmail.com>wrote:
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces you to have sizeof(long double) >= sizeof(double)).
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on windows 64.
Wait, MSVC doesn't support extended precision, so how do we get doubles padded to 96 bits? I think MINGW supports extended precision but the MS libraries won't. Still, if it's doubles it should be 64 bits and float96 shouldn't exist. Doubles padded to 96 bits are 150% pointless. Chuck
Hi, On Thu, Mar 15, 2012 at 9:24 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces you to have sizeof(long double) >= sizeof(double)).
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on windows 64.
Wait, MSVC doesn't support extended precision, so how do we get doubles padded to 96 bits? I think MINGW supports extended precision but the MS libraries won't. Still, if it's doubles it should be 64 bits and float96 shouldn't exist. Doubles padded to 96 bits are 150% pointless.
I think David is arguing that longdouble for MSVC is indeed a 96 bit padded float64 unless I misunderstand him. If we were thinking of trade-offs I suppose one could argue that the confusion and wasted memory of float96 might outweigh the simple ability to read in binary files containing these values, on the basis that one can do it anyway (by using a structured array dtype) and that such files must be very rare in practice. See you, Matthew
On Thursday, March 15, 2012, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau <cournape@gmail.com>
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com>
wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on
windows 64.
Wait, MSVC doesn't support extended precision, so how do we get doubles
wrote: directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces you to have sizeof(long double) >= sizeof(double)). padded to 96 bits? I think MINGW supports extended precision but the MS libraries won't. Still, if it's doubles it should be 64 bits and float96 shouldn't exist. Doubles padded to 96 bits are 150% pointless.
Chuck
There is a Microsoft joke in there, somewhere... Ben Root
Hi, On Thu, Mar 15, 2012 at 9:17 PM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces you to have sizeof(long double) >= sizeof(double)).
I propose then to rename this one to float64_96 . The nexp value in finfo(np.float96) is incorrect I believe, I'll make a ticket for it.
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on windows 64.
Should you have time to do that, could you confirm it's also a padded float64 and that nexp is still (incorrectly) 15? That would be a great help, Thanks, Matthew
I just happened to have an xp64 VM running: My version of numpy (1.6.1) does not have float128 (see more below what I get in ipython session). If you need to test something else please let me know. Val --- Enthought Python Distribution -- www.enthought.com Python 2.7.2 |EPD 7.2-2 (64-bit)| (default, Jul 3 2011, 15:34:33) [MSC v.1500 6 4 bit (AMD64)] Type "copyright", "credits" or "license" for more information. IPython 0.12 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. Welcome to pylab, a matplotlib-based Python environment [backend: WXAgg]. For more information, type 'help(pylab)'. In [1]: import numpy as np In [2]: np.__version__ Out[2]: '1.6.1' In [3]: np.flo np.float np.float32 np.float_ np.floor np.float16 np.float64 np.floating np.floor_divide In [3]: np.flo On Thu, Mar 15, 2012 at 11:25 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 15, 2012 at 9:17 PM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett@gmail.com
wrote:
Hi,
Am I right in thinking that float96 on windows 32 bit is a float64 padded to 96 bits?
Yes
If so, is it useful?
Yes: this is what allows you to use dtype to parse complex binary files directly in numpy without having to care so much about those details. And that's how it is defined on windows in any case (C standard only forces
you
to have sizeof(long double) >= sizeof(double)).
I propose then to rename this one to float64_96 .
The nexp value in finfo(np.float96) is incorrect I believe, I'll make a ticket for it.
Has anyone got a windows64 box to check float128 ?
Too lazy to check on my vm, but I am pretty sure it is 16 bytes on windows 64.
Should you have time to do that, could you confirm it's also a padded float64 and that nexp is still (incorrectly) 15? That would be a great help,
Thanks,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Thu, Mar 15, 2012 at 9:33 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I just happened to have an xp64 VM running: My version of numpy (1.6.1) does not have float128 (see more below what I get in ipython session). If you need to test something else please let me know.
Thanks a lot - that's helpful. What do you get for: print np.finfo(np.longdouble) ? Best, Matthew
I does look like a joke. Here is print np.finfo(np.longdouble) In [2]: np.__version__ Out[2]: '1.6.1' In [3]: np.flo np.float np.float32 np.float_ np.floor np.float16 np.float64 np.floating np.floor_divide In [3]: print np.finfo(np.longdouble) Machine parameters for float64 --------------------------------------------------------------------- precision= 15 resolution= 1e-15 machep= -52 eps= 2.22044604925e-16 negep = -53 epsneg= 1.11022302463e-16 minexp= -1022 tiny= 2.22507385851e-308 maxexp= 1024 max= 1.79769313486e+308 nexp = 11 min= -max --------------------------------------------------------------------- On Thu, Mar 15, 2012 at 11:38 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 15, 2012 at 9:33 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I just happened to have an xp64 VM running: My version of numpy (1.6.1) does not have float128 (see more below what I get in ipython session). If you need to test something else please let me know.
Thanks a lot - that's helpful. What do you get for:
print np.finfo(np.longdouble)
?
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Mar 15, 2012 at 11:41 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I does look like a joke. Here is print np.finfo(np.longdouble)
In [2]: np.__version__ Out[2]: '1.6.1'
In [3]: np.flo np.float np.float32 np.float_ np.floor np.float16 np.float64 np.floating np.floor_divide
In [3]: print np.finfo(np.longdouble) Machine parameters for float64 --------------------------------------------------------------------- precision= 15 resolution= 1e-15 machep= -52 eps= 2.22044604925e-16 negep = -53 epsneg= 1.11022302463e-16 minexp= -1022 tiny= 2.22507385851e-308 maxexp= 1024 max= 1.79769313486e+308 nexp = 11 min= -max ---------------------------------------------------------------------
In this case (Win64), np.longdouble is just an alias for np.float64: In [16]: sys.version Out[16]: '2.7.2 |EPD 7.2-2 (64-bit)| (default, Sep 14 2011, 11:25:00) [MSC v.1500 64 bit (AMD64)]' In [17]: np.__version__ Out[17]: '1.6.1' In [18]: np.longdouble Out[18]: numpy.float64 Warren
On Thu, Mar 15, 2012 at 11:38 PM, Matthew Brett <matthew.brett@gmail.com>wrote:
Hi,
On Thu, Mar 15, 2012 at 9:33 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I just happened to have an xp64 VM running: My version of numpy (1.6.1) does not have float128 (see more below what
I
get in ipython session). If you need to test something else please let me know.
Thanks a lot - that's helpful. What do you get for:
print np.finfo(np.longdouble)
?
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Thu, Mar 15, 2012 at 9:41 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I does look like a joke. Here is print np.finfo(np.longdouble)
In [2]: np.__version__ Out[2]: '1.6.1'
In [3]: np.flo np.float np.float32 np.float_ np.floor np.float16 np.float64 np.floating np.floor_divide
In [3]: print np.finfo(np.longdouble) Machine parameters for float64 --------------------------------------------------------------------- precision= 15 resolution= 1e-15 machep= -52 eps= 2.22044604925e-16 negep = -53 epsneg= 1.11022302463e-16 minexp= -1022 tiny= 2.22507385851e-308 maxexp= 1024 max= 1.79769313486e+308 nexp = 11 min= -max ---------------------------------------------------------------------
Great - much easier on the eye - longdouble is float64 as expected. Thanks, Matthew
I'm seeing the same thing on both (64 and 32-bit) Windows EPD test machines. I guess Windows does not support 128 bit floats. I did some tests a few weeks ago, and discovered that also on the Mac and Linux long long double is not really 128 bits. If I remember correctly it was 80 bits: 1 (sign) + 16 (exp) + 63 (mantissa) - Ilan On Thu, Mar 15, 2012 at 11:52 PM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Mar 15, 2012 at 9:41 PM, Val Kalatsky <kalatsky@gmail.com> wrote:
I does look like a joke. Here is print np.finfo(np.longdouble)
In [2]: np.__version__ Out[2]: '1.6.1'
In [3]: np.flo np.float np.float32 np.float_ np.floor np.float16 np.float64 np.floating np.floor_divide
In [3]: print np.finfo(np.longdouble) Machine parameters for float64 --------------------------------------------------------------------- precision= 15 resolution= 1e-15 machep= -52 eps= 2.22044604925e-16 negep = -53 epsneg= 1.11022302463e-16 minexp= -1022 tiny= 2.22507385851e-308 maxexp= 1024 max= 1.79769313486e+308 nexp = 11 min= -max ---------------------------------------------------------------------
Great - much easier on the eye - longdouble is float64 as expected.
Thanks,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Thu, Mar 15, 2012 at 10:17 PM, Ilan Schnell <ischnell@enthought.com> wrote:
I'm seeing the same thing on both (64 and 32-bit) Windows EPD test machines. I guess Windows does not support 128 bit floats.
Do you mean there is no float96 on windows 32 bit as I described at the beginning of the thread?
I did some tests a few weeks ago, and discovered that also on the Mac and Linux long long double is not really 128 bits. If I remember correctly it was 80 bits: 1 (sign) + 16 (exp) + 63 (mantissa)
Yes, that's right, on Intel for linux and OSX longdouble is 80 bit precision. Thanks, Matthew
To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128 - Ilan On Fri, Mar 16, 2012 at 12:22 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Mar 15, 2012 at 10:17 PM, Ilan Schnell <ischnell@enthought.com> wrote:
I'm seeing the same thing on both (64 and 32-bit) Windows EPD test machines. I guess Windows does not support 128 bit floats.
Do you mean there is no float96 on windows 32 bit as I described at the beginning of the thread?
I did some tests a few weeks ago, and discovered that also on the Mac and Linux long long double is not really 128 bits. If I remember correctly it was 80 bits: 1 (sign) + 16 (exp) + 63 (mantissa)
Yes, that's right, on Intel for linux and OSX longdouble is 80 bit precision.
Thanks,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell <ischnell@enthought.com> wrote:
To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128
Do you have any idea why I am seeing float96 and you are not? I'm on XP with the current sourceforge 1.6.1 exe installer with python.org 2.7 (and same for python.org 2.6 and numpy 1.5.1). Thanks, Matthew
I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow. - Ilan On Fri, Mar 16, 2012 at 12:40 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell <ischnell@enthought.com> wrote:
To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128
Do you have any idea why I am seeing float96 and you are not? I'm on XP with the current sourceforge 1.6.1 exe installer with python.org 2.7 (and same for python.org 2.6 and numpy 1.5.1).
Thanks,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Mar 16, 2012 at 2:10 AM, Ilan Schnell <ischnell@enthought.com> wrote:
I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No
numpy 1.5.1 MingW, on python 2.6 win32 has float96, float128 no numpy 1.6.1 Gohlke (MKL I think) on python 3.2 win64 no float96, no float128 Josef
I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow.
- Ilan
On Fri, Mar 16, 2012 at 12:40 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Thu, Mar 15, 2012 at 10:26 PM, Ilan Schnell <ischnell@enthought.com> wrote:
To be more precise. On both 32-bit and 64-bit Windows machines I don't see.float96 as well as np.float128
Do you have any idea why I am seeing float96 and you are not? I'm on XP with the current sourceforge 1.6.1 exe installer with python.org 2.7 (and same for python.org 2.6 and numpy 1.5.1).
Thanks,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Fri, Mar 16, 2012 at 5:36 AM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 16, 2012 at 2:10 AM, Ilan Schnell <ischnell@enthought.com> wrote:
I just did a quick test across all supported EPD platforms: win-64: float96 No, float128 No win-32: float96 No, float128 No osx-64: float96 No, float128 Yes osx-32: float96 No, float128 Yes rh3-64: float96 No, float128 Yes rh3-32: float96 Yes, float128 No rh5-64: float96 No, float128 Yes rh5-32: float96 Yes, float128 No sol-64: float96 No, float128 Yes sol-32: float96 Yes, float128 No
numpy 1.5.1 MingW, on python 2.6 win32 has float96, float128 no numpy 1.6.1 Gohlke (MKL I think) on python 3.2 win64 no float96, no float128
Josef
I have no explanation for this, but I'm guessing David C. has. I'll look more into this tomorrow.
- Ilan
Oh dear - I completely forgot the previous thread that I started on this : http://mail.scipy.org/pipermail/numpy-discussion/2011-November/059233.html You young people, don't laugh, this will happen to you one day. Anyway, summarizing, it appears that windows float96: a) Is stored as an 80 bit extended precision number b) Uses float64 precision for all calculations. c) Is specific to MingW builds of numpy - I think. Perhaps David C you'll correct me if I've got that wrong, Best, Matthew
participants (8)
-
Benjamin Root -
Charles R Harris -
David Cournapeau -
Ilan Schnell -
josef.pktd＠gmail.com -
Matthew Brett -
Val Kalatsky -
Warren Weckesser