You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mxnet.apache.org by GitBox <gi...@apache.org> on 2019/02/28 03:45:53 UTC

[GitHub] szha commented on issue #14253: [RFC] Introducing NumPy-compatible coding experience into MXNet

szha commented on issue #14253: [RFC] Introducing NumPy-compatible coding experience into MXNet
URL: https://github.com/apache/incubator-mxnet/issues/14253#issuecomment-468126196
 
 
   @anirudh2290 
   
   > Why can't we add the operators under this namespace and make the interface changes for existing operators ?
   
   We can. However, there exist some operators in mxnet.ndarray whose names are the same as numpy counterparts while the behavior are slightly different, this means they cannot exist in the same namespace if we want to preserve backward compatibility. On the other hand, 2.0 is a good opportunity for fixing many of the existing problems besides the operator behaviors, so we'd likely want to take the time. Thus, to start now, having a new namespace would be the most straightforward way to go.
   
   > Have you also considered implementing a seperating numpy ndarray
   
   Yes. Creating different array types means we'd start to see diverging user code, with some in ndarray and some in numpy ndarray, which would become harder to migrate later.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services