| | .. _numpy: |
| |
|
| | NumPy |
| | ##### |
| |
|
| | Buffer protocol |
| | =============== |
| |
|
| | Python supports an extremely general and convenient approach for exchanging |
| | data between plugin libraries. Types can expose a buffer view [#f2]_, which |
| | provides fast direct access to the raw internal data representation. Suppose we |
| | want to bind the following simplistic Matrix class: |
| |
|
| | .. code-block:: cpp |
| |
|
| | class Matrix { |
| | public: |
| | Matrix(size_t rows, size_t cols) : m_rows(rows), m_cols(cols) { |
| | m_data = new float[rows*cols]; |
| | } |
| | float *data() { return m_data; } |
| | size_t rows() const { return m_rows; } |
| | size_t cols() const { return m_cols; } |
| | private: |
| | size_t m_rows, m_cols; |
| | float *m_data; |
| | }; |
| |
|
| | The following binding code exposes the ``Matrix`` contents as a buffer object, |
| | making it possible to cast Matrices into NumPy arrays. It is even possible to |
| | completely avoid copy operations with Python expressions like |
| | ``np.array(matrix_instance, copy = False)``. |
| |
|
| | .. code-block:: cpp |
| |
|
| | py::class_<Matrix>(m, "Matrix", py::buffer_protocol()) |
| | .def_buffer([](Matrix &m) -> py::buffer_info { |
| | return py::buffer_info( |
| | m.data(), |
| | sizeof(float), |
| | py::format_descriptor<float>::format(), |
| | 2, |
| | { m.rows(), m.cols() }, |
| | { sizeof(float) * m.cols(), |
| | sizeof(float) } |
| | ); |
| | }); |
| |
|
| | Supporting the buffer protocol in a new type involves specifying the special |
| | ``py::buffer_protocol()`` tag in the ``py::class_`` constructor and calling the |
| | ``def_buffer()`` method with a lambda function that creates a |
| | ``py::buffer_info`` description record on demand describing a given matrix |
| | instance. The contents of ``py::buffer_info`` mirror the Python buffer protocol |
| | specification. |
| |
|
| | .. code-block:: cpp |
| |
|
| | struct buffer_info { |
| | void *ptr; |
| | ssize_t itemsize; |
| | std::string format; |
| | ssize_t ndim; |
| | std::vector<ssize_t> shape; |
| | std::vector<ssize_t> strides; |
| | }; |
| |
|
| | To create a C++ function that can take a Python buffer object as an argument, |
| | simply use the type ``py::buffer`` as one of its arguments. Buffers can exist |
| | in a great variety of configurations, hence some safety checks are usually |
| | necessary in the function body. Below, you can see a basic example on how to |
| | define a custom constructor for the Eigen double precision matrix |
| | (``Eigen::MatrixXd``) type, which supports initialization from compatible |
| | buffer objects (e.g. a NumPy matrix). |
| |
|
| | .. code-block:: cpp |
| |
|
| | |
| | typedef Eigen::MatrixXd Matrix; |
| |
|
| | typedef Matrix::Scalar Scalar; |
| | constexpr bool rowMajor = Matrix::Flags & Eigen::RowMajorBit; |
| |
|
| | py::class_<Matrix>(m, "Matrix", py::buffer_protocol()) |
| | .def(py::init([](py::buffer b) { |
| | typedef Eigen::Stride<Eigen::Dynamic, Eigen::Dynamic> Strides; |
| |
|
| | |
| | py::buffer_info info = b.request(); |
| |
|
| | |
| | if (info.format != py::format_descriptor<Scalar>::format()) |
| | throw std::runtime_error("Incompatible format: expected a double array!"); |
| |
|
| | if (info.ndim != 2) |
| | throw std::runtime_error("Incompatible buffer dimension!"); |
| |
|
| | auto strides = Strides( |
| | info.strides[rowMajor ? 0 : 1] / (py::ssize_t)sizeof(Scalar), |
| | info.strides[rowMajor ? 1 : 0] / (py::ssize_t)sizeof(Scalar)); |
| |
|
| | auto map = Eigen::Map<Matrix, 0, Strides>( |
| | static_cast<Scalar *>(info.ptr), info.shape[0], info.shape[1], strides); |
| |
|
| | return Matrix(map); |
| | })); |
| |
|
| | For reference, the ``def_buffer()`` call for this Eigen data type should look |
| | as follows: |
| |
|
| | .. code-block:: cpp |
| |
|
| | .def_buffer([](Matrix &m) -> py::buffer_info { |
| | return py::buffer_info( |
| | m.data(), |
| | sizeof(Scalar), |
| | py::format_descriptor<Scalar>::format(), |
| | 2, |
| | { m.rows(), m.cols() }, |
| | { sizeof(Scalar) * (rowMajor ? m.cols() : 1), |
| | sizeof(Scalar) * (rowMajor ? 1 : m.rows()) } |
| | |
| | ); |
| | }) |
| |
|
| | For a much easier approach of binding Eigen types (although with some |
| | limitations), refer to the section on :doc:`/advanced/cast/eigen`. |
| |
|
| | .. seealso:: |
| |
|
| | The file :file:`tests/test_buffers.cpp` contains a complete example |
| | that demonstrates using the buffer protocol with pybind11 in more detail. |
| |
|
| | .. [#f2] http: |
| |
|
| | Arrays |
| | ====== |
| |
|
| | By exchanging ``py::buffer`` with ``py::array`` in the above snippet, we can |
| | restrict the function so that it only accepts NumPy arrays (rather than any |
| | type of Python object satisfying the buffer protocol). |
| |
|
| | In many situations, we want to define a function which only accepts a NumPy |
| | array of a certain data type. This is possible via the ``py::array_t<T>`` |
| | template. For instance, the following function requires the argument to be a |
| | NumPy array containing double precision values. |
| |
|
| | .. code-block:: cpp |
| |
|
| | void f(py::array_t<double> array); |
| |
|
| | When it is invoked with a different type (e.g. an integer or a list of |
| | integers), the binding code will attempt to cast the input into a NumPy array |
| | of the requested type. Note that this feature requires the |
| | :file:`pybind11/numpy.h` header to be included. |
| |
|
| | Data in NumPy arrays is not guaranteed to packed in a dense manner; |
| | furthermore, entries can be separated by arbitrary column and row strides. |
| | Sometimes, it can be useful to require a function to only accept dense arrays |
| | using either the C (row-major) or Fortran (column-major) ordering. This can be |
| | accomplished via a second template argument with values ``py::array::c_style`` |
| | or ``py::array::f_style``. |
| |
|
| | .. code-block:: cpp |
| |
|
| | void f(py::array_t<double, py::array::c_style | py::array::forcecast> array); |
| |
|
| | The ``py::array::forcecast`` argument is the default value of the second |
| | template parameter, and it ensures that non-conforming arguments are converted |
| | into an array satisfying the specified requirements instead of trying the next |
| | function overload. |
| |
|
| | Structured types |
| | ================ |
| |
|
| | In order for ``py::array_t`` to work with structured (record) types, we first |
| | need to register the memory layout of the type. This can be done via |
| | ``PYBIND11_NUMPY_DTYPE`` macro, called in the plugin definition code, which |
| | expects the type followed by field names: |
| |
|
| | .. code-block:: cpp |
| |
|
| | struct A { |
| | int x; |
| | double y; |
| | }; |
| |
|
| | struct B { |
| | int z; |
| | A a; |
| | }; |
| |
|
| | |
| | PYBIND11_MODULE(test, m) { |
| | |
| |
|
| | PYBIND11_NUMPY_DTYPE(A, x, y); |
| | PYBIND11_NUMPY_DTYPE(B, z, a); |
| | |
| | } |
| |
|
| | The structure should consist of fundamental arithmetic types, ``std::complex``, |
| | previously registered substructures, and arrays of any of the above. Both C++ |
| | arrays and ``std::array`` are supported. While there is a static assertion to |
| | prevent many types of unsupported structures, it is still the user's |
| | responsibility to use only "plain" structures that can be safely manipulated as |
| | raw memory without violating invariants. |
| | |
| | Vectorizing functions |
| | ===================== |
| | |
| | Suppose we want to bind a function with the following signature to Python so |
| | that it can process arbitrary NumPy array arguments (vectors, matrices, general |
| | N-D arrays) in addition to its normal arguments: |
| | |
| | .. code-block:: cpp |
| | |
| | double my_func(int x, float y, double z); |
| | |
| | After including the ``pybind11/numpy.h`` header, this is extremely simple: |
| | |
| | .. code-block:: cpp |
| | |
| | m.def("vectorized_func", py::vectorize(my_func)); |
| | |
| | Invoking the function like below causes 4 calls to be made to ``my_func`` with |
| | each of the array elements. The significant advantage of this compared to |
| | solutions like ``numpy.vectorize()`` is that the loop over the elements runs |
| | entirely on the C++ side and can be crunched down into a tight, optimized loop |
| | by the compiler. The result is returned as a NumPy array of type |
| | ``numpy.dtype.float64``. |
| | |
| | .. code-block:: pycon |
| | |
| | >>> x = np.array([[1, 3],[5, 7]]) |
| | >>> y = np.array([[2, 4],[6, 8]]) |
| | >>> z = 3 |
| | >>> result = vectorized_func(x, y, z) |
| | |
| | The scalar argument ``z`` is transparently replicated 4 times. The input |
| | arrays ``x`` and ``y`` are automatically converted into the right types (they |
| | are of type ``numpy.dtype.int64`` but need to be ``numpy.dtype.int32`` and |
| | ``numpy.dtype.float32``, respectively). |
| | |
| | .. note:: |
| | |
| | Only arithmetic, complex, and POD types passed by value or by ``const &`` |
| | reference are vectorized; all other arguments are passed through as-is. |
| | Functions taking rvalue reference arguments cannot be vectorized. |
| | |
| | In cases where the computation is too complicated to be reduced to |
| | ``vectorize``, it will be necessary to create and access the buffer contents |
| | manually. The following snippet contains a complete example that shows how this |
| | works (the code is somewhat contrived, since it could have been done more |
| | simply using ``vectorize``). |
| | |
| | .. code-block:: cpp |
| | |
| | #include <pybind11/pybind11.h> |
| | #include <pybind11/numpy.h> |
| | |
| | namespace py = pybind11; |
| | |
| | py::array_t<double> add_arrays(py::array_t<double> input1, py::array_t<double> input2) { |
| | py::buffer_info buf1 = input1.request(), buf2 = input2.request(); |
| | |
| | if (buf1.ndim != 1 || buf2.ndim != 1) |
| | throw std::runtime_error("Number of dimensions must be one"); |
| | |
| | if (buf1.size != buf2.size) |
| | throw std::runtime_error("Input shapes must match"); |
| | |
| | /* No pointer is passed, so NumPy will allocate the buffer */ |
| | auto result = py::array_t<double>(buf1.size); |
| | |
| | py::buffer_info buf3 = result.request(); |
| | |
| | double *ptr1 = (double *) buf1.ptr, |
| | *ptr2 = (double *) buf2.ptr, |
| | *ptr3 = (double *) buf3.ptr; |
| | |
| | for (size_t idx = 0; idx < buf1.shape[0]; idx++) |
| | ptr3[idx] = ptr1[idx] + ptr2[idx]; |
| | |
| | return result; |
| | } |
| | |
| | PYBIND11_MODULE(test, m) { |
| | m.def("add_arrays", &add_arrays, "Add two NumPy arrays"); |
| | } |
| | |
| | .. seealso:: |
| | |
| | The file :file:`tests/test_numpy_vectorize.cpp` contains a complete |
| | example that demonstrates using :func:`vectorize` in more detail. |
| | |
| | Direct access |
| | ============= |
| | |
| | For performance reasons, particularly when dealing with very large arrays, it |
| | is often desirable to directly access array elements without internal checking |
| | of dimensions and bounds on every access when indices are known to be already |
| | valid. To avoid such checks, the ``array`` class and ``array_t<T>`` template |
| | class offer an unchecked proxy object that can be used for this unchecked |
| | access through the ``unchecked<N>`` and ``mutable_unchecked<N>`` methods, |
| | where ``N`` gives the required dimensionality of the array: |
| | |
| | .. code-block:: cpp |
| | |
| | m.def("sum_3d", [](py::array_t<double> x) { |
| | auto r = x.unchecked<3>(); // x must have ndim = 3; can be non-writeable |
| | double sum = 0; |
| | for (ssize_t i = 0; i < r.shape(0); i++) |
| | for (ssize_t j = 0; j < r.shape(1); j++) |
| | for (ssize_t k = 0; k < r.shape(2); k++) |
| | sum += r(i, j, k); |
| | return sum; |
| | }); |
| | m.def("increment_3d", [](py::array_t<double> x) { |
| | auto r = x.mutable_unchecked<3>(); // Will throw if ndim != 3 or flags.writeable is false |
| | for (ssize_t i = 0; i < r.shape(0); i++) |
| | for (ssize_t j = 0; j < r.shape(1); j++) |
| | for (ssize_t k = 0; k < r.shape(2); k++) |
| | r(i, j, k) += 1.0; |
| | }, py::arg().noconvert()); |
| | |
| | To obtain the proxy from an ``array`` object, you must specify both the data |
| | type and number of dimensions as template arguments, such as ``auto r = |
| | myarray.mutable_unchecked<float, 2>()``. |
| | |
| | If the number of dimensions is not known at compile time, you can omit the |
| | dimensions template parameter (i.e. calling ``arr_t.unchecked()`` or |
| | ``arr.unchecked<T>()``. This will give you a proxy object that works in the |
| | same way, but results in less optimizable code and thus a small efficiency |
| | loss in tight loops. |
| | |
| | Note that the returned proxy object directly references the array's data, and |
| | only reads its shape, strides, and writeable flag when constructed. You must |
| | take care to ensure that the referenced array is not destroyed or reshaped for |
| | the duration of the returned object, typically by limiting the scope of the |
| | returned instance. |
| |
|
| | The returned proxy object supports some of the same methods as ``py::array`` so |
| | that it can be used as a drop-in replacement for some existing, index-checked |
| | uses of ``py::array``: |
| |
|
| | - ``r.ndim()`` returns the number of dimensions |
| |
|
| | - ``r.data(1, 2, ...)`` and ``r.mutable_data(1, 2, ...)``` returns a pointer to |
| | the ``const T`` or ``T`` data, respectively, at the given indices. The |
| | latter is only available to proxies obtained via ``a.mutable_unchecked()``. |
| | |
| | - ``itemsize()`` returns the size of an item in bytes, i.e. ``sizeof(T)``. |
| | |
| | - ``ndim()`` returns the number of dimensions. |
| | |
| | - ``shape(n)`` returns the size of dimension ``n`` |
| | |
| | - ``size()`` returns the total number of elements (i.e. the product of the shapes). |
| | |
| | - ``nbytes()`` returns the number of bytes used by the referenced elements |
| | (i.e. ``itemsize()`` times ``size()``). |
| | |
| | .. seealso:: |
| | |
| | The file :file:`tests/test_numpy_array.cpp` contains additional examples |
| | demonstrating the use of this feature. |
| | |
| | Ellipsis |
| | ======== |
| | |
| | Python 3 provides a convenient ``...`` ellipsis notation that is often used to |
| | slice multidimensional arrays. For instance, the following snippet extracts the |
| | middle dimensions of a tensor with the first and last index set to zero. |
| | In Python 2, the syntactic sugar ``...`` is not available, but the singleton |
| | ``Ellipsis`` (of type ``ellipsis``) can still be used directly. |
| | |
| | .. code-block:: python |
| | |
| | a = # a NumPy array |
| | b = a[0, ..., 0] |
| | |
| | The function ``py::ellipsis()`` function can be used to perform the same |
| | operation on the C++ side: |
| | |
| | .. code-block:: cpp |
| | |
| | py::array a = /* A NumPy array */; |
| | py::array b = a[py::make_tuple(0, py::ellipsis(), 0)]; |
| | |
| | .. versionchanged:: 2.6 |
| | ``py::ellipsis()`` is now also avaliable in Python 2. |
| | |
| | Memory view |
| | =========== |
| | |
| | For a case when we simply want to provide a direct accessor to C/C++ buffer |
| | without a concrete class object, we can return a ``memoryview`` object. Suppose |
| | we wish to expose a ``memoryview`` for 2x4 uint8_t array, we can do the |
| | following: |
| | |
| | .. code-block:: cpp |
| | |
| | const uint8_t buffer[] = { |
| | 0, 1, 2, 3, |
| | 4, 5, 6, 7 |
| | }; |
| | m.def("get_memoryview2d", []() { |
| | return py::memoryview::from_buffer( |
| | buffer, // buffer pointer |
| | { 2, 4 }, // shape (rows, cols) |
| | { sizeof(uint8_t) * 4, sizeof(uint8_t) } // strides in bytes |
| | ); |
| | }) |
| | |
| | This approach is meant for providing a ``memoryview`` for a C/C++ buffer not |
| | managed by Python. The user is responsible for managing the lifetime of the |
| | buffer. Using a ``memoryview`` created in this way after deleting the buffer in |
| | C++ side results in undefined behavior. |
| | |
| | We can also use ``memoryview::from_memory`` for a simple 1D contiguous buffer: |
| | |
| | .. code-block:: cpp |
| | |
| | m.def("get_memoryview1d", []() { |
| | return py::memoryview::from_memory( |
| | buffer, // buffer pointer |
| | sizeof(uint8_t) * 8 // buffer size |
| | ); |
| | }) |
| | |
| | .. note:: |
| | |
| | ``memoryview::from_memory`` is not available in Python 2. |
| | |
| | .. versionchanged:: 2.6 |
| | ``memoryview::from_memory`` added. |
| | |