type deduction fails for std::complex return types for qagX integration methods

[ajackura]

Greetings,

I was testing out some of the integration routines for functions of complex type and real argument. The qagX_integrate algorithms fail to type deduce because the error handling functions cannot distinguish argument type return type. The same is true in the squad_integrate, however the fix there is simple, since one can take std::isinf(iv.fx[i]) || std::isnan(iv.fx[i]) to
std::isinf(std::abs(iv.fx[i])) || std::isnan(std::abs(iv.fx[i])) in all occurrences of the inf/nan test since the standard seems to only accept floating point types. The fixes for the qagX routines are a bit more involved I believe, unless I am missing something.

Cheers, Andrew

[emsr]

Greetings, Andrew,

Thanks for checking this out. I might have had slightly illegal overloads of std::isnan etc. for complex but your solution, or maybe std::isinf(std::real(iv.fx[i])) || std::isinf(std::imag(iv.fx[i])) since those work for reals might be nicer.
I'll work on this tonight.

Cheers, Ed

[ajackura]

Thank you for looking into this Ed,

For your info, I ripped your functions from the __gnu_cxx namespace (as I had trouble compiling out-of-the-box) and placed them in my own namespace to test, and am using g++11 with c++20 standard. My test with double did work as expected.

Cheers,
Andrew

[emsr]

I'm thinking I need a namespace of my own. I thought these were going into the libstdc++ gnu library but that's probably just not realistic.

[ajackura]

I think it could be useful for the community, a new flexible numerical tools library with straightforward api. You have a lot of nice functionalities in the various libraries. Unfortunately you may be right, it may take time (too long) to be part of the standard. Have you thought much about branching these off to their own thing?

[emsr]

I have thought of that: 1. break things up (at least the directory structure suggests this), 2. Use a new namespace so I'm not in std (except for what is really in there) and __gnu_cxx; 3. maybe MIT license things that are not in official libstdc++.

Do you have any short test-cases/reproducers that you could post? I could figure them out but if you have them on hand it would help.

[emsr]

4. Stop uglifying names with __x and _X like a system library must do.
   These are in no particular order.

[ajackura]

Here is a repo of my rip. I have a function test_integrate.cpp where I use a simple test case, as well as some of my compile logs. the routines are in a namespace 'math'. (note I also did remove the leading underscores on variables/functions because I was trying to understand what you coded). I could very well be not using the library correctly, but this did work for double type.

https://github.com/ajackura/math_quadrature

compiled the test simply with
g++ -std=c++20 test_integrate.cpp o test_integrate -I./include/ 2> compile.log

[ajackura]

note also very slightly reorganized since I was playing with this, so I could have broken something inadvertently

[emsr]

#include "include/ext/integration.h"

#include

std::complex<double>
fun(double x)
{
  using namespace std::complex_literals;
  return 1.0 / (x*x - 1.0i * x);
}

int
main()
{
  const auto I = __gnu_cxx::integrate_clenshaw_curtis(fun, 1.0, 4.0, 0.000001, 0.0000111, 12);
}

[ajackura]

So, this test works for me, the integrate_clenshaw_curtis does not seem to have a problem with complex types. If I change integrate_singular (to use qags), then I get the following errors

compile.log

[emsr]

Ugh. I think the workspace type in the caller is right <double, complex>. I don't know why the integration routine expects <double, double>.

I'll figure it out.
I might have to make a reduced thing that gives the template error.

[emsr]

Ok, try it now.
I just got complex type deduction working for all integrals.
I get the same test results as before.
I need to add complex integration tests. Maybe I'll try a function returning a 3-vector or something.

I did not do the other code reorgs yet, I wanted to fix the bug first.

[ajackura]

My first test with the qags method worked for double and complex type. I will keep testing this out as I play with it. I am doing some test on the use of these routines in my integral equations code for complex and real types, so there will be plenty of test to come.

Thanks a lot Ed, I'll be examining more of this library and let you know if I come across anything.

[emsr]

Ok, So I'm closing this one out.
Thank you for testing this!