Hi, On Thu, Mar 15, 2012 at 9:24 PM, Charles R Harris <[email protected]> wrote: > > > On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau <[email protected]> > wrote: >> >> >> >> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <[email protected]> >> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
