# Maths Traits A simple to use yet abstract system of mathematical traits for the Rust language # Design The purpose of this crate is to provide a system for working with mathematical objects that is both maximally abstract *and* that is easy to use such that working with mathematical generics and high abstraction is nearly as simple as designing around a specific type. This system can be used in cases ranging broadly from something as simple as making reals number algorithms apply seamlessly to different precisions to simplifying vector systems such that using polynomials as coordinates is as easy as switching to a ring module, or even something like separating the different poperties of rings from the Integers so that objects like polynomials can fit into algorithms generally designed for the latter. To accomplish this goal, the provided framework provided is built with a number of design considerations: * For ease of use and implementation, the included systems utilize standard Rust or well established libraries, like [`num_traits`](https://crates.io/crates/num-traits), whenever possible instead of creating new systems. * Implementors should only have to consider individual properties of structures while users should only need to use the single trait for whichever mathematical object has the desired features * The systems have been named and organized to fit mathematical convention as much as possible in order to add clarity of use while also increasing generality and flexibility # Usage The traits in this framework are split into two collections, a set of traits for individual properties and operations and a set of trait aliases for mathematical structures that have those properties. This way, to support the system, structs need only implement each relevant property, and to use the system, one can simply bound generics by the single alias of whatever mathematical structure fits their needs. For example, to create a generalized `Rational` type, you would implement the standard `Clone`, `Add`, `Sub`, `Mul`, `Div`, `Neg`, `Inv`, `Zero`, `One` traits, and their assign variants as normal. Then, by implementing the new traits `AddCommutative`, `AddAssociative`, `MulCommutative`, `MulCommutative`, and `Distributive`, all of the aliases using those operations (such as `Ring` and `MulMonoid`) will automatically be implemented and usable for the type.
```Rust use maths_traits::algebra::*; #[derive(Clone)] //necessary to auto-implement Ring and MulMonoid #[derive(Copy, PartialEq, Eq, Debug)] //for convenience and displaying output pub struct Rational { n: i32, d: i32 } impl Rational { pub fn new(numerator:i32, denominator:i32) -> Self { let gcd = numerator.gcd(denominator); Rational{n: numerator/gcd, d: denominator/gcd} } } //Unary Operations from std::ops and num_traits impl Neg for Rational { type Output = Self; fn neg(self) -> Self { Rational::new(-self.n, self.d) } } impl Inv for Rational { type Output = Self; fn inv(self) -> Self { Rational::new(self.d, self.n) } } //Binary Operations from std::ops impl Add for Rational { type Output = Self; fn add(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d + rhs.n*self.d, self.d*rhs.d) } } impl AddAssign for Rational { fn add_assign(&mut self, rhs:Self) {*self = *self+rhs;} } impl Sub for Rational { type Output = Self; fn sub(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d - rhs.n*self.d, self.d*rhs.d) } } impl SubAssign for Rational { fn sub_assign(&mut self, rhs:Self) {*self = *self-rhs;} } impl Mul for Rational { type Output = Self; fn mul(self, rhs:Self) -> Self { Rational::new(self.n*rhs.n, self.d*rhs.d) } } impl MulAssign for Rational { fn mul_assign(&mut self, rhs:Self) {*self = *self*rhs;} } impl Div for Rational { type Output = Self; fn div(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d, self.d*rhs.n) } } impl DivAssign for Rational { fn div_assign(&mut self, rhs:Self) {*self = *self/rhs;} } //Identities from num_traits impl Zero for Rational { fn zero() -> Self {Rational::new(0,1)} fn is_zero(&self) -> bool {self.n==0} } impl One for Rational { fn one() -> Self {Rational::new(1, 1)} fn is_one(&self) -> bool {self.n==1 && self.d==1} } //algebraic properties from math_traits::algebra impl AddAssociative for Rational {} impl AddCommutative for Rational {} impl MulAssociative for Rational {} impl MulCommutative for Rational {} impl Distributive for Rational {} //Now, Ring and MulMonoid are automatically implemented for us fn mul_add(a:R, b:R, c:R) -> R { a*b + c } use maths_traits::algebra::group_like::repeated_squaring; let half = Rational::new(1, 2); let two_thirds = Rational::new(2, 3); let sixth = Rational::new(1, 6); assert_eq!(mul_add(half, two_thirds, sixth), half); assert_eq!(repeated_squaring(half, 7u32), Rational::new(1, 128)); ```

In addition, with little effort, using a more abstract `Integer` or `GCDDomain` bound we can generalize significantly to be able to have more options for numerators and denominators, including every primitive integer precision, various big-integer types, or even structures like polynomials or functions.

