4

According to https://stackoverflow.com/a/17932632/1700939, it should be possible to use complex numbers with boost::multiprecision with gcc-4.7. This indeed works fine with boost::multiprecision::float128:

-----------test.cpp------------
#include <cmath>
#include <boost/multiprecision/float128.hpp>

using namespace std;

typedef boost::multiprecision::float128 real_type_b;
typedef complex<real_type_b> numeric_type_b;


int main()
{

    numeric_type_b a(2,2);
    numeric_type_b r = numeric_type_b(2,2)*a;
    a = sin(r);
    a = exp(r);
    cout << a << endl;

}
-----------test.cpp------------

$ g++-4.7 -std=c++0x test.cpp -lquadmath -o test
$ ./test
(-0.1455,0.989358)

Trying the same thing with boost::multiprecision::mpfr fails for the exp-Function (sin works fine (!))

-----------test.cpp------------
#include <cmath>
#include <boost/multiprecision/mpfr.hpp>

using namespace std;

typedef boost::multiprecision::mpfr_float_500 real_type_b;
typedef complex<real_type_b> numeric_type_b;


int main()
{

    numeric_type_b a(2,2);
    numeric_type_b r = numeric_type_b(2,2)*a;
    a = sin(r);
    a = exp(r);
    cout << a << endl;

}
-----------test.cpp------------

compilation fails:

$ g++-4.7 -std=c++0x test.cpp -lmpfr -o test
In file included from /usr/include/boost/config/no_tr1/complex.hpp:21:0,
                from /usr/include/boost/math/policies/error_handling.hpp:15,
                from /usr/include/boost/multiprecision/detail/default_ops.hpp:9,
                from /usr/include/boost/multiprecision/detail/generic_interconvert.hpp:9,
                from /usr/include/boost/multiprecision/number.hpp:22,
                from /usr/include/boost/multiprecision/mpfr.hpp:9,
                from test.cpp:3:
/usr/include/c++/4.7/complex: In instantiation of ‘std::complex<_Tp> std::__complex_exp(const std::complex<_Tp>&) [with _Tp = boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >]’:
/usr/include/c++/4.7/complex:751:68:   required from ‘std::complex<_Tp> std::exp(const std::complex<_Tp>&) [with _Tp = boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >]’
test.cpp:17:18:   required from here
/usr/include/c++/4.7/complex:736:52: error: no matching function for call to ‘polar(boost::enable_if_c<true, boost::multiprecision::detail::expression<boost::multiprecision::detail::function, boost::multiprecision::detail::exp_funct<boost::multiprecision::backends::mpfr_float_backend<500u> >, boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >, void, void> >::type, boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >)’
/usr/include/c++/4.7/complex:736:52: note: candidate is:
/usr/include/c++/4.7/complex:662:5: note: template<class _Tp> std::complex<_Tp> std::polar(const _Tp&, const _Tp&)
/usr/include/c++/4.7/complex:662:5: note:   template argument deduction/substitution failed:
/usr/include/c++/4.7/complex:736:52: note:   deduced conflicting types for parameter ‘const _Tp’ (‘boost::multiprecision::detail::expression<boost::multiprecision::detail::function, boost::multiprecision::detail::exp_funct<boost::multiprecision::backends::mpfr_float_backend<500u> >, boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >, void, void>’ and ‘boost::multiprecision::number<boost::multiprecision::backends::mpfr_float_backend<500u> >’)

If however, the exp-line is commented out, it works:

$ g++-4.7 -std=c++0x test.cpp -lmpfr -o test
$ ./test
(0,1490.48)

Do i do something wrong, or did i encounter a bug here?

Community
  • 1
  • 1
Sunday
  • 631
  • 1
  • 7
  • 14

1 Answers1

2

Seems like a bug in GNU's library. It triggers when there's _GLIBCXX_USE_C99_COMPLEX here:

#if _GLIBCXX_USE_C99_COMPLEX
  // implementations

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

It looks like it breaks ADL on the exp call (by forwarding with the value of __rep()).

You can easily find out for yourself by hardcoding the exp implementation:

  template<typename T>
    inline std::complex<T>
    my_exp(const std::complex<T>& x)
    { 
        using std::exp; // use ADL
        return std::polar(exp(x.real()), x.imag()); 
    }

This works

#include <cmath>
#include <boost/multiprecision/float128.hpp>
#include <boost/multiprecision/mpfr.hpp>

#if 1
typedef boost::multiprecision::mpfr_float_500 real_type_b;
typedef std::complex<real_type_b> numeric_type_b;
#else
typedef boost::multiprecision::float128 real_type_b;
typedef std::complex<real_type_b> numeric_type_b;
#endif

namespace check
{
  template<typename T>
    inline std::complex<T>
    my_exp(const std::complex<T>& x)
    { 
        using std::exp; // use ADL
        T const& r = exp(x.real());
        return std::polar(r, x.imag()); 
    }
}

#include <iostream>

int main()
{
    numeric_type_b a(2,2);
    numeric_type_b r = numeric_type_b(2,2)*a;
    a = std::sin(r);
    a = check::my_exp(r);
    std::cout << a << std::endl;
}

Works for both types.

Output

(-0.1455,0.989358)
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Thanks for the insight. Maybe this should go to some bugtracker, so that it can be fixed? I think i don't know enough of the details (yet) to do this, but it might be a while before i can come round to dig deeper... – Sunday Feb 27 '14 at 15:33
  • To be honest, i think it's your job to report it. I don't think i know more than you, I just provided you some input. Beyond that, it never was my problem in the first place:) – sehe Feb 27 '14 at 15:39
  • (Clarifying: _People are insecure. Thing is, I'm just as insecure, but I don't have your problem! So, if you want to stand any chance, make sure that a stakeholder follows up. If the stakeholders don't, nobody will_) – sehe Feb 27 '14 at 15:42
  • 1
    http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01377.html (i.e. it will work in gcc-4.10, a bit more than a year to wait). If I hadn't already fixed it, yes, reporting it to gcc's bugzilla would be the right thing to do. – Marc Glisse Mar 04 '14 at 15:34