[INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting
Dear MXNet community, I would like to invite you to the regular Apache MXNet (Incubating) User Group meeting on the 19th of March 2019 [1]. As usually, the meeting will have remote VC, powered by Amazon Chime [2]. Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) / 10am-11am (PST).* One hour later than usual. Join the meeting: https://chime.aws/2671929429 Meeting ID: 2671929429 Looking forward to meet you there. Best Per [1] https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+ User+Groups+recurring+meetings [2] https://chime.aws/
Re: [INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting
Hi Per da Silva, I would like to join this meeting. I would like to ask about some solution of how to replace the depreciated "crop" layer properly. I found many have the same issue and I do not find a proper solution. It can be a real deal breaker for me despite I am really fond of MXNET and use it in Philips for product development for more than 2 years. I am opening a startup and hope to continue using mxnet. I am from Belgium by the way. See you today at 7PM Best regards, Wen-Yang On Tue, May 14, 2019 at 1:52 PM Per da Silva wrote: > Dear MXNet community, > > I would like to invite you to the regular Apache MXNet (Incubating) User > Group meeting on the 19th of March 2019 [1]. > > As usually, the meeting will have remote VC, powered by Amazon Chime [2]. > > Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) / > 10am-11am (PST).* One hour later than usual. > > Join the meeting: > > https://chime.aws/2671929429 > > Meeting ID: 2671929429 > > Looking forward to meet you there. > > Best > Per > > [1] > > https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+ > User+Groups+recurring+meetings > [2] https://chime.aws/ >
Re: [INVITATION] 14th of May 2019 / Berlin MXNet Recurring User Group Meeting
Hey Wen-Yang Chu, Unfortunately, my talents are more on the CI/CD at the moment, so I don't know that I'll be able to answer your question. Is there anyone out there than can join us and shine some light in the situation? If no one is able to join, I'll try to understand your question and find someone who knows the answer. Mad props to you for bringing MXNet to Phillips and your startup!! Cheers, Per On Tue., 14 May 2019, 3:21 pm Wen-Yang Chu, wrote: > Hi Per da Silva, > > I would like to join this meeting. I would like to ask about some solution > of how to replace the depreciated "crop" layer properly. > I found many have the same issue and I do not find a proper solution. It > can be a real deal breaker for me despite I am really fond > of MXNET and use it in Philips for product development for more than 2 > years. I am opening a startup and hope to continue using mxnet. > I am from Belgium by the way. See you today at 7PM > > Best regards, > > Wen-Yang > > On Tue, May 14, 2019 at 1:52 PM Per da Silva wrote: > > > Dear MXNet community, > > > > I would like to invite you to the regular Apache MXNet (Incubating) User > > Group meeting on the 19th of March 2019 [1]. > > > > As usually, the meeting will have remote VC, powered by Amazon Chime [2]. > > > > Due to availability, **TODAY** It will be held from* 7pm-8pm (CEST) / > > 10am-11am (PST).* One hour later than usual. > > > > Join the meeting: > > > > https://chime.aws/2671929429 > > > > Meeting ID: 2671929429 > > > > Looking forward to meet you there. > > > > Best > > Per > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/MXNET/Apache+MXNet+%28Incubating%29+ > > User+Groups+recurring+meetings > > [2] https://chime.aws/ > > >
Re: Python2 End of Life
+1 Let python2 rest, let's simplify our infrastructure and need to support old Python versions. On Mon, May 13, 2019 at 1:58 PM Jake Lee wrote: > > +1 Recently I upgraded the Numpy version and found out that Pylint had > false alarm on it. The Pylint fix is only available on Python3. So I > changed the default python version of 'make pylint' command to python3 (PR > haven't been merged). It's time to drop support for Python2. > > On Mon, May 13, 2019 at 1:37 PM Junru Shao wrote: > > > +1 > > > > On Mon, May 13, 2019 at 1:34 PM Aaron Markham > > wrote: > > > > > +1 for the pledge and to start moving things to Python 3. > > > I think our installation instructions and tutorials can be updated to > > > default to Python3 and we should update Python2-only tutorials. I know > > > we have a handful of those, and when I spot them, I'll create an > > > issue. > > > I can also look at migrating the docs build to Python 3. > > > Should we add a new label for issues relating to migrating to Python3? > > > Cheers, > > > Aaron > > > > > > On Mon, May 13, 2019 at 12:04 PM Zach Kimberg > > > > > wrote: > > > > > > > > Right now, the official date for ending support for Python 2.7 (and all > > > of > > > > python2) is set to January 1 [1]. As part of it, a number of projects > > > have > > > > pledged to drop support for Python2 in or before 2020 including > > > Tensorflow, > > > > requests, pandas, ipython, numpy, pillow, and Cython [2]. I believe we > > > > should also join in this pledge on python3statement.org [2] because it > > > > would help clean up our project and it would be difficult to continue > > > > supporting Python2 anyway when some of our dependencies are dropping > > > > support. > > > > > > > > As a concrete step, we should decide on a date to remove all usages of > > > > Python2 from our CI and consider that officially dropping support. > > > > Following that, we can expect PRs will end up breaking support for > > > Python2. > > > > I suggest just using the same date that Python is dropping support of > > > > January 1. We may also need to update some examples or scripts that > > were > > > > written only for python2 that are around the project. Any thoughts? > > > > > > > > Zach > > > > > > > > > > > > [1] - https://www.python.org/dev/peps/pep-0373/ > > > > [2] - https://python3statement.org/ > > > > >
Re: assimilation of mshadow into the MXNet codebase
Hi Sheng. Do you need some help with this? Do we plan to have this for 1.5? Pedro. On Wed, Apr 24, 2019 at 4:26 PM Pedro Larroy wrote: > > Thanks. Great to read. > > On Wed, Apr 24, 2019 at 2:19 PM Sheng Zha wrote: > > > > The community has agreed to donate mshadow to the mxnet code base. I will > > start the migration and build logic changes soon. > > > > -sz > > > > On 2019/04/07 21:47:39, Sheng Zha wrote: > > > I agree it would make development easier to donate mshadow to mxnet code > > > base, since mshadow is only used in MXNet. I support donating the mshadow > > > code to mxnet and I started an RFC for this in mshadow [1]. > > > > > > [1] https://github.com/dmlc/mshadow/issues/373 > > > > > > -sz > > > > > > On 2019/04/06 04:38:19, Tianqi Chen wrote: > > > > Technically, mshadow is sufficient for MXNet. Adopting other libraries ( > > > > eigen or xtensor) will unnecessarily increase the codebase complexity > > > > without any additional gains. > > > > > > > > Given that mshadow is only used by mxnet. I do support donating it into > > > > mxnet codebase. > > > > To respect the original mshadow community. I would recommend starting a > > > > community RFC In the mshadow github issue for a week, before we start > > > > the > > > > migrating process. > > > > Also, I would recommend a rebase merge just like the case of MXNet.jl > > > > code > > > > base to preserve the contribution history. > > > > > > > > Tianqi > > > > > > > > > > > > On Fri, Apr 5, 2019 at 9:25 PM Alfredo Luque > > > > wrote: > > > > > > > > > Do you have a link to both of these proposals? > > > > > > > > > > On Fri, Apr 5, 2019 at 20:14 Anirudh Acharya > > > > > wrote: > > > > > > > > > > > Hi Pedro, > > > > > > > > > > > > mshadow is mostly used for tensor arithmetic. There have been > > > > > > discussions > > > > > > about including it within mxnet. I think it is a good idea. > > > > > > > > > > > > As a more long term solution using libraries like eigen to perform > > > > > > linear > > > > > > algebra operations was also suggested by anirudh2290@. I think > > > > > > xtensor( > > > > > > https://github.com/QuantStack/xtensor ) can also be a candidate > > > > > > here. > > > > > > > > > > > > - > > > > > > Anirudh > > > > > > > > > > > > > > > > > > On Fri, Apr 5, 2019 at 7:03 PM Pedro Larroy < > > > > > pedro.larroy.li...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > Some developers have noticed that working in mshadow is > > > > > > > cumbersome as > > > > > > > it's a 3rdparty subrepo. > > > > > > > > > > > > > > Since mshadow is a bunch of headers which don't have much of > > > > > > > independent tests / library functionality, me and other developers > > > > > > > believe that it would be good to assimilate this code in the > > > > > > > repository for ease of contribution and changes without having to > > > > > > > go > > > > > > > trough contortions to test PRs that modify mshadow. > > > > > > > > > > > > > > Would anybody oppose this change? > > > > > > > > > > > > > > Thanks and have a nice weekend. > > > > > > > > > > > > > > Pedro. > > > > > > > > > > > > > > > > > > > > > > > > >
[Proposal] New operator graph for MXNet
Hi dev@ As a result of my deep dives on the graph machinery I have created a new proposal to improve the operator graph in MXNet. This would mean superseding the use of NNVM Graph in MXNet and having a new implementation that we can use to simplify a lot of code and do powerful graph manipulation and passes such as operator fusion and other optimizations. As it would be a change with big impact and ramifications, your thoughts and feedback on the document would be highly appreciated so we can take potential future interesting use cases: https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0 Pedro.
Re: [Proposal] New operator graph for MXNet
Hi Pedro, Thanks for taking the inititaive. Skimming through the design doc, I didn't see comparison with existing solutions such as relay in tvm, which is already a dependency of mxnet already. Could you elaborate on comparison with existing solutions in the design doc too? -sz On 2019/05/14 23:49:30, Pedro Larroy wrote: > Hi dev@ > > As a result of my deep dives on the graph machinery I have created a > new proposal to improve the operator graph in MXNet. > > This would mean superseding the use of NNVM Graph in MXNet and having > a new implementation that we can use to simplify a lot of code and do > powerful graph manipulation and passes such as operator fusion and > other optimizations. > > As it would be a change with big impact and ramifications, your > thoughts and feedback on the document would be highly appreciated so > we can take potential future interesting use cases: > > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0 > > Pedro. >
Re: [Proposal] New operator graph for MXNet
Hi Sheng Could you provide relevant links to Relay and what you would recommend to read so we have a focused discussion instead of me potentially me miss-searching? Probably I also missed the discussion or vote in the mail list regarding including TVM as a depedency or future plans on using Relay. As far as I know, we have TVM as a dependency because NNVM was assimilated into it but we are not using it directly. Is this correct? This would help me to add this information to the doc as you request. Thanks. Pedro. On Tue, May 14, 2019 at 5:06 PM Sheng Zha wrote: > > Hi Pedro, > > Thanks for taking the inititaive. Skimming through the design doc, I didn't > see comparison with existing solutions such as relay in tvm, which is already > a dependency of mxnet already. Could you elaborate on comparison with > existing solutions in the design doc too? > > -sz > > On 2019/05/14 23:49:30, Pedro Larroy wrote: > > Hi dev@ > > > > As a result of my deep dives on the graph machinery I have created a > > new proposal to improve the operator graph in MXNet. > > > > This would mean superseding the use of NNVM Graph in MXNet and having > > a new implementation that we can use to simplify a lot of code and do > > powerful graph manipulation and passes such as operator fusion and > > other optimizations. > > > > As it would be a change with big impact and ramifications, your > > thoughts and feedback on the document would be highly appreciated so > > we can take potential future interesting use cases: > > > > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0 > > > > Pedro. > >
Re: [Proposal] New operator graph for MXNet
Thanks for the proposal. Let me share some of my thoughts: Specific comments on the proposal --- The heavy use of generic in the Graph type was a huge departure from type-erased data structure which was presented in the previous design. While we understand the advantage of typed language(more compile-time checking) and type-erased types(more dynamism) the heavy use of the template will actually make the project solely C++ focused, making it hard to expose intermediate(templatized) data structure to other languages like python/scala/clojure. While I fully understand some of the lessons taught in programming C++(reduce shared_ptr, more typing etc.) We need to think about the context of MXNet project and **the need to support multi-language as a first-class**. Some of the type-erased types are design trade-offs made to support these features, and we need to think more carefully instead of just applying "rules for C++" which may bring problems. Future of NNVM -- Given that this thread touched upon what we should do for better computational graph handling. I would recommend also to take a look at NNVMv2 -- relay. Relay addresses many of the wish-lists in the proposal already, such as operator fusion, high order gradient, offload to hardware, isolated compilation, deployment on edge and accelerators etc. Relay also address problems not yet being mentioned in the proposal, including control flow and dynamic runtime, automatic layout optimization etc. Tianqi On Tue, May 14, 2019 at 5:06 PM Sheng Zha wrote: > Hi Pedro, > > Thanks for taking the inititaive. Skimming through the design doc, I > didn't see comparison with existing solutions such as relay in tvm, which > is already a dependency of mxnet already. Could you elaborate on comparison > with existing solutions in the design doc too? > > -sz > > On 2019/05/14 23:49:30, Pedro Larroy > wrote: > > Hi dev@ > > > > As a result of my deep dives on the graph machinery I have created a > > new proposal to improve the operator graph in MXNet. > > > > This would mean superseding the use of NNVM Graph in MXNet and having > > a new implementation that we can use to simplify a lot of code and do > > powerful graph manipulation and passes such as operator fusion and > > other optimizations. > > > > As it would be a change with big impact and ramifications, your > > thoughts and feedback on the document would be highly appreciated so > > we can take potential future interesting use cases: > > > > > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0 > > > > Pedro. > > >
Re: [Proposal] New operator graph for MXNet
Hi Tianqi Thanks for the quick response. Could you point to examples where graph.h is being exposed which would not be possible with what I propose? I don't think my proposal is having any impact in language bindings, and the way I describe it doesn't affect having or not having higher language bindings. Please elaborate so I can understand your concern. Maybe code examples where the graph attributes are being changed from Python? I don't think we have this on MXNet. This is such a core foundation for MXNet, that I don't think we should compromise on it because other project not directly related to MXNet might want to expose some untyped graph and Node attributes. The current status makes maintaining the code very painful and also is preventing desired features such as higher order gradients to be developed. I have heard from you many times how speed is critical for us to innovate in this quickly changing field. My proposal is limited to the graph and wouldn't change the way operators are registered and arguments are processed for operators for example. Regarding the second point, the documentation about Relay in the web which I found for example: https://docs.tvm.ai/dev/relay_add_op.html# Is somebody working on making Imperative::Backward use this API? this would be a big change which I'm not aware of. And using an IR is of a much bigger scope than the change I'm proposing here for example. I think I'm having difficulty understanding what are the arguments here. I'm saying I need to change one piece of my car and what you are selling me is a new vehicle here? Or your suggestion that we use Relay for the graph passes in MXNet? I would like to see C++ code examples, Python examples are not sufficient when we talk about the core MXNet. Pedro. On Tue, May 14, 2019 at 5:39 PM Tianqi Chen wrote: > > Thanks for the proposal. Let me share some of my thoughts: > > Specific comments on the proposal > --- > The heavy use of generic in the Graph type was a huge departure from > type-erased data structure which was presented in the previous design. > While we understand the advantage of typed language(more compile-time > checking) and type-erased types(more dynamism) the heavy use of > the template will actually make the project solely C++ focused, making it > hard to expose intermediate(templatized) data structure to > other languages like python/scala/clojure. > > While I fully understand some of the lessons taught in programming > C++(reduce shared_ptr, more typing etc.) > We need to think about the context of MXNet project and **the need to > support multi-language as a first-class**. > Some of the type-erased types are design trade-offs made to support these > features, and we need to think more > carefully instead of just applying "rules for C++" which may bring problems. > > Future of NNVM > -- > Given that this thread touched upon what we should do for better > computational graph handling. I would recommend also to take a look at > NNVMv2 -- relay. > > Relay addresses many of the wish-lists in the proposal already, such as > operator fusion, high order gradient, offload to hardware, isolated > compilation, deployment on edge and accelerators etc. > Relay also address problems not yet being mentioned in the proposal, > including control flow and dynamic runtime, automatic layout optimization > etc. > > Tianqi > > On Tue, May 14, 2019 at 5:06 PM Sheng Zha wrote: > > > Hi Pedro, > > > > Thanks for taking the inititaive. Skimming through the design doc, I > > didn't see comparison with existing solutions such as relay in tvm, which > > is already a dependency of mxnet already. Could you elaborate on comparison > > with existing solutions in the design doc too? > > > > -sz > > > > On 2019/05/14 23:49:30, Pedro Larroy > > wrote: > > > Hi dev@ > > > > > > As a result of my deep dives on the graph machinery I have created a > > > new proposal to improve the operator graph in MXNet. > > > > > > This would mean superseding the use of NNVM Graph in MXNet and having > > > a new implementation that we can use to simplify a lot of code and do > > > powerful graph manipulation and passes such as operator fusion and > > > other optimizations. > > > > > > As it would be a change with big impact and ramifications, your > > > thoughts and feedback on the document would be highly appreciated so > > > we can take potential future interesting use cases: > > > > > > > > https://cwiki.apache.org/confluence/display/MXNET/MXVM%3A+Operator+graph+2.0 > > > > > > Pedro. > > > > >
Re: [Proposal] New operator graph for MXNet
Hi Tianqi I thought a bit more about your comments and I think there is a simple way to address your concerns that satisfies both needs. We can have a NodeAttributes template class which has a map of string to any as it's currenlty the case, so the graph can be used in the highly dynamic scenario that you are concerned about. Let me know what you think. Pedro. On Tue, May 14, 2019 at 5:50 PM Pedro Larroy wrote: > > Hi Tianqi > > Thanks for the quick response. > > Could you point to examples where graph.h is being exposed which would > not be possible with what I propose? I don't think my proposal is > having any impact in language bindings, and the way I describe it > doesn't affect having or not having higher language bindings. Please > elaborate so I can understand your concern. Maybe code examples where > the graph attributes are being changed from Python? I don't think we > have this on MXNet. This is such a core foundation for MXNet, that I > don't think we should compromise on it because other project not > directly related to MXNet might want to expose some untyped graph and > Node attributes. The current status makes maintaining the code very > painful and also is preventing desired features such as higher order > gradients to be developed. I have heard from you many times how speed > is critical for us to innovate in this quickly changing field. > > My proposal is limited to the graph and wouldn't change the way > operators are registered and arguments are processed for operators for > example. > > > Regarding the second point, the documentation about Relay in the web > which I found for example: > > https://docs.tvm.ai/dev/relay_add_op.html# > > Is somebody working on making Imperative::Backward use this API? this > would be a big change which I'm not aware of. And using an IR is of a > much bigger scope than the change I'm proposing here for example. > > I think I'm having difficulty understanding what are the arguments > here. I'm saying I need to change one piece of my car and what you are > selling me is a new vehicle here? Or your suggestion that we use > Relay for the graph passes in MXNet? > > I would like to see C++ code examples, Python examples are not > sufficient when we talk about the core MXNet. > > Pedro. > > > > > > > On Tue, May 14, 2019 at 5:39 PM Tianqi Chen wrote: > > > > Thanks for the proposal. Let me share some of my thoughts: > > > > Specific comments on the proposal > > --- > > The heavy use of generic in the Graph type was a huge departure from > > type-erased data structure which was presented in the previous design. > > While we understand the advantage of typed language(more compile-time > > checking) and type-erased types(more dynamism) the heavy use of > > the template will actually make the project solely C++ focused, making it > > hard to expose intermediate(templatized) data structure to > > other languages like python/scala/clojure. > > > > While I fully understand some of the lessons taught in programming > > C++(reduce shared_ptr, more typing etc.) > > We need to think about the context of MXNet project and **the need to > > support multi-language as a first-class**. > > Some of the type-erased types are design trade-offs made to support these > > features, and we need to think more > > carefully instead of just applying "rules for C++" which may bring problems. > > > > Future of NNVM > > -- > > Given that this thread touched upon what we should do for better > > computational graph handling. I would recommend also to take a look at > > NNVMv2 -- relay. > > > > Relay addresses many of the wish-lists in the proposal already, such as > > operator fusion, high order gradient, offload to hardware, isolated > > compilation, deployment on edge and accelerators etc. > > Relay also address problems not yet being mentioned in the proposal, > > including control flow and dynamic runtime, automatic layout optimization > > etc. > > > > Tianqi > > > > On Tue, May 14, 2019 at 5:06 PM Sheng Zha wrote: > > > > > Hi Pedro, > > > > > > Thanks for taking the inititaive. Skimming through the design doc, I > > > didn't see comparison with existing solutions such as relay in tvm, which > > > is already a dependency of mxnet already. Could you elaborate on > > > comparison > > > with existing solutions in the design doc too? > > > > > > -sz > > > > > > On 2019/05/14 23:49:30, Pedro Larroy > > > wrote: > > > > Hi dev@ > > > > > > > > As a result of my deep dives on the graph machinery I have created a > > > > new proposal to improve the operator graph in MXNet. > > > > > > > > This would mean superseding the use of NNVM Graph in MXNet and having > > > > a new implementation that we can use to simplify a lot of code and do > > > > powerful graph manipulation and passes such as operator fusion and > > > > other optimizations. > > > > > > > > As it would be a change with big impact and ramifications, your > >
Re: [Proposal] New operator graph for MXNet
The core part of the proposal is to move the graph to be much more strongly typed template class. I think this is mainly a point of engineering taste, and both sides have pros and cons, let me list them before I share my thoughts on this issue: - Typed fields certainly enjoy more compile-time type checking, on the other hand, it is hard to expose template of explosive possibilities to frontend languages. - More type-erased fields provide runtime flexibility to store polymorphic types as well as extensible attributes for graph optimization - It is hard to use a virtual class to expose every possible attribute that an operator might have, such as inlining, storage pattern, gradient etc.. - The nature of supporting a growing set of operator attribute requires a type-erased attrs field. - In contrast to your argument(typing is a blocker to features), type-erased or typed code can both get to the same feature except, except that typed code gets more compile-time errors while type-erased get some of them in runtime. - Templatized data structures will likely introduce additional metal burdens to developers and are not really suitable as a core data structure - Because they imply an explosive number of possible data structures, while the core data structure should be a single one. Now my view(as an MXNet PMC member) on typed vs type-erased style: If MXNet is a pure C++ project, I might take more of the typed approach. However, MXNet itself is a project that takes python/scala/clojure and other frontend languages. The introduction of more typing may not align with the original goal as the tradeoffs I listed above. This proposal is really a drastic change of what NNVM does, as well as the optimization passes, and given the scope, in your analogy, "a new vehicle to solve all the problems" rather than a minor patch. It will take a lot of engineering effort to bring in new features and adapting the existing ones. Because of that, it does merit a discussion about how shall we think about the future MXNet2.0. Technically Relay is a serious candidate. Of course relay, as well as its core, is in C++ but maintains the multi-language first principle, that is why the example code was in python. See more related discussion comparing NNVMv1 and relay: https://discuss.tvm.ai/t/any-materials-of-relay-for-beginners/2392/5 I think the ideal graph data structure candidate for MXNet2.0 should have natural support for: - Native support of function, module, and recursions - Control flows - The ability of interpolation with multi-language frontend, e.g. being able to prototype graph optimizations in python/scala/clojure if needed. Adding these support needs significant engineering effort, and I do hope we only have to do it once. While I don't want to force any conclusion here, I do think Relay is one such candidate. Tianqi On Tue, May 14, 2019 at 5:58 PM Pedro Larroy wrote: > Hi Tianqi > > Thanks for the quick response. > > Could you point to examples where graph.h is being exposed which would > not be possible with what I propose? I don't think my proposal is > having any impact in language bindings, and the way I describe it > doesn't affect having or not having higher language bindings. Please > elaborate so I can understand your concern. Maybe code examples where > the graph attributes are being changed from Python? I don't think we > have this on MXNet. This is such a core foundation for MXNet, that I > don't think we should compromise on it because other project not > directly related to MXNet might want to expose some untyped graph and > Node attributes. The current status makes maintaining the code very > painful and also is preventing desired features such as higher order > gradients to be developed. I have heard from you many times how speed > is critical for us to innovate in this quickly changing field. > > My proposal is limited to the graph and wouldn't change the way > operators are registered and arguments are processed for operators for > example. > > > Regarding the second point, the documentation about Relay in the web > which I found for example: > > https://docs.tvm.ai/dev/relay_add_op.html# > > Is somebody working on making Imperative::Backward use this API? this > would be a big change which I'm not aware of. And using an IR is of a > much bigger scope than the change I'm proposing here for example. > > I think I'm having difficulty understanding what are the arguments > here. I'm saying I need to change one piece of my car and what you are > selling me is a new vehicle here? Or your suggestion that we use > Relay for the graph passes in MXNet? > > I would like to see C++ code examples, Python examples are not > sufficient when we talk about the core MXNet. > > Pedro. > > > > > > > On Tue, May 14, 2019 at 5:39 PM Tianqi Chen > wrote: > > > > Thanks for the proposal. Let me share some of my thoughts: > > > > Specific comments on the proposal > > -