```Rust use maths_traits::algebra::*; //Using a GCDDomain here means we can use more integral types, polynomials, and other types #[derive(Clone, Copy, PartialEq, Eq, Debug)] pub struct Rational { n:T, d:T } impl Rational { pub fn new(numerator:T, denominator:T) -> Self { let gcd = numerator.clone().gcd(denominator.clone()); Rational{n: numerator.divide(gcd.clone()).unwrap(), d: denominator.divide(gcd).unwrap()} } } //Standard operations remain basically the same as for the i32 case impl Neg for Rational { type Output = Self; fn neg(self) -> Self { Rational::new(-self.n, self.d) } } impl Inv for Rational { type Output = Self; fn inv(self) -> Self { Rational::new(self.d, self.n) } } impl Add for Rational { type Output = Self; fn add(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d.clone() + rhs.n*self.d.clone(), self.d*rhs.d) } } impl AddAssign for Rational { fn add_assign(&mut self, rhs:Self) {*self = self.clone()+rhs;} } impl Sub for Rational { type Output = Self; fn sub(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d.clone() - rhs.n*self.d.clone(), self.d*rhs.d) } } impl SubAssign for Rational { fn sub_assign(&mut self, rhs:Self) {*self = self.clone()-rhs;} } impl Mul for Rational { type Output = Self; fn mul(self, rhs:Self) -> Self { Rational::new(self.n*rhs.n, self.d*rhs.d) } } impl MulAssign for Rational { fn mul_assign(&mut self, rhs:Self) {*self = self.clone()*rhs;} } impl Div for Rational { type Output = Self; fn div(self, rhs:Self) -> Self { Rational::new(self.n*rhs.d, self.d*rhs.n) } } impl DivAssign for Rational { fn div_assign(&mut self, rhs:Self) {*self = self.clone()/rhs;} } impl Zero for Rational { fn zero() -> Self {Rational::new(T::zero(),T::one())} fn is_zero(&self) -> bool {self.n.is_zero()} } impl One for Rational { fn one() -> Self {Rational::new(T::one(), T::one())} fn is_one(&self) -> bool {self.n.is_one() && self.d.is_one()} } impl AddAssociative for Rational {} impl AddCommutative for Rational {} impl MulAssociative for Rational {} impl MulCommutative for Rational {} impl Distributive for Rational {} //Now, we can use both 8-bit integers AND 64 bit integers let half = Rational::new(1i8, 2i8); let sixth = Rational::new(1, 6); let two_thirds = Rational::new(2i64, 3i64); let one_third = Rational::new(1i64, 3i64); assert_eq!(half + sixth, Rational::new(2, 3)); assert_eq!(two_thirds + one_third, Rational::new(1, 1)); ```
# Currently Supported Constructs Currently, `maths_traits` supports traits for the following systems of mathematical structures: * Group-Like algebraic structures: monoids, groups, abelian groups, etc * Ring-Like algebraic structures: rings, fields, GCD domains, Euclidean domains, etc * Module-Like structures: vector spaces, algebras, bilinear-forms, etc * Integer and Natural numbers * Ordered algebraic structures: ordered/archimedian rings, fields, etc * Real and Complex numbers * Metric properties of sets: metric spaces, inner-product, norm, etc # `no_std` It is possible to use `maths-traits` without the standard library. To do so, simply compile your project without the `std` feature by disabling default features in your `Cargo.toml`. ```TOML [dependencies] maths-traits = {version = "0.2", default-features = false} ``` However, do note that the implementations of all traits related to `Real` on primitive types will only be available when using `std`, as the floating-point trigonometric and exponential functions are only available when linking to the standard library. # Possible Future Features As `maths_traits` is still in developement, there are a number of features that may be included at a later date: * Traits for vector spaces of finite or countable dimension that have discrete elements. This will *almost certainly* be added eventually, but hasn't yet due to a number of design constraints. * Optional default implementations for the other mathematical strutures in the `num` crate. * A system for category-like structures, ie, sets with an operation that is partial over its elements. This would relatively simple to add, but *so far*, there do not seem to be enough use cases for such a system in order to offset the added code complexity. * Systems for sets, geometric shapes, and set measure. The might be included in the future, but so far, they do not seem to fit within the scope of this project. Of course, if anyone feels that any specific feature be added, feel free to file an issue or contribute at the [github](https://github.com/anvil777/maths-traits) repository. Since most of the non-implemeted features are non-implemented due to usefulness concerns, if a feature is requested (and is reasonable), it will probably be added at some point afterward (though this is not a guarantee). # Release Stability At the moment, this project is still in developement, so do note that it is entirely possible for the API to change in the future. I simply do not feel that the crate has had enough use to warrent a feature freeze of any kind, so I would like to leave that within the realm of possibility. _However_, as it stands currently, a fair portion of subsystems have more-or-less been stable in my own personal use for some time, and I would specifically expect most changes to occur in the module-like, metric, and integer systems, so there should not be a terribly large number of breaking changes in the future. Of course, if an API-breaking change _is_ introduced at any point it will be reflected in the semantic-versioning.