311: rational: make sure Hash agrees with Eq r=cuviper
We can't use a derived `Hash` when we have a manual `Eq`, because we
need to uphold the invariant `a == b` → `h(a) == h(b)`. Since `Eq`
doesn't require them to be in reduced form, `Hash` also needs to be
normalized.
Fixes#310.
315: Fix float NaN positive/negative assumptions r=cuviper
These are the minimal assumptions to make about `NaN`. Fixes part of #312 (but not the `next` branch).
We can't use a derived `Hash` when we have a manual `Eq`, because we
need to uphold the invariant `a == b` → `h(a) == h(b)`. Since `Eq`
doesn't require them to be in reduced form, `Hash` also needs to be
normalized.
- rename `_twos_complement_` methods to just `_signed_`
- make `from_` variants take &[u8]
- refactor helper functions twos_complement (they take byte slice but use a generic function underneath)
- fix issues in `to_signed_` functions (only two's complement negative numbers; perform byte extension where needed)
- add tests to `to_signed_` methods
Revert "Auto merge of #296 - vks:no_std, r=cuviper"
This reverts commit 8b5d4ac24e, reversing
changes made to ef752e4687.
See #297 -- it's a breaking change to feature-gate existing APIs.
Test and fix subcrates with --no-default-features
- The CI script now tests them all with --no-default-features.
- bigint: testing needs rand even when the main feature is disabled.
- rational: gate `FromPrimitive for Ratio<BigInt>` on having bigint.
- The CI script now tests them all with --no-default-features.
- bigint: testing needs rand even when the main feature is disabled.
- rational: gate `FromPrimitive for Ratio<BigInt>` on having bigint.
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.
bors[bot]
Lee Bousfield
Josh Stone
Eduardo Pinho
Phaiax
Homu
Björn Steinbrink
Vinzent Steinberg