[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working on nnet package

From: Mae
Subject: Re: Working on nnet package
Date: Thu, 11 Apr 2019 19:05:09 -0400

> On  11, 2019, at 18:42, Alois Schlögl <address@hidden> wrote:
> On 4/10/19 8:34 PM, Evangelos Rozos wrote:
>> Will anyone advice me what should I do to become the maintainer of
>> this package?
> Disclaimer, I'm not a maintainer of Octave or Octave-forge; so I'm not
> in the position to give you an authoritative answer to that. However, I
> can contribute my own thoughts on this.
> Concern your question, I'd answer this in the following way: As a
> maintainer, you need to be able to deliver. In this case, deliver an
> improved version of nnet, that is somehow *useful to others*.
> Concerning the topic of ANN, machine learning, etc., there are a few
> things to consider. As maintainer of the NaN-toolbox (A statistics and
> *machine learning* toolbox ...), I do have a few thoughts on that topic,
> which you might consider or ignore. You should consider that between
> 2010 and today, there was a big shift in ML, that is "Deep Learning"
> (DL). DL uses Neural Networks of course, but nowadays, there are
> powerful DL frameworks around. IMHO, I'd give it a second thought
> whether you really want to re-implement ANN's in order to set up just
> another DL framework. The level of sophistication in these frameworks is
> very high, any new implementation can hardly compete there. Moreover,
> you might also want to exchange (pre-trained) Deep learning models with
> other frameworks.
> A much more promising approach seems incorporating some open sourced
> Deep Learning framework into Octave. E.g. setting up an interface to
> Tensorflow or ONNX through mex/oct C/C++ interface would be an
> interesting task. Looking at the c_api of TF 1.13, it seems that one
> need to get familiar with dataflow graphs, and protobuf, etc. Matlab
> uses ONNX, so for compatibility one might use ONNX; otoh, Google's
> Tensorflow seems to be technologically more advanced, therefore, I'd go
> with a mex interface to tensorflow. It's certainly not a trivial
> project, but it should be possible. There are already TF interfaces for
> a number of other languages, so way not Octave as well.
> Best,
>   Alois
> P.S.: Some experimental code for a mex-interface to Tensorflow is
> available here:
>    https://sourceforge.net/p/octave/NaN/ci/default/tree/src/mexTF.c
> Feel free to continue from here. 

As a person who uses pytorch for experimental deep learning experiments it also 
is an attractive target which seems to be the most popular (at least in 
research) in recent months.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]