On Jun 9, 2009, at 14:59, alfred.morgan.al...@gmail.com wrote:
> I'm pretty well a complete beginner at clojure, but I was hoping I
> could get some advice on how to do this sort of thing efficiently/
> concisely, because as far as I can tell this involves handling an
> awful lot of heavily mutable state, so right now I really feel like
> I'm fighting the language. What data structures should I be using to
> model nodes and their connections, and would atoms/refs/agents be of
> any help to me?
I am not very familiar with the implementation of neural networks, so
I won't go into the details, but here are some ideas:
1) The state you have to handle is the state of the network, which
changes during training iterations. One way to express this in a
functional style is to write a function (train [network-state] ...)
that returns the modified network state.
2) If you end up having multiple state-modifying functions and need
to compose them (e.g. define a training step in terms of more basic
network-modifying steps), you might want to look at the state monad,
which is designed just for that purpose. For an introduction, see the
two Clojure monad tutorials:
http://onclojure.com/2009/03/23/a-monad-tutorial-for-clojure-
programmers-part-3/
http://intensivesystems.net/tutorials/monads_101.html
3) The state monad is also a way to handle mutable state (such as
arrays) in a safe way, in which it is impossible (as long as some
basic rules are respected) to have references to the mutable state
leak out of your computation.
4) You can even start with an immutable state representation, write
the basic state modification functions, compose them in the state
monad to get your training algorithm, and see if the result is fast
enough. If not, you just have to reimplement the basic functions
using some mutable state (e.g. Java arrays). Of course such a design
is not trivial, it requires some experience and you will likely write
it several times, but the approach as such is a proven one.
5) As for atoms/refs/agents, it is hard to recommend anything without
knowing your algorithms, and in particular their potential for
concurrency. I'd start by implementing a simple case serially, and
then analyze the code for concurrency potential.
Konrad.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
