Clojure for financial applications
Hi, Its been 19 years since I last wrote anything serious in lisp (and that was Scheme). In the intervening time I've mostly used OO languages, for lack of more practical functional ones. There are now a number of functional or hybrid functional languages available which have become practical. I am now trying to decide which language to use. Having been in the OO space for a long time I find struggling to determine how to think about the following in regards to clojure: Organization of large projects -- I have 1/2 million lines of my own code. I'm sure a lot of this compresses to something smaller in clojure. This is manageable for me in the OO setting because functions (methods) are bound to their data (object) and in their own namespaces (classes). I am aware of clojure multimethods, but still seems to me that I would end up having a near flat space of thousands of functions. This would be hard to track and grok over time. I see multimethods working very well for data structures, but not offering much for distinct concepts. Dealing with State -- What follows is very domain specific. I have a trading strategy which takes a vector of market data as the market ticks. In the OO composition, the strategy has a large amount of state and the state will differ from one strategy to the next. For instance I would have: - some window of prior tick history or returns (a rolling matrix) - positions - performance tracking - various matrices used in online statistical analysis (specific to strategy) - instances of other classes used in the analysis (specific to strategy) - finite state machine(s) to manage execution and other behavior I can also have strategies that contain sub-strategies.A high- level OO interface would look something like: - method: tick (time, market-vector) - method: ... - property: positions (an object with various atributes and collections) - property: performance (an object with various attributes) - property: ... it sounds like the approach in Clojure would be to have a single large data structure composed of the common stuff and the specific stuff that gets passed around to functions. Of course this is exactly what happens in the OO world, except that the "class" framework allows one to simplify the presentation (implementation) of this binding of state. Now I suppose the structure / obj equiv can be described as a function with a let binding and a series of functions accessible through some means that work on the closure. As is current, the state of this strategy mutates with each tick. I can see theoretically that could be done immutably, seeing each tick creating a partially modified new strategy state, in effect a versioning trail of prior strategy states. I'm not sure whether I would need to bend over backwards to affect this though. Conclusion -- Wondering whether anyone has done something very complex in the algo space or comparable so can get an idea of how this sort of stuff is structured idiomatically. I will also be concerned with performance and memory use, as one of my strategies creates a few thousand sub- strategies and/or also uses massive matrices that get updates from tick to tick. Thoughts? Thanks Jonathan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Implementation issues that may affect performance?
Thanks The use of (int ...) works, avoiding the dispatch, but it has to be used everywhere there is a variable or literal. Starts getting very ugly and unreadable as expressions get longer.Is there any way to indicate an "int" or "double" literal short of (int 2). Here is the modified function: (defn fib [a] (let [v (int a)] (if (< v (int 2)) v (+ (fib (- v (int 1))) (fib (- v (int 2))) I suspect that on recursion a will become an object again and will then need to be downcasted again as well. Would be nice to be able to do: (defn fib [#^int v] (if (< v 2) v (+ (fib (- v 1)) (fib (- v 2) and just have it "work". If v is known to be an int, then one should be able to deduce in this case that the literals should be as well. Short of that, some concise decoration on literals like #2 or something ... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: benchmarks on a poor-man's matrix concept
It looks like the new (deftype ..) may be what I am looking for in
terms of binding heterogenous state efficiently. The matrix function
was just a test case for how to bind state efficiently. Thanks for
all of the responses.
On Mar 8, 2:57 pm, Jonathan Shore wrote:
> Hi,
>
> I'm still trying to work out the best way to deal with operations on
> heterogenous data in clojure. I have a complex application which has such
> requirements. I wrote a simple toy matrix as a means to explore closure
> versus map based implementations. Note that in this case the "data
> structure" is not pure, rather mutable. Here are 2 implementations I came
> up with (note this is my second day with closure, so my not be idiomatic):
>
> The first impl uses closures and provides access via a function (is there a
> more efficient way to do this?, avoiding the cond-dispatch?):
>
> (defn matrix-1 [nrow ncol]
> (let [data (float-array (* nrow ncol))]
> (fn [command & args]
> (condp = command
> :dim
> [nrow ncol]
> :get
> (let [[i j] args] (aget data (* i j)))
> :set
> (let [[i j v] args] (aset-float data (* i j) v))
>
> The second implementation uses a map:
>
> (defn matrix-2 [nrow ncol]
> { :data (float-array (* nrow ncol)), :nrow nrow, :ncol ncol })
>
> (defn mset! [mat i j v]
> (aset-float (get mat :data) (* i j) v))
>
> (defn mget [mat i j]
> (aget (get mat :data) (* i j)))
>
> (defn mdim [mat]
> [(get mat :nrow) (get mat :ncol)])
>
> Both of these implementations bother me. The first because of the dispatch,
> the second because maps clearly are not "near the metal". It would seem
> would have to resort to java side classes, unless there is a better way?
>
> BTW, the map implementation is about 3x faster:
>
> (def m1 (matrix-1 10 10))
> (def m2 (matrix-2 10 10))
> ...
>
> (defn benchmark [what times f]
> (let [
> Tstart
> (System/currentTimeMillis)
> result
> (loop [ntimes times]
> (f)
> (if (> ntimes 0)
> (recur (- ntimes 1
> Tend
> (System/currentTimeMillis)]
> (println "evaluating" what "took" (- Tend Tstart) "ms")))
>
> (benchmark "map-based-matrix" 100 (fn [] (mset! m2 3 3 0.1234)))
> (benchmark "closure-based-matrix" 100 (fn [] (m1 :set 3 3 0.1234)))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure Implementation issues that may affect performance?
Hmm, is there a notation to express an int literal. Better yet, clojure should try to infer that if I do (+ v 2) where v was hinted to be "int", 2 should be considered to be an int. The code starts getting really messy: (defn fib [a] (let [v (int a)] (if (< v (int 2)) v (+ (fib (- v (int 1))) (fib (- v (int 2))) And still, I believe at the recursive step will be converted into an Object again and then casted to a value type. Would be nice to be able to declare as: defn fib [#^int a] On Mar 9, 1:44 am, Timothy Pratley wrote: > On 9 March 2010 04:03, Jonathan Shore wrote: > > > (defn fib [#^Integer a] > > (if (< a 2) > > a > > (+ (fib (- a 1)) (fib (- a 2) > > I'm just learning, so I may have overlooked something that mitigates or > > otherwise avoids dispatch. > > You might want to experiment with something like > (defn fib [a] > (let [ia (int a)] > ..)) > > I know that seems a little weird but anything passed into or out of a > function gets boxed to an object type. (int a) coerces to a primitive > int which for some operations has much better performance. > > Regards, > Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
