ejmahler
Portability with `nalgebra`
I wonder if every Complex<T> in the implementation could be replaced with ComplexField<RealField = T> or SimdComplexField<SimdRealField = T> trait in nalgebra so that library implementations based on these 2 crates can be more generic and portable. That's a huge change indeed, but I'm still looking forward to the possibility.
BTW, I've seen the issue #85, which seems to be a particular case of above. I don't quite know about nalgebra's SIMD operations and whether its co-op with this crate would slow down much. But I'm interested to how it would work.
I love the idea of making rustfft more interoperable with other crates. This would be a breaking change, so at minimum, we can't do it for another year. After that, I'm torn, because that would be a very, very large commitment.
Something we do in the AVX code to get around the lack of specialization is to have two different numeric traits (one user-facing and one interal), assert that they're the same type with std::any, then just transmute one to the other. Could we take the same approach here, where we expose an API that accepts nalgebra's types, and internally we transmute them to Complex<T> behind the scenes? That would let us put the nalgebra integration in a different crate and avoid such a massive change, while still providing usability improvements to users.
I'll leave this open and think about it.
