Re: [Haskell-cafe] Strings in Haskell
I wonder if that's another reason OCaml is used in a(t least one)
hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder? Was
it the state of affairs then that OCaml was more efficient (? --
WAGuess), and would they prefer Haskell now? I'm trying to make sense
out of OCaml objects out of that already infamously annoying
"Practical OCaml" book, and class object <blah>... doesn't look like
much, not to say that "class object" sounds about as bad as most
English in that book. (Written by an English major... What a decline
in US education! :) I come from ML background, so Haskell laziness
and OCaml objects are all new to me. But my Haskell book, Haskell
School of Expression, is so much better written, that I'm reading it
much faster.
I'm CC'ing Yaron as his e-mail comes up in my Gmail context adwords on
the word "Haskell." :) I'm interested in financial data mining and
market modeling -- are there any good application of FP there, say in
Lisp?
Cheers,
Alexy
P.S. Somebody with an old-fashioned mail client please feel free to
change the subject to "Financial Engineering with FP," gmail seems to
etch its subjects in stone. :)
On 1/23/07, Martin Jambon
On Mon, 22 Jan 2007, Alexy Khrabrov wrote:
Greetings -- I'm looking at several FP languages for data mining, and was annoyed to learn that Erlang represents each character as 8 BYTES in a string which is just a list of characters. Now I'm reading a Haskell book which states the same. Is there a more efficient Haskell string-handling method? Which functional language is the most suitable for text processing?
In OCaml, strings are compact sequences of bytes. And you can pass them as-is to C functions:
http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/e109df224ff0150b30203...
Martin
-- Martin Jambon http://martin.jambon.free.fr
Alexy, This is a subject near and dear to my heart and I also dabble in Lisp and Erlang. Google for "Composing Financial Contracts", you will surely like the paper. This is the paper that got me started with Haskell. I'm sure you could do financial data mining in either Lisp, Haskell or OCaml. I think what matters most is being able to "compose" and specify what you want to do as opposed to how. You could compose your contracts in Lisp but it would not be as elegant as in Haskell. You would need to deal with layers and layers of macros, wrapping your head around the prefix notation and having to add laziness to prevent your data structure from always being evaluated. Lastly, you would want to apply different methods to your engineered contracts, e.g. to price them or print them as documents. There's no pattern matching in Lisp or guards for that matter. This means that you would need to resort to lots of imperative code and case statements that check the type of the data structure passed in to special-process it. Yes, you could add pattern matching to Lisp but it's not natural or that elegant. Yes, you could accomplish the same goal with CLOS, i.e. objects and methods. You could do the same in C++, Python or many other languages. Haskell is uniquely suitable for financial engineering. The boon of Haskell is being able to build a lazy data structure in memory to describe your financial contract, then use pattern matching and guards to deconstruct this data structure and slice it and dice it as you see fit, without having to evaluate it fully and running out of memory in doing so. The boon Haskell is being able to do this cleanly, elegantly and succinctly, without the need for extra helping layers of code. The bane of Haskell is not being able to predict the performance in doing the above. This may not be the reason why Yaron chose to use OCaml at Jane St a few years ago but this is certainly the reason why anyone would hesitate to use Haskell for the same purpose now. Haskell performance optimization is still black art and a few bits of magic. Joel -- http://wagerlabs.com/
Alexy Khabrov wrote:
I wonder if that's another reason OCaml is used in a(t least one) hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder? Was it the state of affairs then that OCaml was more efficient (? -- WAGuess), and would they prefer Haskell now?
Ocaml definitely has more visibility in finance, due to at least two real world uses: - at Jane St Capital - The lexifi contract description language (www.lexifi.com) I'm not aware of any ongoing haskell work in finance, other that some private work being done by Alain Cremieux, reported in the HCAR. I'd be happy to learn of any more, however. I don't think there's any reasons right now why one ought to favour ocaml over haskell in this domain. Tim
On Jan 23, 2007, at 10:37 PM, Tim Docker wrote:
I'm not aware of any ongoing haskell work in finance,
I'm gearing up to do something but don't have anything to show yet.
I'd be happy to learn of any more, however. I don't think there's any reasons right now why one ought to favour ocaml over haskell in this domain.
The reason OCaml was used for LexiFi was _not_ performance. I think Jean-Marc Eber was just a big OCaml user and shared offices or was close to the OCaml team at INRIA. The reason Jane St. is usign OCaml is definitely performance. These guys are trying to shave milliseconds of their processing time. The reason I want to use Haskell where OCaml seems to be more appropriate is because I'm stubborn and a sucker for punishment :-). OCaml also doesn't hold a candle to Haskell in elegance. Think let ... in ..., begin ... end or parens instead of the same, rules for using 'and' in function clauses, etc. etc. etc. I like elegance and hope that performance will catch up, specially with the great strides made in binary IO and data-parallel Haskell. Joel -- http://wagerlabs.com/
Tim Docker wrote:
I'm not aware of any ongoing haskell work in finance, other that some private work being done by Alain Cremieux, reported in the HCAR.
Lennart Augustsson works for Credit Suisse, using a Haskell DSEL to
generate financial models for execution by clusters running Excel.
(This I gleaned from him in IRC the other day; apologies to Lennart if I
misremember the specifics.)
I believe that Goldman Sachs might be using Haskell, too, but I don't
know for sure (they have at least one ex-Yale FRP person, at any rate).
Wall Street has long had a fondness for esoteric technologies (APL,
Linda, you name it). I'm sure there are more Haskell users lurking
there somewhere.
Hello,
On 1/23/07, Bryan O'Sullivan
Tim Docker wrote:
I'm not aware of any ongoing haskell work in finance, other that some private work being done by Alain Cremieux, reported in the HCAR.
Lennart Augustsson works for Credit Suisse, using a Haskell DSEL to generate financial models for execution by clusters running Excel. (This I gleaned from him in IRC the other day; apologies to Lennart if I misremember the specifics.)
I believe that Goldman Sachs might be using Haskell, too, but I don't know for sure (they have at least one ex-Yale FRP person, at any rate).
Wall Street has long had a fondness for esoteric technologies (APL, Linda, you name it). I'm sure there are more Haskell users lurking there somewhere.
I work at Deutsche Bank. I am using Haskell to manage several databases, using HDBC and HAppS, and do some data mining and (light) numerical calculation. -Jeff
On Tue, 23 Jan 2007, Alexy Khrabrov wrote:
I wonder if that's another reason OCaml is used in a(t least one) hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder? Was it the state of affairs then that OCaml was more efficient (? -- WAGuess), and would they prefer Haskell now? I'm trying to make sense out of OCaml objects out of that already infamously annoying "Practical OCaml" book, and class object <blah>... doesn't look like much, not to say that "class object" sounds about as bad as most English in that book. (Written by an English major... What a decline in US education! :)
According to people's reviews, that book is just as bad as the sample chapter (chapter 6), which is like the worst technical book ever. You'd better read Jon Harrop's book "Objective Caml for Scientists", or use online resources. (I am being off-topic?) Martin -- Martin Jambon http://martin.jambon.free.fr
participants (6)
-
Alexy Khrabrov -
Bryan O'Sullivan -
jeff p -
Joel Reymont -
Martin Jambon -
Tim Docker