<br><br><div class="gmail_quote">On Sun, Nov 13, 2011 at 3:56 PM, Matthew Brett <span dir="ltr"><<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
On Sun, Nov 13, 2011 at 1:34 PM, Charles R Harris<br>
<div><div class="h5"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sun, Nov 13, 2011 at 2:25 PM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Sun, Nov 13, 2011 at 8:21 AM, Charles R Harris<br>
>> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Sun, Nov 13, 2011 at 12:57 AM, Matthew Brett<br>
>> > <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> On Sat, Nov 12, 2011 at 11:35 PM, Matthew Brett<br>
>> >> <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Hi,<br>
>> >> ><br>
>> >> > Sorry for my continued confusion here.  This is numpy 1.6.1 on<br>
>> >> > windows<br>
>> >> > XP 32 bit.<br>
>> >> ><br>
>> >> > In [2]: np.finfo(np.float96).nmant<br>
>> >> > Out[2]: 52<br>
>> >> ><br>
>> >> > In [3]: np.finfo(np.float96).nexp<br>
>> >> > Out[3]: 15<br>
>> >> ><br>
>> >> > In [4]: np.finfo(np.float64).nmant<br>
>> >> > Out[4]: 52<br>
>> >> ><br>
>> >> > In [5]: np.finfo(np.float64).nexp<br>
>> >> > Out[5]: 11<br>
>> >> ><br>
>> >> > If there are 52 bits of precision, 2**53+1 should not be<br>
>> >> > representable, and sure enough:<br>
>> >> ><br>
>> >> > In [6]: np.float96(2**53)+1<br>
>> >> > Out[6]: 9007199254740992.0<br>
>> >> ><br>
>> >> > In [7]: np.float64(2**53)+1<br>
>> >> > Out[7]: 9007199254740992.0<br>
>> >> ><br>
>> >> > If the nexp is right, the max should be higher for the float96 type:<br>
>> >> ><br>
>> >> > In [9]: np.finfo(np.float64).max<br>
>> >> > Out[9]: 1.7976931348623157e+308<br>
>> >> ><br>
>> >> > In [10]: np.finfo(np.float96).max<br>
>> >> > Out[10]: 1.#INF<br>
>> >> ><br>
>> >> > I see that long double in C is 12 bytes wide, and double is the usual<br>
>> >> > 8<br>
>> >> > bytes.<br>
>> >><br>
>> >> Sorry - sizeof(long double) is 12 using mingw.  I see that long double<br>
>> >> is the same as double in MS Visual C++.<br>
>> >><br>
>> >> <a href="http://en.wikipedia.org/wiki/Long_double" target="_blank">http://en.wikipedia.org/wiki/Long_double</a><br>
>> >><br>
>> >> but, as expected from the name:<br>
>> >><br>
>> >> In [11]: np.dtype(np.float96).itemsize<br>
>> >> Out[11]: 12<br>
>> >><br>
>> ><br>
>> > Hmm, good point. There should not be a float96 on Windows using the MSVC<br>
>> > compiler, and the longdouble types 'gG' should return float64 and<br>
>> > complex128<br>
>> > respectively. OTOH, I believe the mingw compiler has real float96 types<br>
>> > but<br>
>> > I wonder about library support. This is really a build issue and it<br>
>> > would be<br>
>> > good to have some feedback on what different platforms are doing so that<br>
>> > we<br>
>> > know if we are doing things right.<br>
>><br>
>> Is it possible that numpy is getting confused by being compiled with<br>
>> mingw on top of a visual studio python?<br>
>><br>
>> Some further forensics seem to suggest that, despite the fact the math<br>
>> suggests float96 is float64, the storage format it in fact 80-bit<br>
>> extended precision:<br>
>><br>
><br>
> Yes, extended precision is the type on Intel hardware with gcc, the 96/128<br>
> bits comes from alignment on 4 or 8 byte boundaries. With MSVC, double and<br>
> long double are both ieee double, and on SPARC, long double is ieee quad<br>
> precision.<br>
<br>
</div></div>Right - but I think my researches are showing that the longdouble<br>
numbers are being _stored_ as 80 bit, but the math on those numbers is<br>
64 bit.<br>
<br>
Is there a reason than numpy can't do 80-bit math on these guys?  If<br>
there is, is there any point in having a float96 on windows?<br></blockquote><div><br>It's a compiler/architecture thing and depends on how the compiler interprets the long double c type. The gcc compiler does do 80 bit math on Intel/AMD hardware. MSVC doesn't, and probably never will. MSVC shouldn't produce float96 numbers, if it does, it is a bug. Mingw uses the gcc compiler, so the numbers are there, but if it uses the MS library it will have to convert them to double to do computations like sin(x) since there are no microsoft routines for extended precision. I suspect that gcc/ms combo is what is producing the odd results you are seeing.<br>
<br>Chuck<br></div><br></div>