[Numpy-discussion] float128 in fact float80

[Matthew Brett]

Hi,

On Sun, Oct 16, 2011 at 1:18 AM, David Cournapeau <cournape at gmail.com> wrote:
> On Sun, Oct 16, 2011 at 8:33 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> On Sun, Oct 16, 2011 at 12:28 AM, David Cournapeau <cournape at gmail.com> wrote:
>>> On Sun, Oct 16, 2011 at 8:04 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Sat, Oct 15, 2011 at 11:04 PM, Nadav Horesh <nadavh at visionsense.com> wrote:
>>>>> On 32 bit systems it consumes 96 bits (3 x 32). and hence float96
>>>>> On 64 bit machines it consumes 128 bits (2x64).
>>>>> The variable size is set for an efficient addressing, while the calculation in hardware is carried in the 80 bits FPU (x87) registers.
>>>>
>>>> Right - but the problem here is that it is very confusing.  There is
>>>> something called binary128 in the IEEE standard, and what numpy has is
>>>> not that.  float16, float32 and float64 are all IEEE standards called
>>>> binary16, binary32 and binary64.
>>>
>>> This one is easy: few CPU support the 128 bits float specified in IEEE
>>> standard (the only ones I know are the expensive IBM ones). Then there
>>> are the cases where it is implemented in software (SPARC use the
>>> double-pair IIRC).
>>>
>>> So you would need binar80, binary96, binary128, binary128_double_pair,
>>> etc... That would be a nightmare to support, and also not portable:
>>> what does binary80 become on ppc ? What does binary96 become on 32
>>> bits Intel ? Or on windows (where long double is the same as double
>>> for visual studio) ?
>>>
>>> binary128 should only be thought as a (bad) synonym to np.longdouble.
>>
>> What would be the nightmare to support - the different names for the
>> different precisions?
>
> Well, if you have an array of np.float80, what does it do on ppc, or
> windows, or solaris ? You will have a myriad of incompatible formats,
> and the only thing you gained by naming them differently is that you
> lose the ability of using the code on different platforms. The
> alternative is to implement in software a quadruple precision number.

The thing you gain by naming them correctly is the person using the
format knows what it is.

If we use float64 we know what that is.  If we are using float128,
we've got no idea what it is.

I had actually guessed that numpy had some software emulation for IEEE
float128.   I don't know how I would have known otherwise.

Obviously what I'm proposing is that the names follow the precisions
of the numbers, not the itemsize.

If what we actually have is something that is sometimes called
float128, sometimes float96, that is always what C thinks of as long
double, then surely the best option  would be:

float80
floatLD

for intel 32 and 64 bit, and then

floatPPC
floatLD

for whatever PPC has, and so on.

See you,

Matthew