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 <marco.g.ab...@gmail.com> wrote: > 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 <aaron.s.mark...@gmail.com> 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 <junrushao1...@gmail.com> 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 <wujun....@gmail.com> 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 > > > > > > > > > >
