On 12 Mar 2008, ndmitchell@gmail.com wrote:
I'm looking for interesting project to work on during Google Summer of Code. So I found [1]"A data parallel physics engine" ticket and got excited about it. I'd like to know interested mentors and community opinion about the complexity of such project.
I don't think there are a great deal of Haskell users who _really_ need a physics engine right now. However, there seem to be a massive number who are working with matrices. I am informed that a lot of physics is just matrix stuff underneath (but don't know anything myself).
Perhaps a nice direction to take this project would be to build an NDP matrix library first, then use that library to build a physics engine on top of it. A physics engine would certainly be very cool, and a parallel matrix library would certainly be very much in demand.
Indeed, a matrix library would be really nice. Before getting serious about this, please take a very close look at how PETSc (http://www-unix.mcs.anl.gov/petsc/) handles matrices. The abstraction is very important because most large matrices of interest are sparse or have some symmetry that makes them asymptotically cheaper to apply (like with an FFT, FMM, or tensor product). It would be a shame to put a lot of work into something and have it miss the very important point that a matrix is nothing more than a linear transformation between finite dimensional spaces. Certain algorithms may need a particular representation, but many don't (a Krylov iteration just needs to apply the matrix to a vector; the preconditioner usually needs more, but may not use the same matrix). At the more mundane level, there is frequently an order of magnitude performance difference between different sparse matrix formats, but which one wins is problem specific. Jed