Because the code printers treat Indexed objects with repeated indices as a
summation, the above equality instance will be translated to low-level code for
a matrix vector product. This is how you tell SymPy to generate the code,
compile it and wrap it as a python function:

>>> matvec=autowrap(instruction)

That’s it. Now let’s test it with some numpy arrays. The default wrapper
backend is f2py. The wrapper function it provides is set up to accept python
lists, which it will silently convert to numpy arrays. So we can test the
matrix vector product like this:

The autowrap module is implemented with a backend consisting of CodeWrapper
objects. The base class CodeWrapper takes care of details about module
name, filenames and options. It also contains the driver routine, which runs
through all steps in the correct order, and also takes care of setting up and
removing the temporary working directory.

The actual compilation and wrapping is done by external resources, such as the
system installed f2py command. The Cython backend runs a distutils setup script
in a subprocess. Subclasses of CodeWrapper takes care of these
backend-dependent details.

Module for compiling codegen output, and wrap the binary for use in
python.

Note

To use the autowrap module it must first be imported

>>> fromsympy.utilities.autowrapimportautowrap

This module provides a common interface for different external backends, such
as f2py, fwrap, Cython, SWIG(?) etc. (Currently only f2py and Cython are
implemented) The goal is to provide access to compiled binaries of acceptable
performance with a one-button user interface, i.e.

The callable returned from autowrap() is a binary python function, not a
SymPy object. If it is desired to use the compiled function in symbolic
expressions, it is better to use binary_function() which returns a SymPy
Function object. The binary callable is attached as the _imp_ attribute and
invoked when a numerical evaluation is requested with evalf(), or with
lambdify().

The idea is that a SymPy user will primarily be interested in working with
mathematical expressions, and should not have to learn details about wrapping
tools in order to evaluate expressions numerically, even if they are
computationally expensive.

When is this useful?

For computations on large arrays, Python iterations may be too slow,
and depending on the mathematical expression, it may be difficult to
exploit the advanced index operations provided by NumPy.

For really long expressions that will be called repeatedly, the
compiled binary should be significantly faster than SymPy’s .evalf()

If you are generating code with the codegen utility in order to use
it in another project, the automatic python wrappers let you test the
binaries immediately from within SymPy.

To create customized ufuncs for use with numpy arrays.
See ufuncify.

When is this module NOT the best approach?

If you are really concerned about speed or memory optimizations,
you will probably get better results by working directly with the
wrapper tools and the low level code. However, the files generated
by this utility may provide a useful starting point and reference
code. Temporary files will be left intact if you supply the keyword
tempdir=”path/to/files/”.

If the array computation can be handled easily by numpy, and you
don’t need the binaries for another project.

If supplied, (options: ‘C’ or ‘F95’), specifies the language of the
generated code. If None [default], the language is inferred based
upon the specified backend.

backend : string, optional

Backend used to wrap the generated code. Either ‘f2py’ [default],
or ‘cython’.

tempdir : string, optional

Path to directory for temporary files. If this argument is supplied,
the generated code and the wrapper input files are left intact in the
specified path.

args : iterable, optional

An ordered iterable of symbols. Specifies the argument sequence for the
function.

flags : iterable, optional

Additional option flags that will be passed to the backend.

verbose : bool, optional

If True, autowrap will not mute the command line backends. This can be
helpful for debugging.

helpers : iterable, optional

Used to define auxillary expressions needed for the main expr. If the
main expression needs to call a specialized function it should be put
in the helpers iterable. Autowrap will then make sure that the
compiled main expression can link to the helper routine. Items should
be tuples with (<funtion_name>, <sympy_expression>, <arguments>). It
is mandatory to supply an argument sequence to helper routines.

code_gen : CodeGen instance

An instance of a CodeGen subclass. Overrides language.

include_dirs : [string]

A list of directories to search for C/C++ header files (in Unix form
for portability).

library_dirs : [string]

A list of directories to search for C/C++ libraries at link time.

libraries : [string]

A list of library names (not filenames or paths) to link against.

extra_compile_args : [string]

Any extra platform- and compiler-specific information to use when
compiling the source files in ‘sources’. For platforms and compilers
where “command line” makes sense, this is typically a list of
command-line arguments, but for other platforms it could be anything.

extra_link_args : [string]

Any extra platform- and compiler-specific information to use when
linking object files together to create the extension (or to create a
new static Python interpreter). Similar interpretation as for
‘extra_compile_args’.

Generates a binary function that supports broadcasting on numpy arrays.

Parameters:

args : iterable

Either a Symbol or an iterable of symbols. Specifies the argument
sequence for the function.

expr

A SymPy expression that defines the element wise operation.

language : string, optional

If supplied, (options: ‘C’ or ‘F95’), specifies the language of the
generated code. If None [default], the language is inferred based
upon the specified backend.

backend : string, optional

Backend used to wrap the generated code. Either ‘numpy’ [default],
‘cython’, or ‘f2py’.

tempdir : string, optional

Path to directory for temporary files. If this argument is supplied,
the generated code and the wrapper input files are left intact in
the specified path.

flags : iterable, optional

Additional option flags that will be passed to the backend.

verbose : bool, optional

If True, autowrap will not mute the command line backends. This can
be helpful for debugging.

helpers : iterable, optional

Used to define auxillary expressions needed for the main expr. If
the main expression needs to call a specialized function it should
be put in the helpers iterable. Autowrap will then make sure
that the compiled main expression can link to the helper routine.
Items should be tuples with (<funtion_name>, <sympy_expression>,
<arguments>). It is mandatory to supply an argument sequence to
helper routines.

kwargs : dict

These kwargs will be passed to autowrap if the \(f2py\) or \(cython\)
backend is used and ignored if the \(numpy\) backend is used.

For the ‘f2py’ and ‘cython’ backends, inputs are required to be equal length
1-dimensional arrays. The ‘f2py’ backend will perform type conversion, but
the Cython backend will error if the inputs are not of the expected type.

The default backend (‘numpy’) will create actual instances of
numpy.ufunc. These support ndimensional broadcasting, and implicit type
conversion. Use of the other backends will result in a “ufunc-like”
function, which requires equal length 1-dimensional arrays for all
arguments, and will not perform any type conversions.