<div dir="ltr">Set Erlang aside for this problem and go use TensorFlow to learn about neural network training and applications. There is way too much to learn in this field to worry about how it might apply to our favorite language.<div><br></div><div>As has already been said, Erlang is well suited for coordinating process automation using these toolsets, but the architecture of running complex models on CUDA and cuDNN is completely non trivial and the entire focus of libraries like TensorFlow, Theano, Caffe, etc.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 11, 2016 at 12:04 PM <<a href="mailto:lloyd@writersglen.com">lloyd@writersglen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Teepan,<br>
<br>
While I understand that Erlang may not deliver the performance needed for serious machine learning programs, I'd much welcome anything you can contribute toward demonstrating how machine learning ideas and algorithms can be implemented in Erlang.<br>
<br>
Tinker toy models, while not fast, can be very valuable learning tools. Given my aging brain and severe time constraints, I'd much rather play around with these ideas in a language I know than jumping across who knows how many syntactic boundaries to implement something in a black box.<br>
<br>
Bests wishes,<br>
<br>
LRP<br>
<br>
P.S. I'm also interested in processing text corpuses. So I'd also welcome anything you might contribute in this area.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: "Theepan" <<a href="mailto:vasdeveloper@gmail.com" target="_blank">vasdeveloper@gmail.com</a>><br>
Sent: Thursday, February 11, 2016 12:43pm<br>
To: "Jesper Louis Andersen" <<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>><br>
Cc: "Erlang Questions Mailing List" <<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>><br>
Subject: Re: [erlang-questions] Machine Learning<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
Thanks Jesper and other for the pointers.. My work is more on texts<br>
corpuses than on images. Will revert if there is something that I can share<br>
with the team.. :)<br>
<br>
Regards,<br>
Theepan<br>
<br>
<br>
On Wed, Feb 10, 2016 at 5:01 PM, Jesper Louis Andersen <<br>
<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>> wrote:<br>
<br>
><br>
> On Wed, Feb 10, 2016 at 10:34 AM, Samuel <<a href="mailto:samuelrivas@gmail.com" target="_blank">samuelrivas@gmail.com</a>> wrote:<br>
><br>
>> 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.<br>
>><br>
><br>
> The question is if this is a practical problem which needs solving or it<br>
> is for research. If you are researching how to construct, say, SVM or NNs,<br>
> then surely Erlang is a good vehicle. But in practice, there is a number of<br>
> things which makes Erlang unsuitable:<br>
><br>
> * ML is often CPU bound. You don't want a bytecode interpreter to be a<br>
> limiting factor here. Even if the interpreter in Erlang is state-of-the-art<br>
> and highly optimized, it is not far fetched that a FP-intensive program<br>
> will be roughly a factor of 30 faster if compiled in a lower level language.<br>
><br>
> * GPUs are popular in ML models for a reason: they speed up the FP<br>
> computations by a factor of 3000 or more. This in itself should hint you<br>
> that you need something else than Erlang.<br>
><br>
> * Erlangs word overhead per process and terms means a lower-level model<br>
> can pack many more entities in memory. This affects caching behavior.<br>
><br>
> Training of the model is often off-line and using the model is online in<br>
> the system. How you train your model is less important. This is why I'd<br>
> just outsource this problem to the libraries built and tuned for it. It is<br>
> like solving LinAlg problems but forgetting everything about existing<br>
> LAPACK and ATLAS routines in Fortran.<br>
><br>
> A model, in Erlang, which could be viable is to use Erlang to produce<br>
> programs for lower level consumption by compilation. But these are problems<br>
> for which languages such as Haskell and OCaml dominates for a reason: their<br>
> type systems makes it far easier to pull off.<br>
><br>
><br>
><br>
> --<br>
> J.<br>
><br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>