It's possible that some particularly bad inputs cause
severe loss of significance in the triangular solves.
This is exacerbated by the fact that the way we test
the (residual) error is also prone to loss of significance,
so that the error measure itself is problematic.
We could maybe improve this in the future by using arbitrary-
precision arithmetic to remove some sources of error and testing
against appropriate bounds.
Due to a bug in proptest, we were required to pull in and modify
parts of proptest::strategy::Shuffle. Once the below PR has been merged
and released on crates.io, we can remove this code.
https://github.com/AltSysrq/proptest/pull/217
After much deliberation, I have come to the conclusion that the
benefits do not really outweigh the added complexity. Even though
the added complexity is relatively minor, it makes it somewhat
more complicated to inter-op with other sparse linear algebra
libraries in the future.
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.
Andreas Longva