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
