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 > > > >
