Week 2

Getting Pull Requests In …. Hello everyone, hope this blog finds you well.

This week has been a significant week in my initial work. Interactions with my mentor @blueloveTH and his suggestions gave considerable directions to the project. I appreciate him for being clear and to the point, and would like to thanks him for the freedom he gives me to explore on my own self.

Aim :

My aim for this week was to get PR#4 merged by my mentors. I aim for the code in numpy.hpp to be robust for all use cases and for all dtpyes.

Work :

Although I did not raise any new pull requests, these where some points of discussion with my mentor after going through my pull request from last week -

• Is making a pocketpy ndarray wrapper redundant : We discussed that xtensor is a header only library so it’s headers can directly be used with our pybind11 implementation. It would be a more straight forward approach.

  The approach regarding making a wrapper first and then exposing that to python was discussed in my proposal and you can do through it as well here. We actually are going against the traditional approach of writing a .hpp file to declare the interfaces (seen by the user) and a .cpp file to define the implementations (for the developer) as we are populating numpy.hpp with implementations.
  I believe this approach is advantageous due to these reasons.

  • It provides an additional C++ API of numpy.
  • It makes writing the python bindings simpler.
  • It hides unwanted implementations from external libraries like xtensor and xtensor-blas.
• No requirement to support numpy.complex for our numpy module : I have stashed all the routines using complex types to backlogs for now. If time permits I’ll make sure to complete these routines as well.

• The appraoch for writing python bindings through pybind11 : Figuring this approach out was the most challenging task of this week and will be an integral part of my project.

  Here is the step by step breakdown of this appraoch -

  1. As the code in the wrapper is templated, we cannot directly write bindings for it using pybind11 as it only allows bindings detailed functons. You can have a look at this issue as reference. So ndarray<T> should derive from a non templated base, something like ndarray_base.
  2. All the bindigs would not target this base class. So we make a single python class say ndarray instead of multiple classes like ndarray<int>, ndarray<float> etc.

  3. We would need a dispatching mechanism to return the appropriate ndarray when a particular type is targeted by the routine.
     To discuss this in more detail I raised the issue #5 - Discussion on dispatch mechanisms for ndarray classes.

     There are 2 methods I was confused between. I could use virtual functions to dispatch the appropriate ndarray instance or I could dispatch on the python side itself. Although both mechanisms gave the correct answer it is not predictable which mechanism is optimal. Although both methods made sense and I was fairly condifent in implementing both, I looked to my mentors for suggestions.

     We plan to go ahead with virtual functions due to the following reasons -
     a. Dispatching on python side would require us to write repetitive binding code for each dtype which is redundant.
     b. Writing isolated code for each dtype will cause unnecessary code bloat and affect build time.

Future Work :

In the upcoming week, I would implement the python bindings code in numpy.cpp and send in a pull request as soon as possible.