search

ian-ross / arb-fft

Pure Haskell arbitrary length FFT library
https://www.skybluetrades.net/haskell-fft-index.html
BSD 3-Clause "New" or "Revised" License
11 stars 1 forks source link

Use unboxed vectors #2

Closed Daniel-Diaz closed 10 years ago

Daniel-Diaz commented 10 years ago

I still don't know how things are working internally but, did you consider using unboxed vectors? They are usually more efficient. Any pros or cons?

ian-ross commented 10 years ago

Things should mostly be unboxed internally. I'll check over the APIs properly. I sometimes get confused with multiple kinds of Vector floating around.

ian-ross commented 10 years ago

I've checked, and everything is unboxed internally. However, the APIs do only deal with boxed vectors. What about a generic interface like this:

import Data.Vector.Generic
import Data.Complex

fft :: Vector v (Complex Double) =>
       v (Complex Double) -> IO (v (Complex Double))

ifft :: Vector v (Complex Double) =>
        v (Complex Double) -> IO (v (Complex Double))

fftWith :: Vector v (Complex Double) =>
           Plan -> v (Complex Double) -> v (Complex Double)

ifftWith :: Vector v (Complex Double) =>
            Plan -> v (Complex Double) -> v (Complex Double)

That way, you can call with boxed or unboxed vectors, and I use vector's convert function to convert things to unboxed for internal use and back again when done (so if you call fft with an unboxed vector, the conversions collapse to no-ops).

Does that make sense?

Daniel-Diaz commented 10 years ago

I think it is the ideal solution. Thank you for looking at this!

ian-ross commented 10 years ago

OK, fixed in HEAD. I have another couple of things to look at before I upload a new version to Hackage.