[Numpy-discussion] float96 on windows32 is float64?

Matthew Brett matthew.brett at gmail.com
Fri Mar 16 00:29:43 EDT 2012


Hi,

On Thu, Mar 15, 2012 at 9:24 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Thu, Mar 15, 2012 at 10:17 PM, David Cournapeau <cournape at gmail.com>
> wrote:
>>
>>
>>
>> On Thu, Mar 15, 2012 at 11:10 PM, Matthew Brett <matthew.brett at 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



More information about the NumPy-Discussion mailing list