Thanks for all the replies, It sounds like there is enough interest and even some potential collaborators out there. I have created a few data structures to represent sparse vectors and matrices. The vector was a simple binary tree and the matrix a quad tree. As I suspected a standard IntMap was around 3X as fast as my binary tree, so I have switched to the IntMap for now. I was hoping to hold on to my quad tree for the matrix rep. because I like the elegance of the recursive algorithms like Strassen’s for multiplication. In the end it will most likely be best to have a few different matrix representations anyway. For instance, I know that compressed row form is most efficient for certain algorithms. I have a Gauss iterative solver working currently and am thinking of moving on to a parallel Conjugate gradient or direct solver using LU decomposition. I’m no expert in Haskell or numeric methods but I do my best. I’ll clean up what I have and open up the project on Github or Bitbucket. Any other thoughts or ideas are welcome. I’m currently using the Matrix Market files for testing. It would be nice to benchmark this against an industry standard solver in C or Fortran, without having to do a lot of work to set it up. Does anyone know of an easy way to do this? I’m just trying to get results to compare in orders of magnitude for now. It would be motivating to see these comparisons. -- View this message in context: http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix-li... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Hi Mark To continue with library I just wrote a quick recursive matrix multiplication. Since you mentioned about Strassen's algorithm so I went to wikipedia ( http://en.wikipedia.org/wiki/Strassen_algorithm ) and wrote the recursive algorithm using 4 multiplication but it's not very hard to modify this to Strassen's algorithm. You can see code ( https://github.com/mukeshtiwari/Puzzles/blob/master/recursivematrixmultiplic...). It's just quick code and it has lot of chance for improvement like using Data Parallel Haskell ) , some parallelism using Simon's monad-par library or distributed parallelism using Cloud Haskell and sparse matrix representation consideration. Mukesh Tiwari On Sat, Dec 1, 2012 at 3:28 AM, Mark Flamer wrote:

Thanks for all the replies, It sounds like there is enough interest and even some potential collaborators out there. I have created a few data structures to represent sparse vectors and matrices. The vector was a simple binary tree and the matrix a quad tree. As I suspected a standard IntMap was around 3X as fast as my binary tree, so I have switched to the IntMap for now. I was hoping to hold on to my quad tree for the matrix rep. because I like the elegance of the recursive algorithms like Strassen’s for multiplication. In the end it will most likely be best to have a few different matrix representations anyway. For instance, I know that compressed row form is most efficient for certain algorithms. I have a Gauss iterative solver working currently and am thinking of moving on to a parallel Conjugate gradient or direct solver using LU decomposition. I’m no expert in Haskell or numeric methods but I do my best. I’ll clean up what I have and open up the project on Github or Bitbucket. Any other thoughts or ideas are welcome. I’m currently using the Matrix Market files for testing. It would be nice to benchmark this against an industry standard solver in C or Fortran, without having to do a lot of work to set it up. Does anyone know of an easy way to do this? I’m just trying to get results to compare in orders of magnitude for now. It would be motivating to see these comparisons.

-- View this message in context: http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix-li... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Sun, Dec 2, 2012 at 10:52 AM, wren ng thornton wrote:

...

My goal for all this is in setting up the type system, not performance. I figure there are other folks who know and care a lot more about the numerical tricks of giving the actual implementations.

You've got my support -- old-school optimizations, numerical, compiler, or otherwise, are deadly boring. Death to them, I say! If we don't explore uncharted waters, who will? -- Kim-Ee On Sun, Dec 2, 2012 at 10:52 AM, wren ng thornton wrote:

On 11/30/12 4:58 PM, Mark Flamer wrote:

...

Thanks for all the replies, It sounds like there is enough interest and even some potential collaborators out there. I have created a few data structures to represent sparse vectors and matrices. The vector was a simple binary tree and the matrix a quad tree. As I suspected a standard IntMap was around 3X as fast as my binary tree, so I have switched to the IntMap for now. I was hoping to hold on to my quad tree for the matrix rep. because I like the elegance of the recursive algorithms like Strassen’s for multiplication. In the end it will most likely be best to have a few different matrix representations anyway. For instance, I know that compressed row form is most efficient for certain algorithms. I have a Gauss iterative solver working currently and am thinking of moving on to a parallel Conjugate gradient or direct solver using LU decomposition. I’m no expert in Haskell or numeric methods but I do my best.

I've also been working haphazardly on some similar stuff lately. However, my focus is rather different[1] so I'm afeared not much code sharing could happen at the moment. While I'm certainly no expert on numerical methods, I seem to have acquired some experience in that domain so I may be able to lend a hand from time to time.

[1] In particular my goal has been to revive some old ideas about making linear algebra well-typed. The vast majority (if not all) of extant linear algebra systems are poorly typed and will do stupid things to "resolve" type errors (e.g., automatically padding, truncating, and reshaping things). Because of the use case I have in mind, this project also involves setting up a proper numerical type-class hierarchy (i.e., one which expresses semirings and other things ignored by the numerical hierarchies out there today). My goal for all this is in setting up the type system, not performance. I figure there are other folks who know and care a lot more about the numerical tricks of giving the actual implementations.

-- Live well, ~wren

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks to all for the feedback. As I investigate the structures for organizing a library of sparse matrix representations a bit more and look into the repa 3 library, I cant help but wonder if these spare matrix types could just be additional instances of Source and Target in repa. Does anyone know of any reason why this would be a bad idea? I see that the lib was designed to be extended with new matrix representations. Just a thought. -- View this message in context: http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix-li... Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Woops, forgot I switched to darcs after some time. The latest version can be found here: http://www.funfem.org/browser/Numeric/Funfem/Algebra Adrien On Sunday 02 December 2012 00:00:32 Adrien Haxaire wrote:

Hello,

I started a FEM library, funfem [1], but I stopped it for the moment; Haskell is my hobby and I work on FEM all day long, I prefer to focus on orthogonal problems for home projects. It is a very naive implementation. Far from a version 0.0.1 too, i.e. unusable at the moment.

I did not test the performance as it was not my main goal, so the following may not be completely relevant to your purpose.

I define a type Tensor [2], which is a sparse matrix based on Data.Map. Not sure how efficient it is, I chose to start simple. The resulting conjugate gradient [3] is very clear.

Please let us know how it goes, it's good to see more traction towards Haskell from our field, and I'll be glad to use your library !

Best regards, Adrien

[1] http://www.funfem.org

[2] https://github.com/adrienhaxaire/funfem/blob/master/Numeric/Funfem/Algebra/T ensor.hs

[3] https://github.com/adrienhaxaire/funfem/blob/master/Numeric/Funfem/Algebra/S olver/CG.hs On Thursday 29 November 2012 14:03:04 Mark Flamer wrote:

...

I am looking to continue to learn Haskell while working on something that might eventually be useful to others and get posted on Hackage. I have written quite a bit of Haskell code now, some useful and a lot just throw away for learning. In the past others have expressed interest in having a native Haskell sparse matrix and linear algebra library available(not just bindings to a C lib). This in combination with FEM is one of my interests. So my questions, is anyone currently working on a project like this? Does it seem like a good project/addition to the community? I'm also interested if anyone has any other project idea's, maybe even to collaborate on. Thanks

-- View this message in context: http://haskell.1045720.n5.nabble.com/Is-anyone-working-on-a-sparse-matrix- l ibrary-in-Haskell-tp5721452.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Adrien Haxaire www.adrienhaxaire.org | @adrienhaxaire