Hi, Banibrata.<br><br><div>Before my opinion, could you tell me where, from which books, did you know </div><div>spot patterns? A request for reading materials suggestion.</div><div><br></div><div>Back to this topic,</div>
<div><br><div class="gmail_quote">On Sun, Jun 12, 2011 at 10:51 PM, Banibrata Dutta <span dir="ltr"><<a href="mailto:banibrata.dutta@gmail.com">banibrata.dutta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">Prematurely sent.<div class="im"><br><br>On Sun, Jun 12, 2011 at 7:59 PM, Banibrata Dutta <span dir="ltr"><<a href="mailto:banibrata.dutta@gmail.com" target="_blank">banibrata.dutta@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>What would be a good way to correlate asynchronous events, spot patterns over a sliding window (s.a. of no. of events elapsed or time elapsed), with millions of events occurring simultaneously, using Erlang ?<br>
<br>The set of possible events is known, and any unknown event is just flagged as 'unknown' (so all unknowns are similar). The set of possible event patterns can be enumerated, but is possibly quite a large set of patterns.<br>
</blockquote></div></div><br>Was wondering as to what could be the approach taken to implement such a thing in pure Erlang. My initial thoughts were along the line of maintaining FSMs per event source, but with so many events and so many possible/valid patterns, the thing seems kind of unwieldy. Also, I'd like a non-programmer to be able to define new events and valid event patterns.<br>
<br>I believe 'Complex Event Processing' is quite likely to be the standard
approach for such things, as I've found from some posts, and solutions
exist in Java world for same, but both as an academic exercise (for the fun of learning) and for a potentially simpler + better solution, would like to try doing this is Erlang.<br><br>-- <br>regards,<br><font color="#888888">Banibrata<br>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br></div><div>The atomic message-sending command in Erlang is just to send things and done.</div><div>"Send and forget it." Joe Armstrong and Erlang book writers said the word.</div>
<div><br></div><div>A strip can be seen in many Erlang programs.</div><div><br></div><div> Pid ! {self(), hello, world},</div><div> receive</div><div> {Pid1, Pattern1} -></div><div> ....</div><div>
end,</div><div><br></div><div>a 'send' followed by a 'receive'. It seems synchronous.</div><div><br></div><div>There can be some asynchronous approach. For example, a listener is started and</div><div>
its PID is recorded as 'Pid1'. Every time it sends messages, the strip of sending can</div><div>be</div><div><br></div><div> Pid ! {Pid1, hello, world},</div><div><br></div><div>sending a message but no 'receive' instruction following. The PID of the listener is</div>
<div>within the message, and it's treated as a callback endpoint by remote process.</div><div>This is a general asynchronous model.</div><div><br></div><div>On concepts of event-processing, in my opinion, it's similar to the Object-Oriented</div>
<div>concepts. Some may want to define as many as possible, near all available,</div><div>events/objects when planning and designing a system. However, most of these</div><div>efforts tend to be in vain. Better approach can be to just list events/objects those</div>
<div>in need and use their common patterns.</div><div><br></div><div>/yhh<br clear="all"><br>-- <br><div><br></div>Best Regards.<div><br></div><div>--- Y-H. H.</div><div><br></div><br>
</div>