Where do the headers get installed?¶

Its easiest to find this location using this Python code snippet:

from imp import find_module
file, pathname, descr = find_module("pyublas")
from os.path import join
return join(pathname, "..", "include")

Since PyUblas requires numpy, you’ll need a similar snippet for that, too:

from imp import find_module
file, pathname, descr = find_module("numpy")
from os.path import join
return join(pathname, "core", "include")

What about 0-dimensional arrays?¶

0-dimensional arrays are supported by PyUblas, they can be converted to numpy_vector instances of length 1.

My wrapped function is not found by Boost.Python. Help!¶

Even if you heed all the advice in Automatic From-Python Conversion, Boost.Python will sometimes still complain that no valid overload can be found. Common reasons include:

• You expect to be handling a float array, but you actually got an int (or different dtype) array. To be consistent, PyUblas will not copy-and-cast in this situation. If necessary, use numpy.asarray() in your Python code. (I’m debating whether to add C++ syntax to say “copying is ok here”. If you have input, let me know.)
• If converting a matrix, the row/column-major setting may not match what Ublas is expecting. By default, numpy_matrix is row-major, as is numpy.array when creating a 2D array.

The function pyublas.why_not() can help you debug these cases.

Gaah! Why is this garbage so slow?¶

Ok, let’s substantiate this discussion somehwat. I’ve obtained the following numbers using test/strided_speed.py on my 1.7GHz Pentium M. You can run that file yourself for comparison.

PyUblas with Boost.Ublas in its default configuration obtains the following speeds:

test_ublas_speed: 0.023819s
test_unstrided_speed: 0.152608s
test_strided_speed: 0.234522s

All these tests measure a certain number of large in-place vector-scalar multiplications. The assumption is that performance for most other vector-vector operations will be very similar.

test_ublas_speed measures the performance of that operation for boost::numeric::ublas::vector, test_unstrided_speed for numpy_vector, and test_strided_speed for numpy_strided_vector. Now, you’ll say, that’s scary, because, unlike what’s promised here, the unstrided numpy_vector actually is about an order of magnitude slower than native Ublas. This is due to the fact that Ublas uses indexed access for dense vector/matrix operations by default.

This default can be changed, however, by defining BOOST_UBLAS_USE_ITERATING, in which case the timings are pretty much as promised:

test_ublas_speed: 0.031008s
test_unstrided_speed: 0.034083s
test_strided_speed: 0.205794s

If you configure PyUblas with --use-iterators, it will define BOOST_UBLAS_USE_ITERATING while it is being compiled. Note however that you still need to define this macro when compiling your own code.

The final question is, then, why test_strided_speed is still about an order of magnitude slower than the other two. The answer is that Ublas will always use indexing access in boost::numeric::vector_slice, from which numpy_strided_vector is derived.

PyUblas 0.93¶

• Negative strides are supported. Slice handling was cleaned up and should be correct now.
• invalid_ok was added.
• numpy_strided_vector was added as another way of transparently dealing with non-contiguous slices.
• numpy_vector::min_stride() is gone. It was ill-specified and not capable of doing what it promised to do.
• numpy forces every C/C++ module that uses its functionality to call import_array(). PyUblas has a clever mechanism that does this for you. This mechanism was not correct previously, it would often fail when a particular piece of code was not inlined.