Previous topic

Next topic

This Page

Quick search

One objective of Numba is having a seamless integration with NumPy.
NumPy arrays provide an efficient storage method for homogeneous sets of
data. NumPy dtypes provide type information useful when compiling, and
the regular, structured storage of potentially large amounts of data
in memory provides an ideal memory layout for code generation. Numba
excels at generating code that executes on top of NumPy arrays.

NumPy support in Numba comes in many forms:

Numba understands calls to NumPy ufuncs and is able to generate
equivalent native code for many of them.

NumPy arrays are directly supported in Numba. Access to Numpy arrays
is very efficient, as indexing is lowered to direct memory accesses
when possible.

Numba is able to generate ufuncs and gufuncs. This means that it
is possible to implement ufuncs and gufuncs within Python, getting
speeds comparable to that of ufuncs/gufuncs implemented in C extension
modules using the NumPy C API.

The following sections focus on the Numpy features supported in
nopython mode, unless otherwise stated.

Arrays support normal iteration. Full basic indexing and slicing is
supported. A subset of advanced indexing is also supported: only one
advanced index is allowed, and it has to be a one-dimensional array
(it can be combined with an arbitrary number of basic indices as well).

Numpy supports these attributes regardless of the dtype but Numba chooses to
limit their support to avoid potential user error. For numeric dtypes,
Numba follows Numpy’s behavior. The real attribute
returns a view of the real part of the complex array and it behaves as an identity
function for other numeric dtypes. The imag attribute
returns a view of the imaginary part of the complex array and it returns a zero
array with the same shape and dtype for other numeric dtypes. For non-numeric
dtypes, including all structured/record dtypes, using these attributes will
result in a compile-time (TypingError) error. This behavior differs from
Numpy’s but it is chosen to avoid the potential confusion with field names that
overlap these attributes.

Numba supports top-level functions from the
numpy.random
module, but does not allow you to create individual RandomState instances.
The same algorithms are used as for the standard
random module (and therefore the same notes apply),
but with an independent internal state: seeding or drawing numbers from
one generator won’t affect the other.

Also, under Unix, if creating a child process using os.fork() or the
multiprocessing module, the child’s random generator will inherit
the parent’s state and will therefore produce the same sequence of
numbers (except when using the “forkserver” start method under Python 3.4
and later).

One objective of Numba is having all the
standard ufuncs in NumPy
understood by Numba. When a supported ufunc is found when compiling a
function, Numba maps the ufunc to equivalent native code. This allows the
use of those ufuncs in Numba code that gets compiled in nopython mode.

Right now, only a selection of the standard ufuncs work in nopython mode.
Following is a list of the different standard ufuncs that Numba is aware of,
sorted in the same way as in the NumPy documentation.