Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid

[John W. Eaton]

On  9-Sep-2005, Laurent Bonnaud wrote:

| Here is the build with g++-3.4.  It is worse than with g++-4.0 (6
| failures instead of 2).

Odd.  My results were:

  3.3: all tests pass

  3.4: all tests pass

  4.0: 1 failed  (FAIL: octave.test/arith/coth-1.m)

My system is Debian testing, updated to the latest packages just
before running my tests.  I built Octave 2.1.71 (downloaded from the
Octave ftp site) using 3.3, 3.4, and 4.0, with the following commands:

  tar zxf octave-2.1.71.tar.gz
  top=`pwd`
  for v in 3.3 3.4
  do
    mkdir $top/$v
    cd $top/$v
    ## since there is no g77-4.0, I used the default g77 (3.4) when
    ## building with gcc/g++ 4.0
    if [ "$v" = "4.0" ]; then G77=g77; else G77=g77-$v; fi
    ../octave-2.1.71/configure --enable-shared --disable-static CC=gcc-$v CXX=g++-$v F77=$G77
    make all check
  done

The failed test is:

  x = [pi/2*i, 3*pi/2*i];
  v = [0, 0];
  all (abs (coth (x) - v) < sqrt (eps))

Running this by hand (and looking at what is actually produced by coth
instead of just the final result) shows

  octave:4> coth(x)
  ans =

	     NaN -         NaNi           NaN -         NaNi

At least it is NaN, which will show up in obvious ways later on in a
calculation, instead of just some incorrect numerical result.  But
still, I would prefer that this bug be fixed before Octave packages
built with gcc 4.0 are distributed.

Octave's coth function is just a simple

  function w = coth (z)

    if (nargin != 1)
      usage ("coth (z)");
    endif

    w = 1 ./ tanh (z);

  endfunction

but tanh is a built-in function, and it is returning

  octave:7> tanh (x)
  ans =

	     NaN +         Infi           NaN +         Infi

for the same X as above.

The 4.0 <complex> header has

  // 26.2.8/15 tanh(__z):  Returns the hyperbolic tangent of __z.
  
  template<typename _Tp>
    inline complex<_Tp>
    __complex_tanh(const complex<_Tp>& __z)
    { return std::sinh(__z) / std::cosh(__z); }

#if _GLIBCXX_USE_C99_COMPLEX
  inline __complex__ float
  __complex_tanh(__complex__ float __z) { return __builtin_ctanhf(__z); }

  inline __complex__ double
  __complex_tanh(__complex__ double __z) { return __builtin_ctanh(__z); }

  inline __complex__ long double
  __complex_tanh(const __complex__ long double& __z)
  { return __builtin_ctanhl(__z); }

  template<typename _Tp>
    inline complex<_Tp>
    tanh(const complex<_Tp>& __z) { return __complex_tanh(__z.__rep()); }
#else
  template<typename _Tp>
    inline complex<_Tp>
    tanh(const complex<_Tp>& __z) { return __complex_tanh(__z); }
#endif

while the 3.3 <complex> header has

  template<typename _Tp>
    inline complex<_Tp>
    tanh(const complex<_Tp>& __z)
    {
      return sinh(__z) / cosh(__z);
    }

so my guess is the bug is in the __builtin_ctanh code.

Here is a simpler test case:

  #include <cmath>
  #include <iostream>
  #include <complex>

  int
  main (void)
  {
    std::cout << std::tanh (std::complex<double> (0, M_PI/2)) << std::endl;
    std::cout << std::tanh (std::complex<double> (0, 3*M_PI/2)) << std::endl;

    return 0;
  }

I think this should produce (0, inf) in both cases.  With 3.3, it is
still not right, as it produces

  (0,1.63318e+16)
  (0,5.44393e+15)

but at least it does not give NaN.

Or, is the C math library standard written so that tanh is required to
give (nan, inf) here?

Thanks,

jwe