Boost logo

Boost :

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:

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                    

Boost list run by bdawes at, gregod at, cpdaniel at, john at