real128 cmplx ATAN, ATANH - quality of implementation?

[Steve Kargl]

On Fri, Feb 03, 2017 at 03:38:38PM -0700, Dan Nagle wrote:
> 
> > On Feb 3, 2017, at 14:02 , Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> > 
> > On Fri, Feb 03, 2017 at 05:19:51PM +0100, FX wrote:
> >>> No, it is not.  Anton uses x86_64-*-free.  REAL128 maps to REAL(10)
> >>> aka long double complex.  Note, that the standard says that REAL128
> >>> corresponds with a type that occupies 128 bits, which REAL(10) does
> >>> on FreeBSD (long double is padded for 16-byte alignment).
> >> 
> >> Even on other platforms it often does. I had forgotten that.
> >> 
> > 
> > I suspect some users will see REAL128 and think that this maps
> > to an IEEE754-2008 128-bit floating point type with 113-bits of
> > precisions.  This patch will cause gfortran to select the
> > kind type with the larget precision.  Testing on x86_64-*-freebsd
> > with the following program
> > 
> > program foo
> >   use iso_fortran_env
> >   print '(3(I0,1x))', kind(1._REAL32), kind(1._REAL64), kind(1._REAL128)
> > end program foo
> > 
> > gives '4 8 10' without the patch and '4 8 16' with the patch.
> > 
> > What do you think? Should we adopt the patch?
> > 
> 
> Yes, this is a surprise when it arises in my Fortran workshops.
> real128 gives REAL*10 is unexpected by many.
> 

Consider it a learning opportunity for those attending your
workshop :-)

But, seriously, thanks for the input Dan.  I'll defer to FX
here as I'm changing code he wrote.  In particular, if the
routine does not find a suitable real kind type value, it 
will then return -1 or -2.  I don't know what -2 is signalling
to the compiler.   

-- 
Steve
20161221 https://www.youtube.com/watch?v=IbCHE-hONow