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.
23: Add RealNum trait for real data types (Float, but without floating-point specific features) r=cuviper a=yoanlcq
This is supposed to fix [#19](https://github.com/rust-num/num-traits/issues/19); I assumed going ahead would be better than bumping the thread.
In any case, I understand that it is a quite significant addition and won't mind too much if it doesn't make it.
This adds a new `RealNum` trait, along with a universal impl `impl<T: Float> RealNum for T { ... }`.
Therefore, this shouldn't be a breaking change, except in places where both traits are imported (which obviously only happened in a few places in this crate).
The intent is that generic code may prefer to use `RealNum` instead of `Float` when floating-point isn't a requirement. In the future (next major version ?), I guess `Float` could be made to only provide floating-point-specific features on top of `RealNum`.
Most of the code+doc was copy-pasted from `Float`, but the doc comments should be up-to-date with the situation; `Float` only makes an appearance when talking about NaN and infinity.
Issues I've seen :
- `RealNum` might not be the name we want;
- I've mentioned that `sqrt()` is allowed to panic if the input is negative and has no meaningful NaN representation;
- Should we do that too for e.g `log()` ? Like `sqrt()`, it's supposed to return Nan when `x < 0`.
Thanks for your time. :)
17: Add AsPrimitive trait for generic casting with `as` r=cuviper a=Enet4
This is my personal attempt at #7. It is fairly similar to what can be found in `asprim`, although implemented from scratch. Please let me know of what you think. Could it use more tests? Should I also leave a safety notice that some conversions with `as` are currently UB (rust-lang/rust#10184)?
21: Add checked shifts r=cuviper a=fabianschuiki
Add traits `CheckedShl` and `CheckedShr` that correspond to the standard
library's `checked_shl` and `checked_shr` functions. Implement the trait
on all primitive integer types by default, akin to what the standard
library does.
The stdlib is somewhat inconsistent when it comes to the type of the
shift amount. The `checked_*` functions have a `u32` shift amount, but
the `std::ops::{Shl,Shr}` traits are generic over the shift amount. Also
the stdlib implements these traits for all primitive integer types as
right-hand sides. Our implementation mimics this behaviour.
Josh Stone
bors[bot]
Clar Charr
Vinzent Steinberg
Toshiki Teramura
Yoan Lecoq