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:24:58 UTC

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

anirudh2290 commented on issue #14253: [RFC] Introducing NumPy-compatible coding experience into MXNet
URL: https://github.com/apache/incubator-mxnet/issues/14253#issuecomment-468122597
 
 
   Thanks for the RFC!
   > It is just that users are encouraged to access NumPy operator APIs through `mxnet.numpy` to write pure imperative code and Gluon APIs for achieving hybrid coding experience.
   
   Earlier mxnet.ndarray was supposed to give you the experience of writing pure imperative code. Why can't we add the operators under this namespace and make the interface changes for existing operators ? Is there a list of operators which have diverged APIs for numpy and ndarray and can it be timed with 2.0  release?
   
   > We can keep the current behavior unchanged and implement a global switch for users to turn on for expecting NumPy-compatible results.
   If I understand correctly, even when using numpy namespace you need to toggle this switch(probably an env variable?) to obtain the correct slicing ? Have you also considered implementing a seperating numpy ndarray from base with specific functions for slicing like `__getitem__` implemented to avoid using this switch.

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