How would this impact use by other languages such as Scala, Perl, C++, etc?
On Fri, Oct 20, 2017 at 8:01 AM, Tianqi Chen <[email protected]> wrote: > Given the instability nature of the current status of onnx, and the ease of > development, python would be favorable as the initial choice > > On Fri, Oct 20, 2017 at 8:00 AM, Chris Olivier <[email protected]> > wrote: > > > Also, what language is the expectation here? Is the ONNX serialization > to > > be developed in the C++ layer or python? Seems like what I saw before > was > > python. > > > > On Fri, Oct 20, 2017 at 1:05 AM, Lupesko, Hagay <[email protected]> > wrote: > > > > > Tianqi, > > > > > > “I would want the code to be in the repo as long as we reach the > > > consensus.” > > > +1 > > > > > > “The reason why I am seeing this decision so seriously is that it will > > > affect how we can influence the design of the exchange format we act > on” > > > IMO, the most important first thing to do in order to influence the > > design > > > of ONNX is to support it, and the actual implementation detail matters > > less. > > > > > > “I am in favor of (2) because technically it gives us a clean future > > > compatibility, offers compilation” > > > What do you mean by “future compatibility”? > > > What do you mean by “offers compilation”? And since MXNet Sym is built > on > > > top of NNVM, why will we not have all of that if we go down the route > of > > > implementing the conversion on top of MXNet Sym? > > > > > > Hagay > > > > > > On 10/19/17, 20:43, "Tianqi Chen" <[email protected] on behalf of > > > [email protected]> wrote: > > > > > > I will start forking the previous discussion and it has gone awry > > and I > > > hope to start a pure technical discussion thread. > > > > > > I said in another email that we could do a vote to settle this > issue. > > > I now > > > think that I was wrong and would like to apology for my rush > proposal > > > on > > > this. > > > > > > I hope to reopen this email thread to gain consensus on what we > want. > > > There > > > has been express of concerns that the code should reside on > > ApacheMXNet > > > repo. I think that discussion is already over and at least I would > > > want the > > > code to be in the repo as long as we reach the consensus. > > > > > > The leftover point is how should we do it. There are two ways of > > doing > > > this > > > > > > 1) Doing it on top of existing Symbol API. > > > 2) Moving most of the exchange layer on standardized core operator > > set, > > > namely mxnet/gluon spec. > > > > > > Both approaches are feasible. There is some advocation on which way > > > might > > > be simpler, but the additional effort of engineering won't be that > > > much. > > > The reason why I am seeing this decision so seriously is that it > will > > > affect how we can influence the design of the exchange format we > act > > > on, and > > > how easily it is to integrate future features that are made > > available. > > > > > > I am in favor of (2) because technically it gives us a clean future > > > compatibility, offers compilation and articulates clearly what > > > ApacheMXNet's stance on core operators. > > > These things could bring more impact to the community in general. > > > > > > Tianqi > > > > > > > > > > > > > > >
