Re: [Boost.GIL] GSoC 2020 - FFT implementation

From: Janek Kozicki (janek.listy.mailowe_at_[hidden])
Date: 2020-02-06 22:48:51

stefan via Boost said:     (by the date of Thu, 6 Feb 2020 17:36:01 -0500)

> On 2020-02-06 5:28 p.m., Janek Kozicki via Boost wrote:
> 
> > I agree that writing FFT which supports all multiprecision types is a
> > tremendous task. But if it's not in GSoC it has a really hard chance
> > of being completed, ever. So maybe the right approach is to split this
> > task into several smaller sub-tasks?
> 
> The point is not that it's a lot of work. It's that the idea to 
> re-implement FFT from scratch inside Boost is foolish, given the 
> availability and quality of existing FFT libraries.

I did not find a library which works with these types:

* boost::multiprecision::mpfr
* boost::multiprecision::cpp_bin_float
* boost::multiprecision::quad_double, in the works:
   https://github.com/boostorg/multiprecision/pull/190
   https://github.com/boostorg/multiprecision/issues/184

hence a generic approach to FFT which works with any multiprecision
type is desirable. Not a single other library can provide that.

Notwithstanding of course the boost implementation could fallback to
existing libraries for types where FFT implementation is available,
for example in libfftw:

* double
* long double
* boost::multiprecision::float128

> That being said, if you think you can come up with a better API
>   (using modern C++), I think there *might* be value in providing
>   (very thin) wrappers around those existing libs. But
>   reimplementing them from scratch, and hope to get to a similar
>   level of quality with a reasonable amount of effort, that's
>   extremely naive.

Not all hope is lost, then ;) Depending on how badly I will need FFT
for quad_double I could consider doing this.

-- 
# Janek Kozicki                              http://janek.kozicki.pl/