I am not implementing it, but I prefer C++ for this reason. But then again, I am biased towards C++ in general :) Are there reasons to not do it in C++? Maybe there are...
On Fri, Oct 20, 2017 at 8:08 AM, Tianqi Chen <tqc...@cs.washington.edu> wrote: > I do not have a preference in terms of specifically having to do this in > particular language, and merely mean python would be an easier path. Most > other languages users can still get onnx model to mxnet's format(with a > script) and load it from there. > > Tianqi > > On Fri, Oct 20, 2017 at 8:06 AM, Chris Olivier <cjolivie...@gmail.com> > wrote: > > > 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 <tqc...@cs.washington.edu> > > 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 <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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
