Re: Functional DSP
Philip Wadler wrote: > By the way, FFTW although written in C, was generated by a functional > program written in Caml. You can find more details on the web page I asked the authors (Steven Johnson and Matteo Frigo from MIT) a few months ago why they chose Objective Caml over SML, Haskell, and Scheme. The answer was bascially because they knew it already and it ran well on one of their older laptops. I think what it more interesting is that fact that the code uses explicit recursion (as oppose to "traditional" loop based algorithms) and all of the codelets/butterflys are executed via byte code. On top of that, it managed to beat most other FFT packages available today. --Matt Donadio ([EMAIL PROTECTED])
Re: Functional DSP
On Sat, 24 Oct 1998, Philip Wadler wrote: > I was planning to try similar things you have mentioned > on your page, such as interfacing to "the fastest FFT in > the West" (FFTW) via GreenCard, ... > > By the way, FFTW although written in C, was generated by a functional > program written in Caml. You can find more details on the web page > > Functional Programming in the Real World > http://www.cs.bell-labs.com/~wadler/realword/ > Yes, I know it, but thank you for pointing it out. It is amazing to see how useful caml/ocaml is in development of other goodies, such as Pict, Joint Calculus, Ensemble, etc. I think that they did a good job with interfacing it to C in a variety of ways: toplevel, bytecode, native code, embedded bytecode, etc.; and that's probably one of the answers why it is so popular - at least among researchers. Jan > -- P >
Re: Functional DSP
I was planning to try similar things you have mentioned on your page, such as interfacing to "the fastest FFT in the West" (FFTW) via GreenCard, ... By the way, FFTW although written in C, was generated by a functional program written in Caml. You can find more details on the web page Functional Programming in the Real World http://www.cs.bell-labs.com/~wadler/realword/ -- P
Re: Functional DSP
On Thu, 22 Oct 1998, Matthew Donadio wrote: > With the recent talk about scientific computing in Haskell, I decided to > start converting my DSP and digital comm. libraries to Haskell (I was > also home sick the other day and had some free time). I have created a > rather Spartan web page about the venture: > > http://users.snip.net/~donadio/mpd-hs-dsp.html > > There are a few GPL'ed literate Haskell modules there. I have done > preliminary testing with Hugs 1.4, but there may still some remaining > bugs. Way to go, Matthew. We need more of this sort of work published to demonstrate that Haskell is not only about itself.:-) I hope others would follow suit and show some of their reaches kept hidden in their coffers. It is only by exchanging ideas and by trial and error that a resonably usable and consistent library of DSP could be built. I was planning to try similar things you have mentioned on your page, such as interfacing to "the fastest FFT in the West" (FFTW) via GreenCard, and it pleases me to know that you have decided to give Haskell a second chance as well. (I am referring here to one of your previous posts.) By the way, are you aware of Cilk - a multithreading parallel programming model based on Ansi C (from the same group that invented FFTW)? I think that this, or other multithreading approaches, should be seriously considered when attempting to interface Haskell to C. Think about data presentation running in a separate thread. After all the amount of input or output data tend to be quite large in this sort of applications. You might find it useful to see my page http://www.numeric-quest.com/lang/nq_proxy.html about using LinuxThreads with thread-unsafe library, EZWGL. Jan
Functional DSP
With the recent talk about scientific computing in Haskell, I decided to start converting my DSP and digital comm. libraries to Haskell (I was also home sick the other day and had some free time). I have created a rather Spartan web page about the venture: http://users.snip.net/~donadio/mpd-hs-dsp.html There are a few GPL'ed literate Haskell modules there. I have done preliminary testing with Hugs 1.4, but there may still some remaining bugs. This is only a spare time effort right now, so updates may be slow, but I will chug away at it. Enjoy. -- Matt Donadio ([EMAIL PROTECTED]) | 43 Leopard Rd, Suite 102 Sr. Software Engineer | Paoli, PA 19301-1552 Image & Signal Processing, Inc. | Phone: +1 610 407 4391 http://www.isptechinc.com | FAX: +1 610 407 4405
