[Numpy-discussion] [Numpy] quadruple precision
Charles R Harris
Wed Feb 29 14:19:57 CST 2012
On Wed, Feb 29, 2012 at 1:09 PM, Francesc Alted <firstname.lastname@example.org>wrote:
> 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  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.
The quad precision library has been there for a while, and quad precision
is also supported by the Intel compiler. I don't know about MSVC. Intel has
been working on adding quad precision to their hardware for several years
and there is an IEEE spec for it, so some day it will be here, but it isn't
here yet. It's a bit sad, I could use quad precision in FORTRAN on a VAX 25
years ago. Mind, I only needed it once ;) I suppose lack of pressing need
accounts for the delay.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion