[Numeric] HMatrix priorities
huw.campbell at gmail.com
Wed Jul 8 07:18:05 UTC 2020
I've put a bit of time into hmatrix over the past week. My main
priorities at the moment are fixing bugs, segfaults, memory leaks, and
other infelicities. But after that's done I'm planning on tackling
some broader API and design issues.
I have a few questions:
- Why are CSR and CSC 1 indexed? The early literature uses 0 indexing
AFAICS, and it means that Ben Gamari's libsvd wrapper has to do extra
leg work reindexing before calling its C code.
- Why do we have our own mutable vector type? I would have thought the
the vector package would be sufficient.
- Should we try to move more of the library towards the general matrix
`GMatrix`? At the moment there are not very many functions which
actually use it (and it has partial record labels), and one can't
project out back to any of the underlying matrix forms.
- Can we bring the test suites and benchmarks back into the libraries
proper? The test suite is currently lagging the major version, and on
master doesn't compile with GHC 8.6+ (I have a PR for that).
- CI looks like it's only testing one version of GHC, do we have a
policy on how many versions we support?
- What are all of your priorities? Dominic has mentioned a few use cases around
sparse matrices people have been working on.
We've also spoken about github etiquette. I agreed with Dominic that
branches and pull requests are probably the best approach at the
moment. I won't merge my own PRs without input from another maintainer
at this stage, so please do have a look.
More information about the Numeric