[erlang-questions] [Erlang-Question] Is Erlang good for Matrix manipulation and AI related algorithms
Thu Nov 10 06:39:36 CET 2011
Thank you very much for your wise replies!
>Are you meaning message passing in the Erlang sense? This seems a bit
Yes, I mean Message Passing.
>Your description of the algorithm confuses me, can't you describe this
more in the sense of matrix operations than message passing?
>It is unclear how the timing of your messages should be? Some kind of
synchronous? All at once? Asynchronous in whatever order?
Yes, the messages are passed in synchronous way, not all at once but
step-by-step: every node sends messages to its next neighbors at the same
time with other nodes who got a message simultaneously, and the speed of
messages is constant.
>Be aware that syntax is secondary, semantics is the important
>If you want to do this with lists does this mean you first want to
distribute the "messages" in the direction of the innermost dimension
>You need to give us more information what you *really* want to achieve
by this algorithm. Maybe its the wrong algorithm for doing this in
erlang. As you described it I at least can't understand what exactly
you want to achieve with this.
I hope to know there are how many paths across a specific point in a cubic
lattice if we walk from the origin to the far-most diagonal point.
Thank you for your suggestion about Lisp learning.
On Thu, Nov 10, 2011 at 3:08 AM, Peer Stritzinger <> wrote:
> On Wed, Nov 9, 2011 at 6:31 AM, Barco You <> wrote:
> > As known, Erlang is born with inherent distributed-computing properties
> > is good for lists manipulation, but currently I'm encountering a problem
> > that I don't know how to do with Erlang in an efficient way.
> There is no code to see yet but you might watch
> I'm working on a ndimarray module in my spare time, my plans are under
> the above link.
> > I hope to build a cubic matrix with I x J x K dimension (I,J,K are
> > and >= 2), for which the origin (index [1,1,1], or [0,0,0] for
> > is assigned with an initial value 1, and then the initial value is
> > unidirectionally message-passed to adjacent nodes.
> Are you meaning message passing in the Erlang sense? This seems a bit
> overkill then.
> > Every node gets a value
> > that is the sum of afferent messages and continue to pass its value
> > forward, until the far-most node (with index [I,J,K]) gets a value.
> Taking a
> > 2x2x2 dimensional scenario as an example (in the attached picture, the
> > vertices of the cube represent the nodes of the matrix), we will get a
> > matrix as [ [ [1,1], [1,2] ], [ [1,2], [2,6] ] ].
> Your description of the algorithm confuses me, can't you describe this
> more in the sense of matrix operations than message passing?
> It is unclear how the timing of your messages should be? Some kind of
> synchronous? All at once? Asynchronous in whatever order?
> > To implement this, I'll have two functions: gen_cubic([I,J,K]) -> list().
> > get_value([i,j,k], Cubic::list()) -> number().
> > BTW: I heard of that Lisp is good for this kind of matter, but when I
> > to learn List yesterday I found it's so hard to read and the syntax is
> > so natural as Erlang.
> Be aware that syntax is secondary, semantics is the important
> differentiation factor.
> If you want to do this with lists does this mean you first want to
> distribute the "messages" in the direction of the innermost dimension
> You need to give us more information what you *really* want to achieve
> by this algorithm. Maybe its the wrong algorithm for doing this in
> erlang. As you described it I at least can't understand what exactly
> you want to achieve with this.
> Anything that can be done in Lisp *except* macros can usually be done in
> > So, if someone have more time, please give your
> > insights comparing these two language. I would appreciate that.
> Lisp and Erlang are similar up to a point (there is even a Lisp
> flavored Erlang = LFE front-end).
> Lisp lists are identical to Erlang lists.
> Lisp macros are not available in Erlang syntax.
> Erlang has pattern matching, very lightweight processes and message
> passing that Lisp doesn't have.
> But on the other hand: The way Lisp is programmed is that it turns
> into whatever domain specific language your problem needs as you go
> along. So in theory at least Lisp can be made to do all these things.
> What can't be done easily in Lisp is getting the performance,
> low-latency and robustness characteristics of Erlang.
> My suggestion: learn both, pick the one you like most first. And when
> you know Lisp and Erlang, learn another language and so on ...
> -- Peer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions