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

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

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

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

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

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 >