dimforge / dimforge/alga

RealField/ComplexField traits

Open
#71 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
201
Forks
40
PR merge metrics
No merged PRs in 30d

Description

Thank you all so much for adding in complex support! It makes my project 100x easier now that I can use existing matrix functions with complex numbers. I have just a few lingering concerns about the traits.

First of all, would it be possible to remove the `Bounded` requirement of `RealField`? Although this would be a breaking change, it would allow using arbitrary-size numbers or rationals, as long as they implement `Copy`. I understand the argument that they should probably implement `Clone` instead, but on the other hand, I seriously doubt that many functions rely on `Bounded`, and that could be added as a generic requirement for those limited cases. Furthermore, using `Bounded` does not really make much sense for floating point numbers anyway since it is almost always impractical that any number should ever come even close to the maximum possible float (since they store an **exponent** and significand rather than a binary number like `u8`; [`f64::MAX` > 10308](https://doc.rust-lang.org/stable/src/core/num/f64.rs.html#38)).

Second, is the `'static` requirement for `ComplexField` really necessary? Yes, I know that removing this would be very breaking, and make things a bit more difficult to write, but I IMHO at least _eventually_ it is a necessary step in order to write any performant code using `alga` in order to avoid memory leaks. Same goes for `Send`, `Sync`, `Any`, and `Debug`/`Display`. As is the case for `Bounded`, I think it would make more sense for rarely-used requirements like these to be specified for individual functions and to only require the real necessities like arithmetic as a requirement for all `ComplexField` and thereby `RealField` numbers.

Third, one more breaking change: would it be possible to _eventually_ refactor the requirements for trigonometric/hyperbolic/exponential/logarithmic, etc. functions into requirements for the corresponding traits in `num_traits`? This would make implementing those functions easier. Or better yet, at least for `RealField`, would it be possible to remove those requirements except for the functions that use them?

---

Overall, the most important request I have is removing `'static`. Everything else is just a suggestion/proposal, but IMHO removing `'static` is essential for proper memory management even if it makes generics a bit more difficult.

Thank you again, and please note that everything here is just ideas for consideration and not feature requests. I understand if not everything here would make sense to implement.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.