If you're trying to do scientific computing in Rust, and you can't get used
to mathematical functions like
cos() being postfix methods,
this crate may be for you!
It provides free function versions of the trait methods of the
so that you can easily do things like
sin(x) + 3*ln(y).
Each trait's methods are exposed as an module of free functions, named after a snake_case version of the trait's name, and it only takes a couple of use clauses to go from there to using the above syntax in your math expressions.
This crate generally opts for maximal coverage of the num traits, except in the following circumstances:
- The trait represents an operator whose standard notation is closer to a
postfix method than to a prefix function, as is the case for most binary
operators. For this reason,
Wrapping(Add|Mul|Shl|Shr|Sub)are not covered.
- The num_trait crate already provides a set of free functions that cover
90% of a trait's functionality, and we re-export them. Thus,
Zeroare not covered.
- A specific trait or its methods would require very significant supporting
infrastructure to be exposed as a free function by this crate, and the
extent of its real-world usage does not seem to justify the effort.
To be more specific...
FloatConst::TAU()would require adding Self trait bound support to the underlying macro infrastructure, while
TAUis arguably a math expert joke that most normal persons would spell out as
2.0 * PI.
MulAddAssignwould require adding generic trait support to the underlying macro infrastructure, while it is debatable whether a multiply-add should be considered a prefix or postfix operator.
NumCastwould require adding generic trait method support, when it is dubious whether
from::<T, _>(n)is actually a readability improvement over the
T::from(n)that it replaces.
i128-based casts would require extending this crate's conditional compilation setup quite a bit through use of the
autocfgcrate, which seems to be a bit much considering how obscure that type is.
If you find a num trait functionality which is neither exposed by this crate nor covered by the above list, this is likely an oversight from my part, please ping me about it.
I am also willing to reconsider any point of the above policy if someone manages to make a good argument against it. Issues are welcome!
Only a one-line summary of each method's documentation is provided. Please
refer to the corresponding trait method's documentation in
the full details of each function's API contract.
One advantage of using a trait-based approach like
num_traits instead of
free functions like this crate is that trait methods gracefully handle
With this crate, you will instead be the one responsible for only
one function with a given name at a time.
For what it's worth, this is why programming languages with prefix numerical methods usually also support method overloading. But Rust could not have that language feature, as it would break the kind of advanced type inference that all Rustaceans are used to enjoy today...
Methods from the Bounded trait, exposed as free functions.
Methods from the CheckedNeg trait, exposed as free functions
Methods from the Float trait, exposed as free functions.
Methods from the FloatConst trait, exposed as free functions.
Methods from the FloatCore trait, exposed as free functions.
Methodes from the FromPrimitive trait, exposed as free functions.
Methods from the Inv trait, exposed as free functions
Methods from the Num trait, exposed as free functions
Methods from the PrimInt trait, exposed as free functions.
Methods from the Real trait, exposed as free functions.
Methodes from the ToPrimitive trait, exposed as free functions.
Methods from the WrappingNeg trait, exposed as free functions