boostgsoc21 / math Goto Github PK

The offending line is here

    transform_api< std::complex<double>,     3,boost::math::fft::fftw_dft >();

I would like to be adding builds for MSVC and GCC on MinGW x86_64 host to our CI as we progress and stride forward.

The interface, as it evolves, is expected to utilize a potentially custom allocator when the caller wishes to provide one other than the default.

It would be nice to make some tests with a project-local toy allocator toi ensure that this works propoerly.

Provide such a toy allocator.

Our BSL interface, GSL backend and FFTW backend for float, double and long double do not depend on GMP nor MPFR libraries. Nevertheless, the examples cannot be compiled without linking to those libraries. Can we make these dependencies disappear for the cases when they are not needed?

We could improve the speed execution of the complex and real transforms by pre-computing a sin/cos table when a plan is created.

You probably know that real to complex is very often used in applications of Fourier Methods. This particular use case allows for an optimization in computation and memory of a factor of 2. To exploit the complex conjugate symmetry here, the output is usually an array of floor(N/2)+1 complex numbers when the input consists of N real numbers (see for instance numpy).

The Real-to-Complex transform (and its inverse Complex-to-Real) require for an API that breaks our current design because of the following:

1. this use case applies exclusively to the realm of complex numbers, and not our generalized abstract DFT.
2. input and output have different types, one is Real and the other is Complex.

The first point above makes me think that at this point we should have separate classes to handle two types of transform philosophy: complex dft and ring dft. Moving forward with this proposal will break the nice symmetry that we previously have where ring transforms were handle as if they were complex, with the underlying static type selection making all the work to select the appropriate algorithms. On the bright side having these two api's will give the user more control of what is being done and we no longer need is_complex to select appropriate algorithms. Notice that ring transforms can also apply to complex numbers, with the appropriate selection of the root of unity, this is why I thought they might be unified at first.

If we introduce real-to-complex into the game, we could either expand the complex dft class to accommodate this case or we could introduce a third class specific to it. In any case I think we are likely bound to have template parameters specifying the Real and the Complex types, maybe having by default the following rule Real = Complex::value_type.

I am quite convinced that we should go for the 3 classes solution: ring, complex and real-to-complex dfts.
@cosurgi @ckormanyos what do you think?

Deactivate the normal Math CI in this fork and set up a simple project specific CI for FFT only.

@ckormanyos mentioned that math does not depend on multiprecision. So we cannot simply #include <boost/multiprecision/complex_adaptor.hpp> and go ahead. Also there is a multitude of real types available within Boost. See for example this short program:

#include <boost/config.hpp>
#include <boost/cstdfloat.hpp>
#include <boost/multiprecision/float128.hpp>
#include <boost/multiprecision/cpp_bin_float.hpp>
#include <boost/multiprecision/cpp_dec_float.hpp>
#include <boost/multiprecision/mpfr.hpp>
#include <boost/multiprecision/mpfi.hpp>
#include <boost/core/demangle.hpp>

template<typename T>
void print_sin_1() {
	using std::sin;
	std::cout << sin(T(1)) << " type: " << boost::core::demangle(typeid(T).name()) << std::endl;
}

template <typename... T>
constexpr inline auto for_each = [](auto&& f) {
    (f.template operator()<T>(), ...);
};

int main() {
	auto for_each_test_type = for_each<
			  float
			, double
			, long double
			, boost::multiprecision::float128
			, boost::multiprecision::cpp_bin_float_50
			, boost::multiprecision::cpp_bin_float_quad
			, boost::multiprecision::cpp_dec_float_100
			, boost::multiprecision::number<boost::multiprecision::cpp_bin_float<200> >
			, boost::multiprecision::mpfr_float_100
			, boost::multiprecision::number<boost::multiprecision::mpfr_float_backend<200> >
			, boost::multiprecision::mpfi_float_100
			, boost::multiprecision::number<boost::multiprecision::mpfi_float_backend<200> >
		>;

	for_each_test_type([]<typename T>() {
		print_sin_1<T>();
	});
}

Also this code snippet should be nice to test the solution to the problem which we seek here.

Not mentioning the types in the works such as double_float and quad_float (I believe complex_adaptor is for them).

Now we need something which, in a universal way, constructs a Complex type for each of them. We have a hackish tool for that here already used in the code in several places.

@Lagrang3 already noted in the comments that it is needed.

Following this comment I'd like to open an issue to track this problem. Basically it comes from the fact that boost::is_complex does not recognize Boost complex 128, MPFR, MPFI, cpp_bin/dec_float family of types, but only the standard std::complex.

While the target is to recognize at least these types:

1. std::complex<float>
2. std::complex<double>
3. std::complex<long double>
4. boost::multiprecision::complex128
5. complex_adaptor<boost::multiprecision::cpp_bin_float_*>
6. complex_adaptor<boost::multiprecision::cpp_dec_float_*>
7. boost::multiprecision::mpc_complex*
8. complex_adaptor<boost::multiprecision::mpfi_float_*>

it seems apparently that the problem lies on the side of Boost.Multiprecision, not on the side of Boost.Math. Because it's the job of Boost.Multiprecision to make sure that the complex type, provided by Boost.Multiprecision is recognized.

So I guess we will need to open a PR to Boost.Multiprecision, by either changing is_complex (I suppose that is undesirable for backward compatibility reasons) or by supplementing a new recognizer of complex type somewhere in the namespace of complex_adaptor. Maybe call it is_boost_complex or something like that. And then provide a specialization for this recognizer under declaration of every complex type or maybe every type which can be complexified, like I did here.

When working on #17 I encountered a problem that boost::multiprecision::complex128 isn't working in fft_ex_06.cpp.

Before changes in #17 it was using std::complex<boost::multiprecision::float128> and worked.

Let's us track here progress with this problem.

@Lagrang3 @ckormanyos , any ideas?

The file chebyshev_transform.hpp uses FFT. We should know how to deal with this.

Issue #18 is dealing only with boost::multiprecision::complex128 but we need to test the real to complex transforms also for types mpfr and cpp_bin_float.

The complex to complex transforms are tested in fft_ex05.cpp. Actually maybe this file should land in the test directory?

CC @Lagrang3 @ckormanyos

Clang with gnu++2a is failing after we added allocators. I will try to find a simple failing case to pinpoint the problem.

Originally posted by @Lagrang3 in #9 (comment)

So far I am unable to reproduce the compile error locally.

My user config file

$ cat ~/user-config.jam 
using clang : : clang++-11 : <cxxflags>-std=gnu++2a ;
using gcc : : g++ : <cxxflags>-std=gnu++2a ;