[Numpy-discussion] [Numpy] quadruple precision

[Francesc Alted]

On Feb 29, 2012, at 11:52 AM, Pierre Haessig wrote:

> Hi,
> 
> Le 29/02/2012 16:22, Paweł Biernat a écrit :
>> Is there any way to interact with Fortran's real(16) (supported by gcc
>> and Intel's ifort) data type from numpy? By real(16) I mean the
>> binary128 type as in IEEE 754. (In C this data type is experimentally
>> supported as __float128 (gcc) and _Quad (Intel's icc).) 
> I googled a bit this "__float128". It seems a fairly new addition (GCC
> 4.6, released March 2011).
> The related point in the changelog [1] is :
> 
> "GCC now ships with the LGPL-licensed libquadmath library, which
> provides quad-precision mathematical functions for targets with a
> __float128 datatype. __float128 is available for targets on 32-bit x86,
> x86-64 and Itanium architectures. The libquadmath library is
> automatically built on such targets when building the Fortran compiler."

Great find!

> It seems this __float128 is newcomer in the "picture of data types" that
> Matthew just mentioned.
> As David says, arithmetic with such a 128 bits data type is probably not
> "hardwired" in most processors (I mean Intel & friends) which are
> limited to 80 bits ("long doubles") so it may be a bit slow. However,
> this GCC implementation with libquadmath seems to create some level of
> abstraction. Maybe this is one acceptably good way for a real "IEEE
> float 128" dtype in numpy ?

That would be really nice.  The problem here is two-folded:

* Backwards-compatibility.  float128 should represent a different data-type than before, so we probably should find a new name (and charcode!) for quad-precision.  Maybe quad128?

* Compiler-dependency.  The new type will be only available on platforms that has GCC 4.6 or above.  Again, using the new name for this should be fine.  On platforms/compilers not supporting the quad128 thing, it should not be defined.

Uh, I foresee many portability problems for people using this, but perhaps it is worth the mess.

-- Francesc Alted