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.
Josh Stone
Homu
Vinzent Steinberg
king6cong
Sebastian Dröge
Yoan Lecoq
Patrick Jackson