On Mar 8, 5:50 pm, Jonathan Shore <jonathan.sh...@gmail.com> wrote: > Now OO may be antithetical to the traditional way of using lisp, however, I > see myself needing something close to an OO-style mapping for part of what I > do. Currently my trading strategies have large and disparate state > contained in each strategy. I'm not really sure how can effeciently map > into clojure. So for instance if I have 50 different pieces of state, some > of which will be: > > - matrices > - numbers > - vectors > - booleans > - FSMs > > How would I encapsulate this into a data structure to be passed into > functions efficiently? I could use a map of symbols to various structures, > but that would be inefficient in access and memory.
It's not really clear what the problem is. If the state is going to stick around for a while and you expect to mutate it then use reference types and keep the variables in namespaces next to the code that operates on them. In the same way that you group your code with your member and class variables when defining a class, you can group your code with the state variables in your namespaces. You can use maps to organize groups of related data, and if you want to update nested parts of this data without having to create new maps all the time you can have the map store refs or atoms that you can mutate safely. Shifting from OO does take a bit of squinting and experimentation, at least it did for me after doing a lot of Ruby and C ++, but now I find that by having my data sitting in the open in standard data structures it lets me experiment and re-use methods much easier without needing to deal with useless machinery. > - does small computations at high frequency > - pushes a huge amount of data through at each timestep > - currently can take hours or days to run with mutation. It will really depend on the nature of the mutation. With some algorithms you can probably optimize the inner loops with type hints, transients, unboxed numbers and raw arrays and get performance on par with Java. I was experimenting with real-time 2D animation in Clojure a while back, and mutating pixel buffers was not a great fit. Anyway, going to Java or even C++ is damn easy from Clojure, so give it a shot and in the worst case you can use Clojure as the glue for a library of lower level algorithms written in whatever you want. -Jeff -- 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
