FFTs

[pfeatherstone]

At the moment dlib::fft() computes a full FFT across all dimensions. So it's actually closer to numpy.fft.fftn() with all axes set.
I have a use case where i need to compute the FFT of a dlib::matrix on only one dimension. Both the KISS and MKL backends can do this so it's just a matter of adding some API functions.

I propose we add dlib::fftn(), dlib::rfftn() and their inverses, allowing you to set the axes along which to do the FFT. Then you can just set one axis and voila job done.

[pfeatherstone]

Alternatively, we kind of do what pytorch did, and add a dlib::fft namespace and put all new API functions in there. Make dlib::fft::fft() a 1-dimensional FFT, and mirror all the numpy/torch naming conventions. That might be nice.

[davisking]

You don't want to use colm() or similar and just run the current code on each column?

[pfeatherstone]

Yeah I guess i could do that for now. That would possibly incur a copy. In general having an API that mirrors numpy and torch would be great. Those FFT APIs are now pretty much a standard.
I'm not sure about MKL, but KISSFFT actually accepts stride arguments so even if you were slicing in a way that elements weren't consecutive, you still wouldn't get a copy when computing the FFT. That's great when FFTs are in the hot path

[davisking]

Oh right, I forgot that the overload for a generic matrix_exp does a copy right now. Yeah, that would be non-ideal.