octave-maintainers
[Top][All Lists]
Advanced

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

Re: GSOC 17 - Octave - Reutilization of NNET on CNN Project


From: Francesco Faccio
Subject: Re: GSOC 17 - Octave - Reutilization of NNET on CNN Project
Date: Thu, 23 Mar 2017 19:45:02 +0100



2017-03-22 19:13 GMT+01:00 Brayan Impatá <address@hidden>:
Hi Rik,

I will give them a glance and a try. I have never wrote one so I guess that my proposal's timing would be more realistic given I get some experience with this. As for Tensorflow abandoning the C++ API, on November 2016 a contributor said that was unlikely since the Tensorflow serving uses it (check it here).

On 22 March 2017 at 17:21, Rik <address@hidden> wrote:
On 03/22/2017 09:00 AM, address@hidden.org wrote:
Subject:
Re: GSOC 17 - Octave - Reutilization of NNET on CNN Project
From:
Brayan Impatá <address@hidden>
Date:
03/22/2017 01:07 AM
To:
address@hidden
List-Post:
<mailto:address@hidden.org>
Precedence:
list
MIME-Version:
1.0
References:
<HE1PR0601MB2265D69601F28D33B8address@hiddenrprd06.prod.outlook.com> <address@hidden.nabble.com> <CAMg2hZk_3tGiuhs+tQ=oZMnRbWBDaddress@hiddengmail.com>
In-Reply-To:
<CAMg2hZk_3tGiuhs+tQ=oZMnRbWBDaddress@hiddengmail.com>
Message-ID:
<CAMg2hZ=Omw-Wq958hWH9gy-48d6iaddress@hiddengmail.com>
Content-Type:
multipart/alternative; boundary=001a11422a3c89d27b054b4d3fa1
Message:
3

Hi,

I've seen we have a strong dependency to the Pytave project if we pretend to use Tensorflow/Keras through its Python interface. Shall we better move to use OCT files to define the CNN module and use the C++ API that Tensorflow exposes? It does not seems to be a good idea depending on another developing project.

I would say that many people overestimate the difficulty of using .oct files.  I re-wrote a lot of the documentation on using the external interface so I think the manual is pretty clear now.  And there are many usage examples in the libinterp/dldfcn directory to begin an implementation from.  Since Tensorflow exposes a C++ API it makes a whole lot of sense to me to use this approach rather than go through a longer path of Octave->Python->Tensorflow->Python->Octave.

The only caveat I see is this, "A word of caution: the APIs in languages other than Python are not yet covered by the API stability promises."  However, I doubt they are going to abandon C++ as an API.

---Rik




--
Un saludo,
Brayan.
Dear Rik, Brayan,
 
In my opinion it is better to use the Python API. I agree on the fact that it would be easier to do everything in terms of OCT-files and I see a lot of improvement in the C++ API and documentation since TensorFlow 1.0 [1].

However, the Python API is the most extended and it is stable. With the experimental C++ API, there could be a lot of incompatibilities between minor releases [2] and this would make the maintainance of the package extremely difficult.

As a developer, I encourage collaboration across projects and I think that the right approach to the community should be as open and collaborative as possible. This means that if this project depends on Pytave and Pytave is under development, then a small part of the work should be devoted to fix features of Pytave that we need.

Francesco

[1]https://www.tensorflow.org/api_docs/cc/
[2]https://www.tensorflow.org/programmers_guide/version_semantics

reply via email to

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