Abstract over sample type

[awelkie]

The FFT functions should be generic over the sample type

[itdaniher]

I've actually struggled with this issue myself - a pure Rust FFT impl will likely make it easier for compile-time number widths than trying to trigger a recompilation of kissfft. :)

Aside from a call to f32::consts::PI and some explicit casts, the implementation you adopted from kissfft looks pretty type-generic. Have you spent any time trying to refactor RustFFT such that process looks like

process<T: std::num::Float>(&mut self, signal: &[Complex<T>], spectrum: &mut [Complex<T>])

or equiv?

[awelkie]

I tried making it generic a while ago, and I think I got hung up on the casts of f32::consts::PI to the generic type. But other than that, T should just need to be Float, I think. But it looks like std::num::Float is deprecated. Does that mean we're supposed to use the Float trait from the num crate?

And yeah, having generics is probably the only actual improvement over a C implementation of the FFT. That, and maybe a slightly easier build process for Rust projects.

[itdaniher]

use core::num::Float;

....I think....

[itdaniher]

Worked at https://github.com/ade-ma/LibRedio/blob/9a81b079475c78f3156e3f84dad0447d46908ea8/src/kpn/src/kpn.rs#L13, at least.

[awelkie]

I just merged in generics. I decided to use Signed + FromPrimitive + Copy' which should more easily allow fixed point numbers than using theFloat` trait.

[itdaniher]

Awesome!