Re: MXNet Berlin User Group

Am 9. April 2019 17:56:21 MESZ schrieb Jose Luis Contreras Santos : >This is a friendly reminder that the MXNet Berlin User Group will be >held >today, starting in a few minutes at 6pm-7pm (CEST) / 9am-10am (PST). Would you mind providing a brief summary of the user group here? How many ppl

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Really nice improvement over MXNet's usability! I suggest that we could make numpy-compatible behavior default in 2.0. On Wed, Apr 10, 2019 at 11:34 PM Jun Wu wrote: > Dear Community, > > A while ago, we sent out an RFC > discussing the >

Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Dear Community, A while ago, we sent out an RFC discussing the initiative introducing NumPy compatibility into MXNet. As the first outcome of this initiative, we submitted the PR

Re: MXNet Berlin User Group

We didn't have any attendees this time either. As Chance says, I believe we need to rethink these users groups, we very rarely have any users as they stand right now. The idea of having talks from contributors sounds like an interesting one to me. Jose El jue., 11 abr. 2019 a las 10:14, Chance

Re: MXNet Berlin User Group

I think it would drive attendance if we had a quick talk each week from an interested contributor. We could start a sign up list for topics and issues. Chance Bair On Thu, Apr 11, 2019 at 9:29 AM Isabel Drost-Fromm wrote: > > > Am 9. April 2019 17:56:21 MESZ schrieb Jose Luis Contreras

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

In case only changes to the c-api are being made, it doesn't fall under our semantic versioning since that's not a user facing API and thus I'd be in favour as doing it as part of a minor release. If there is any behavioural change from a user perspective (a good indicator would be if tests have

Re: MXNet Berlin User Group

In addition to talks, we could also consider some mob programming sessions? Maybe use the time to (as a small group) tackle some of the open issues? Maybe this also helps new member to get up to speed with the code and tooling, etc. as well as develop the community by solving problems together =)

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Just curious about when this kind of change will land. Would it wait for 2.0 or would it be in 1.5 or another minor release? On Thu, Apr 11, 2019, 00:15 Junru Shao wrote: > Really nice improvement over MXNet's usability! I suggest that we could > make numpy-compatible behavior default in 2.0. >

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

I was under the impression that C API does fall under semver. Has this been discussed somewhere before ? Is this also the case for C Predict API ? On Thu, Apr 11, 2019, 8:08 AM Marco de Abreu wrote: > In case only changes to the c-api are being made, it doesn't fall under our > semantic

Re: duplicated nnvm code

We should remove 3rdparty/tvm/nnvm/gradient.cc.o imo On Thu, Apr 11, 2019 at 6:44 PM Pedro Larroy wrote: > Hi > > I found that src/nnvm and 3rdparty/tvm/nnvm/src/pass/ has duplicated > code that we are linking in: > > ./CMakeFiles/mxnet_static.dir/3rdparty/tvm/nnvm/src/pass/gradient.cc.o >

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

I'm not sure about whether C APIs should fall under semver. This is the discussion we would like to have with the community. My thinking on this: 1. In most of the cases, C APIs only serve as bridges between frontend language bindings and C++ backend. Most of users/developers do not interact

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Hi Jun, Till now from what I have observed this has been an undocumented guideline to not break C APIs (example: https://github.com/apache/incubator-mxnet/pull/11429#discussion_r199564999). Although the C APIs are supposed to serve only as bridges for frontend language bindings (exception being C

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

My personal opinion towards that discussion is that we should keep the C-API free from semantic versioning because otherwise we're introducing two "fronts" that we have to maintain backwards compatibility for. By the way, currently, we have no way to verify and guarantee the compatibility of the

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Hi Jun, we've had a previous discussion on this topic here: https://lists.apache.org/thread.html/f0d7d96f9737479ec57580a977e9169544ffa1bc1a8ae21ab18fc6a0@%3Cdev.mxnet.apache.org%3E Best regards, Marco On Thu, Apr 11, 2019 at 7:58 PM Jun Wu wrote: > I'm not sure about whether C APIs should

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Good point about the adoption speed for the different frontends, Anirudh. While this is a quite valid argument, I'm afraid of the complexity it might introduce as well as a risk of further diverging frontend functionality. I'd rather propose that we introduce a guideline to follow when changes to

Re: Implementing zero-dim and zero-size tensors in MXNet and its impact on your codebases

Hi Marco, The backend private APIs in engine, executor, storage, ndarray etc. can still be changed. I understand that it may introduce code duplication, but introducing duplicate C APIs can still be better than the backend developer having to worry about different frontends. Not to mention a

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

I don't have idea about the following issues: 1) Reducing the abuse of inlined code moving more logic to implementation files and improve scoping which will also speed up compilation 2) Reduce runtime of some unit tests 3) Improve MXNet startup time Will be super interested to hear about your

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

Thanks Marco for raising this issue. I think we can certainly do some improvements in modularization and build. At the same time Tianqi's point of view is important to consider and on point. I see a high risk of overengineering in such endeavor. I also see increased complexity, difficulty

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

We have a systematic solution to go without ABI headache. I am struggling with some errants, and will share our proposal here as soon as I could. This will be very interesting topic to discuss. Let's work hard together and make it perfect :-) On Thu, Apr 11, 2019 at 12:43 PM Pedro Larroy wrote:

duplicated nnvm code

Hi I found that src/nnvm and 3rdparty/tvm/nnvm/src/pass/ has duplicated code that we are linking in: ./CMakeFiles/mxnet_static.dir/3rdparty/tvm/nnvm/src/pass/gradient.cc.o ./CMakeFiles/mxnet_static.dir/src/nnvm/gradient.cc.o This can potentially cause problems when linking. The symbol that

Re: [MXNET 2.0 Wishlist] [DISCUSS] Backend choices during runtime

I will respond in slack, so we don't derail the original thread's topic with my points. Looking forward to your proposal. On Thu, Apr 11, 2019 at 1:00 PM Junru Shao wrote: > > I don't have idea about the following issues: > > 1) Reducing the abuse of inlined code moving more logic to