On Nov 4, 11:46 pm, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > > Long answer: SISAL is an example of a functional parallel language > > Ah, right, there was SISAL... unfortunately long forgotten.
I saw a retrospective presentation on it at SIAM PP this spring by one of the Livermore folks who promoted it. Pretty neat! > > One could express solving linear systems (which is what I presume you > > mean by "matrix inversion," unless you really want the entries of the > > inverse) in a purely functional way using a language like SISAL with a > > compiler that optimizes away temporaries, and the resulting > > Could one? That was actually the core of my question. Of course HPC > applications would require smart compilers that, but first of all > there must be a purely functional algorithm that can be transformed > automatically into an efficient one. Do you know any references to > such algorithms in linear algebra? There's probably a big difference between "in theory" and "in practice" in this case ;-) SISAL didn't have multidimensional arrays so I doubt very much that it could have optimized away the creation of matrix temporaries. The usual trick to make things look functional is to index vector variables with the current iteration, so that you aren't overwriting anything. Then if the compiler can prove that there are no read-after- write conflicts, it can collapse the vector variables into one vector and replace copies with destructive writes. I haven't seen a purely functional formulation of LU factorization but it could be done without too much trouble. Of course there's no reason to go through that effort because people spend so much time optimizing LU and its constituent components that you would be better off reusing their work. > Of course, HPC applications dealing with large data sets would always > want algorithms that modify matrices in place instead of allocating > more memory. I don't expect a purely OO HPC world any time soon. But > it would still be interesting to know how many of the traditional CPU- > hungry algorithms already have known efficient functional equivalents. To me the more interesting and rewarding task is to figure out how to splice existing HPC libraries into a functional framework, without losing the ability to reason functionally about the components. > Me too. HPC is only one aspect of my work. And I think languages like > Clojure can be useful for generating specialized HPC code as well, > just like FFTW uses Caml code for generating C routines. Definitely! We've got at least one fellow here who uses Common Lisp to generate stencil codes. He's been thinking about switching to Clojure ever since he and I worked on a thorny Lisp problem together ;-) mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
