I have tried. Using just normal lists, I found it difficult to avoid huge space leaks, but once things are working, the end result is easy to reason about. I'm considering giving it another try using Stream Processors or some form of Arrows instead of lists. I think this strategy might allow me to do several transformations of the same input list in pseudo-parallel, which would allow the GC to collect old data as soon as its not needed by the computation that decides when to buy and sell. The Stream Processor library I was looking at uses Continuation Passing Style, which I don't know too much about, and I'm not sure Arrows will work out. Generalizing the problem, how does one express: "given multiple transformations of an infinite numeric list, perform some IO at the first instance some predicate is met"? I feel that Arrows might somehow trivially allow me to compute on huge lists without leaking, but don't understand them well enough to apply them. If one could write an arrow that applies the transformations to the input list in parallel, then I'd think you could solve the above example something like this: (f &&& g) >>> dropWhile (\(x,y) -> x > 0 && y > 0) >>> performSomeIO Maybe <+> is the arrow operator I'm looking for, not &&&, but to be honest, the documentation for Arrows blows my mind. I think a few examples would go a long way. Thanks, Greg On 7/6/06, Joel Reymont wrote:

Is anyone using Haskell for heavy numerical computations? Could you share your experience?

My app will be mostly about running computations over huge amounts of stock data (time series) so I'm thinking I might be better of with OCaml.

Thanks, Joel

-- http://wagerlabs.com/

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

Joel Reymont wrote:

Is anyone using Haskell for heavy numerical computations? Could you share your experience?

My app will be mostly about running computations over huge amounts of stock data (time series) so I'm thinking I might be better of with OCaml.

If you are really serious about numerical throughput, you probably should be looking at vector instructions, CPU cache sizes, and parallelising your algorithms, not choosing between high-level languages. Hopefully it's enough to do that sort of thing for a few important primitives, and then you can write the rest of the program in whatever langauge you like. * MonetDB It sounds like MonetDB might be related to your problem. This database is designed for ad-hoc analytical queries which touch most of the rows (but hopefully only a few of the columns) of a database. The design of the system has a lot of interesting analysis about the performance characteristics of modern hardware. Publications: http://monetdb.cwi.nl/Research/Articles/index.html The first sections of the Boncz thesis provide an overview which will hopefully tell you rather this stuff applies at all. The only paper with "X100" in the title is an overview of what's been happening more lately. * Optimizing Combinator Libraries If you are trying to build a nice and efficient library in Haskell over a few fast primitives, the ByteString library could be a good example. In particular, the use of rewrite rules for loop fusion might help in your case as well. If you are trying to build a combinator library in Haskell over a few efficient primitives, you might like the use of rewrite rules in Data.ByteString to implement some kinds of loop fusion. http://www.cse.unsw.edu.au/~dons/fps.html I liked the slides Perhaps idea from this paper could help if you are doing more complicated things: Dynamic Optimization for Functional Reactive Programming using Generalized Algebraic Data Types http://www.cs.nott.ac.uk/~nhn/Publications/icfp2005.pdf Brandon

Alberto Ruiz has developed a linear algebra library which could be seen as an alternative to Matlab/Octave, using the GSL, ATLAS, LAPACK, etc. IIRC. http://dis.um.es/~alberto/GSLHaskell/ I've optimized it in some places, and added an interface which guarantees operand conformability through the type system at compile time. http://ofb.net/~frederik/stla/ It is almost twice as fast as Octave on an example program, and probably comparable to Matlab. However, it is currently very difficult to debug some of the type errors which are emitted by GHC when using it, and there are some outstanding heap-related bugs. Also, we don't have as wide a variety of built-in functions as Matlab and Octave do. Frederik On Thu, Jul 06, 2006 at 11:03:11PM +0100, Joel Reymont wrote:

Is anyone using Haskell for heavy numerical computations? Could you share your experience?

My app will be mostly about running computations over huge amounts of stock data (time series) so I'm thinking I might be better of with OCaml.

Thanks, Joel

-- http://ofb.net/~frederik/