traits: Introduce std feature
This makes it possible to build `traits` without `std`. For this a new
trait `BasicFloat` was introduced, implementing some basic functionality
that works with `core`. Most notably this is lacking functions like
`cos`, `sin`, etc.
`Float` is not available without `std`.
Refs #216.
This makes it possible to build `traits` without `std`. For this a new
trait `BasicFloat` was introduced, implementing some basic functionality
that works with `core`. Most notably this is lacking functions like
`cos`, `sin`, etc.
`Float` is not available without `std`.
Refs #216.
Get the default hasher indirectly
`DefaultHasher` wasn't stable until 1.13, at which point all the other
hashers were deprecated, so it's not easy for us to name a hasher type to
use for testing. However, `RandomState` has been stable since 1.7, and it
implements `BuildHasher` that has a `Hasher` associated type.
(extends #287)
`DefaultHasher` wasn't stable until 1.13, at which point all the other
hashers were deprecated, so it's not easy for us to name a hasher type
to use for testing. However, `RandomState` has been stable since 1.7,
and it implements `BuildHasher` that has a `Hasher` associated type.
Add new traits for reference and assignment operators
There are two new "utility" traits covering the basic operators:
`Add`, `Sub`, `Mul`, `Div`, and `Rem`.
- `NumOps<Rhs, Output>`: operators with an arbitrary operand and output.
- `NumAssignOps<Rhs>`: assignment operators with an arbitrary operand.
Then the new collection of numeric traits are:
- `Num`: effectively unchanged, just taking operands by value.
- `NumRef`: `Num` adding reference operands on the right side.
- `RefNum`: `&T` operators, with either `T` or `&T` on the right side.
- This does not specify `T: Num`, as rust-lang/rust#20671 means that
could only add a constraint, without implying its presence for use.
- `NumAssign`: `Num` adding assignment operators by value.
- `NumAssignRef`: `NumAssign` adding reference assignment operators.
- Nothing actually implements this yet!
Acknowledgement: this is roughly based on [@andersk's suggestion](https://github.com/rust-num/num/issues/94#issuecomment-269073071).
There are two new "utility" traits covering the basic operators:
`Add`, `Sub`, `Mul`, `Div`, and `Rem`.
- `NumOps<Rhs, Output>`: operators with an arbitrary operand and output.
- `NumAssignOps<Rhs>`: assignment operators with an arbitrary operand.
Then the new collection of numeric traits are:
- `Num`: effectively unchanged, just taking operands by value.
- `NumRef`: `Num` adding reference operands on the right side.
- `RefNum`: `&T` operators, with either `T` or `&T` on the right side.
- This does not specify `T: Num`, as rust-lang/rust#20671 means that
could only add a constraint, without implying its presence for use.
- `NumAssign`: `Num` adding assignment operators by value.
- `NumAssignRef`: `NumAssign` adding reference assignment operators.
- Nothing actually implements this yet!
Acknowledgement: this is roughly based on [@andersk's suggestion][1].
[1] https://github.com/rust-num/num/issues/94#issuecomment-269073071
impl remaining num-traits for std::num::Wrapping<T>
This is a (late) follow-up for [https://github.com/rust-num/num/pull/279](https://github.com/rust-num/num/pull/279) since I realized that implementing `Num` for `Wrapping<T>` was merely half of the work.
This PR makes `Wrapping<T>` implement the remaining appropriate traits, granting it the ability to really be used a complete substitute for its primitive integer counterparts.
Some benefits are :
- Less refactoring for users using `num`'s traits replacing some primitives by their `Wrapping` counterpart (same for the opposite);
- Since `Wrapping<T>` is from `std`, nobody except us can `impl` our traits for it, so people don't have to create their own.
rational: Implement approximation from floats and FromPrimitive for v…
…arious types
FromPrimitive is implemented for i8/16/32/64 and BigInt.
https://github.com/rust-num/num/issues/282
Complex: Use repr(C) and add documentation for what it means
Here's an ambitious proposal that puts currently practiced ffi usage of `Complex<f32/f64>` on sound footing.
Fixes #79
Current users appear to be:
- https://crates.io/crates/blas
+ Their use is not about Complex<f64> in an extern function's signature, but it is explicitly using that it is memory layout compatible.
Implement an iterator over the binomial coefficients
I'm not very happy with the excessive cloning, but to fix it the bounds on the type parameters would have to be excessive. We probably need something like [this](https://github.com/vks/discrete-log/blob/master/src/main.rs#L90) in `num-traits`.
Homu
Vinzent Steinberg
Josh Stone
king6cong
Sebastian Dröge
Yoan Lecoq
Patrick Jackson
bluss