Make trait bounds for sparse arithmetic operations more deliberate
- Dominant language
- Rust
- Stars
- 4.8k
- Forks
- 565
- PR merge metrics
- No merged PRs in 30d
Description
Currently, the necessary trait bounds for methods in `nalgebra_sparse::ops` and implementations of e.g. `Add, Mul` and so on are somewhat arbitrary. The issue here is that we'd like to be able to use generalized operations from `nalgebra_sparse::ops` in the `Add/Mul` etc. operations, so that optimization efforts can be focused on the free-standing functions. However, by necessity, these functions need both `Add, Sub` and so on, which means that `Add(Csr, Csr)` needs `T: Sub`.
Trait bounds are not only about what operations are needed right now, but due to forward compatibility concerns, we also need to take into account what we might need in the future. Therefore I propose to simplify trait bounds by introducing a trait, perhaps called `Number`, which is intended to encompass integers and floating-point numbers. `Number` would corresponds to typical arithmetic operations, such as addition, multiplication, subtraction and division. However, it does *not* provide a multiplicative inverse like `RealField`.
We could consider having this trait in `nalgebra` proper and recommend it as a generic trait bound to use whenever you want to abstract over integers and floating-point numbers. This needs more discussion, however.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.