octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55538] logspace BIST tests fail when Octave b


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #55538] logspace BIST tests fail when Octave built with LLVM libc++
Date: Mon, 21 Jan 2019 17:25:38 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Follow-up Comment #2, bug #55538 (project octave):

Here is a revised test program:


#include <complex>
#include <limits>
#include <iostream>

int
main (int argc, char *argv[])
{
  double x = 10.0;
  std::complex<double> y {std::numeric_limits<double>::infinity (), 1.0};

  std::complex<double> z1 = std::pow (x, y);
  std::complex<double> z2 = std::pow (std::complex<double> (x), y);
  std::complex<double> z3 = std::exp (y * std::log (x));
  std::complex<double> z4 = std::exp (y * std::log (std::complex<double>
(x)));

  std::cout << z1 << ", "
            << z2 << ", "
            << z3 << ", "
            << z4 << std::endl;
}


And the output:


$ g++ -o x x.cc && ./x
(-inf,inf), (inf,-nan), (-inf,inf), (inf,-nan)
$ clang++ -stdlib=libstdc++ -o x x.cc && ./x
(-inf,inf), (inf,-nan), (-inf,inf), (inf,-nan)
$ clang++ -stdlib=libc++ -o x x.cc && ./x
(inf,-nan), (inf,-nan), (-inf,inf), (inf,-nan)


The difference seems to be that LLVM promotes a non-complex argument to its
complex equivalent and uses 'exp(y*log(x))' on those two values. GCC computes
the result as a special case for a non-complex base and a complex exponent.
Both runtimes agree on the underlying return values, they just disagree about
whether 'pow(double, complex<double>)' should be computed as a special case or
not.

So basically the same as this difference in Octave when built with GCC:


>> power (10, complex (inf, 1))
ans = -Inf + Infi
>> power (complex (10, 0), complex (inf, 1))
ans =  Inf - NaNi


If built with LLVM these will return the same thing.

I can't tell from cppreference whether this is an ambiguity in the spec or
whether either one is definitively correct.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55538>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]