The suffix is intended to communicate that these methods
assume `preallocated` storage, i.e. they try to store the
result in a matrix which already has the correct sparsity
pattern for the operation.
The CSC matrix API mirrors the CSR matrix API. However, there
are subtle differences throughout (both in the available
methods and the implementation) that I believe makes any attempt
to avoid the duplicate effort futile.
This mimics how std does it, e.g. std::vec::Vec. This avoids potential
problems down the road, where adding more types might clutter the
API interface and generated documentation.
SparsityPattern's constructor now returns a fine-grained error
enum that enumerates possible errors. We use this to build a more
user-friendly error when constructing CSR matrices.
We also overhauled the main SparseFormatError error type by
making it a struct containing a *Kind type and an underlying error
that contains the message.
We can easily create the CSR and CSC constructors by using the
SparsityPattern constructors. However, one lingering problem
is giving meaningful error messages. When forwarding error messages
from the SparsityPattern constructor, the error messages must
be written in terms of "major" or "minor" dimensions, and using
general terms like "lanes", instead of "rows" and "columns".
When forwarding these messages up to CSR or CSC constructors,
they are not directly meaningful to an end user. We should find
a better solution to this problem, so that end users get
more meaningful messages.
The previous test claimed to verify that all possible outputs
are sampled, but it didn't. This commits fixes this issue
by actually computing all possible combinations.
However, to accomplish this we needed to add itertools as a test
dependency. Otherwise we'd have to implement our own way of
generating the Cartesian product of an arbitrary number
of sets.
This introduces functionality for creating strategies for matrices and
vectors, as well as an implementation of Arbitrary.
Strategies for the geometric types (Point3, Quaternion etc.) are not
currently part of this contribution.
The current strategy implementation for matrices has some limitations
that lead to suboptimal shrinking behavior. This is documented in the
module-level docs, with some additional comments in the code.
Andreas Longva
Sébastien Crozet