<div dir="ltr">Thanks Jesper and other for the pointers.. My work is more on texts corpuses than on images. Will revert if there is something that I can share with the team.. :)<div><br></div><div>Regards,</div><div>Theepan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 5:01 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@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 dir="ltr"><span class=""><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 10:34 AM, Samuel <span dir="ltr"><<a href="mailto:samuelrivas@gmail.com" target="_blank">samuelrivas@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 style="overflow:hidden">I am not aware of existing ML or linear algrebra libraries in erlang<br>
that can be used to quick start an ML project, but just piping into<br>
tensorflow (or any other existing library/framework) isn't really<br>
doing ML with erlang, is it? You can as well just use tensorflow<br>
directly.</div></blockquote></div><br></div></span><div class="gmail_extra">The question is if this is a practical problem which needs solving or it is for research. If you are researching how to construct, say, SVM or NNs, then surely Erlang is a good vehicle. But in practice, there is a number of things which makes Erlang unsuitable:<br><br></div><div class="gmail_extra">* ML is often CPU bound. You don't want a bytecode interpreter to be a limiting factor here. Even if the interpreter in Erlang is state-of-the-art and highly optimized, it is not far fetched that a FP-intensive program will be roughly a factor of 30 faster if compiled in a lower level language.<br><br></div><div class="gmail_extra">* GPUs are popular in ML models for a reason: they speed up the FP computations by a factor of 3000 or more. This in itself should hint you that you need something else than Erlang.<br><br></div><div class="gmail_extra">* Erlangs word overhead per process and terms means a lower-level model can pack many more entities in memory. This affects caching behavior.<br><br></div><div class="gmail_extra">Training of the model is often off-line and using the model is online in the system. How you train your model is less important. This is why I'd just outsource this problem to the libraries built and tuned for it. It is like solving LinAlg problems but forgetting everything about existing LAPACK and ATLAS routines in Fortran.<br><br></div><div class="gmail_extra">A model, in Erlang, which could be viable is to use Erlang to produce programs for lower level consumption by compilation. But these are problems for which languages such as Haskell and OCaml dominates for a reason: their type systems makes it far easier to pull off.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br clear="all"><br>-- <br><div>J.</div>
</div></font></span></div>
</blockquote></div><br></div>