boostgsoc21 / math Goto Github PK
View Code? Open in Web Editor NEWThis project forked from boostorg/math
Boost.org math module
Home Page: http://boost.org/libs/math
License: Boost Software License 1.0
This project forked from boostorg/math
Boost.org math module
Home Page: http://boost.org/libs/math
License: Boost Software License 1.0
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:
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.
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:
std::complex<float>
std::complex<double>
std::complex<long double>
boost::multiprecision::complex128
complex_adaptor<boost::multiprecision::cpp_bin_float_*>
complex_adaptor<boost::multiprecision::cpp_dec_float_*>
boost::multiprecision::mpc_complex*
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?
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 ;
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.