Don't require process_outofplace_with_scratch input to be mutable

[michaelciraci]

Right now, the Fft options are:

fn process(&self, buffer: &mut [Complex<T>]);
fn process_with_scratch(&self,
        buffer: &mut [Complex<T>],
        scratch: &mut [Complex<T>],
    );
fn process_outofplace_with_scratch(
        &self,
        input: &mut [Complex<T>],
        output: &mut [Complex<T>],
        scratch: &mut [Complex<T>],
    );

Can you provide an API where the input does not need to be mutable? Right now, if I have a non-mutable slice I need to clone the slice before I can take the FFT.

[HEnquist]

ThIs would be quite convenient. Many of the algorithms (most of them IIRC) modify the input while performing the transform. So this new method would need to copy the input to a scratch buffer as the first step. It could be implemented quite easily as a provided method on the Fft trait.

[michaelciraci]

Do you think the past path to implement this would be to add a new function to the Fft trait? Maybe something like this:

fn process_outofplace_with_scratch_immut(
        &self,
        input: &[Complex<T>],
        output: &mut [Complex<T>],
        scratch1: &mut [Complex<T>],
        scratch2: &mut [Complex<T>],
    );

[HEnquist]

Yes, but I would use a single scratch buffer and split it with split_at_mut(): https://doc.rust-lang.org/std/primitive.slice.html#method.split_at_mut

[michaelciraci]

Thanks for the info.

And it looks like there are several instances where perform_fft_out_of_place calls process_with_scratch (for example: https://github.com/ejmahler/RustFFT/blob/master/src/algorithm/good_thomas_algorithm.rs#L411). Any reason why this isn't self.height_size_fft.perform_fft_out_of_place?

[michaelciraci]

I didn't implement sse/neon/wasm yet, but I wanted to get your feedback first: #157

[ejmahler]

Closed by #157