This change adds some new macro rules used when converting from floats
to integers. There are two macro rule variants, one for signed ints, one
for unsigned ints.
Among other things, this change specifically addresses the overflow case
documented in https://github.com/rust-num/num-traits/issues/12
41: Various improvements to FloatCore r=vks a=cuviper
- New macros simplify forwarding method implementations.
- `Float` and `Real` use this to compact their implementations.
- `FloatCore` now forwards `std` implementations when possible.
- `FloatCore` now requires `NumCast`, like `Float does.
- New additions to `FloatCore`:
- Constants like `min_value()` -> `f64::MIN`
- Rounding methods `floor`, `ceil`, `round`, `trunc`, `fract`
- `integer_decode` matching `Float`'s
- Fix NAN sign handling in `FloatCore` (rust-num/num#312, rust-lang/rust#42425)
- Fix overflow in `FloatCore::powi` exponent negation.
- Add doctests to all `FloatCore` methods.
37: Add Inv and Pow traits. r=cuviper a=clarcharr
This is not a breaking change, and closes#34 and #38.
This doesn't add any impls for the other `num` crates, just floats with `std` enabled. The trait has to be added before those other crates can be updated.
32: Implement CoreFloat trait r=cuviper a=vks
This is a subset of the `Float` trait, but works with `no_std`.
Some code was simplified by using `CoreFloat`.
30: Re-introduce the std feature r=vks a=cuviper
This is a port of @vks's rust-num/num#296, but without the feature-toggled changes to `Float`. Now `Float` and the newer `Real` are completely dependent on having `std` enabled. In the future we can consider adding separate more-limited float/real traits that can work without `std`, like the `BaseFloat` that was originally proposed in the former PR.
This is a breaking change with a bump to 0.2, since anyone currently using `default-features = false` will lose functionality. The actual API is otherwise unchanged, so my plan is to employ the "semver trick" -- publishing a new num-traits-0.1 that re-exports everything from 0.2 (with `std`). Thus all `num-traits` users should remain compatible even if they mix 0.1 and 0.2.
Closes#16.
We don't have implementations for many of the methods in `no_std`. It's
hostile to external implementors if some trait methods are conditional
on a feature, as that feature could be added by anyone in a dependency
tree. Instead, let's just live without these traits for now.
Dan Barella
bors[bot]
Josh Stone
Clar Charr
Vinzent Steinberg
Toshiki Teramura