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 <cjolivie...@gmail.com> 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 <lupe...@gmail.com> 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" <workc...@gmail.com on behalf of > > tqc...@cs.washington.edu> 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 > > > > > > > > >
