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 to be changed as reaction to the Backend changes), then I'd prefer a major release.
I'd slightly prefer a minor release since this change touches quite a few parts and could risk being outdated/diverged as the time until 2.0 progresses. -Marco Aaron Markham <[email protected]> schrieb am Do., 11. Apr. 2019, 16:28: > 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 <[email protected]> wrote: > > > 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 <[email protected]> wrote: > > > > > Dear Community, > > > > > > A while ago, we sent out an RFC > > > <https://github.com/apache/incubator-mxnet/issues/14253> discussing > the > > > initiative introducing NumPy compatibility into MXNet. As the first > > outcome > > > of this initiative, we submitted the PR > > > <https://github.com/apache/incubator-mxnet/pull/14661> providing the > > > infrastructure of supporting zero-dim (scalar) and zero-size tensors, > > which > > > have been long-missing in MXNet. > > > > > > In our implementation, we have put the best efforts of keeping the > > promise > > > of backward compatibility in all the language bindings. Nevertheless, > we > > > still would like to call out the changes explicitly that may impact > your > > > existing codebases developed on top of MXNet by calling C-APIs directly > > or > > > implementing operators in your own repos. > > > > > > 1. In you application, if you called any one of the following > > shape-related > > > C-APIs, you will need to change the data type of shape's ndim and > > dim_size > > > from *unsigned int* to signed *int*, because we have to use -1 to > > represent > > > unknown shape information, and reserve 0 for scalar and zero-size > > tensors. > > > One example of such changes can be seen in the cpp-package > > > < > > > > > > https://github.com/apache/incubator-mxnet/pull/14661/files#diff-c0e77771fcfe1619faa4ff5f59d94e8bR183 > > > > > > > calling MXSymbolInferShape. > > > - MXSymbolInfershape > > > - MXSymbolInfershapePartial > > > - MXExecutorSimpleBind > > > - MXExecutorReshape > > > - MXNDArrayGetShape > > > - MXNDArrayCreaetFromSharedMem > > > > > > 2. If you have implemented operators in your own codebases, you will > > > probably need to change every operator's shape inference function to > use > > > the following util functions to check whether shape information is > known, > > > instead of checking against 0 directly. One example of such changes can > > be > > > seen in the shape inference function > > > < > > > > > > https://github.com/apache/incubator-mxnet/pull/14661/files#diff-afa640c4653c59f00f43a84455f91ef9R35 > > > > > > > of concat operator. > > > - shape_is_known (include/mxnet/tuple.h) > > > - ndim_is_known (include/mxnet/tuple.h) > > > - dim_size_is_known (include/mxnet/tuple.h) > > > > > > If you are interested in knowing the value of scalar tensors, and hence > > > understanding our motivation further, this thread > > > <https://discuss.mxnet.io/t/rank-0-arrays-in-mxnet-aka-pi-is-wrong/108 > > > > of > > > discussion provides very good insights from the view of data science. > It > > > was actually related to an opportunity for MXNet becoming the backend > of > > > PyMC <https://en.wikipedia.org/wiki/PyMC3>, but somehow it didn't go > > > through due to missing several key features > > > <https://discuss.mxnet.io/t/moving-pymc3-from-theano-to-mxnet/86>, and > > > scalar tensors is one of them. > > > > > > Please leave comments in the PR > > > <https://github.com/apache/incubator-mxnet/pull/14661> if you have any > > > concerns or suggestions of our work. > > > > > > Thank you very much for your time and consideration. > > > > > > Best, > > > Jun > > > > > > *References* > > > [1] RFC of NumPy compatibility: > > > https://github.com/apache/incubator-mxnet/issues/14253 > > > [2] Pull request of supporting scalar and zero-size tensors: > > > https://github.com/apache/incubator-mxnet/pull/14661 > > > [3] The value of scalar tensors from the view of data science: > > > https://discuss.mxnet.io/t/rank-0-arrays-in-mxnet-aka-pi-is-wrong/108 > > > [4] Previous discussion for MXNet becoming the backend of PyMC: > > > https://discuss.mxnet.io/t/moving-pymc3-from-theano-to-mxnet/86 > > > > > >
