You make a good point and the decision was by no means cut and dry. However
I made a point of developing some test code using some the newer array data
types and looked at maintaining the array in Haskell and then directly
calling Blas etc. I even had a nice polymorphic matrix class going.
However I found the array interface just a bit too 'clunky' to use a
technical term. The withArray interface is not very appealing. The layers
of lambda notation was giving me a headache.
The idea of separating the imperative code into an imperative language was
appealing to me. Moreover using a stack based architecture for matrix
operations makes the C end of things very easy to implement. The big
bugaboo of memory management issues pretty much disappears, and thinking of
the world state in the IO monad as a stack of matrices has a nice intuitive
appeal for me. It seems to work well so far as I said earlier. I'm not
sure all my issues would have gone away if I had tried to do more of the
matrix op.s in Haskell. It is pretty much a given that I need to interface
to external optimized libraries, that's where the big number crunching is
occuring and those libraries have had teams of Ph.D.s working on them for
years. I want to leverage that. My approach actually minimizes the amount
of marshalling I have to do between C and Haskell. The stack manipulations
are simply scripted in a do clause, with nary an argument being passed.
Has any one created binding for the numarray library ala Python
Numarray? I've heard it's a very good and fast array interface.
Perhaps it would be useful for this sort of task.
Jason
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
