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.
Make the checked left and right shifts take a `u32` as right-hand side,
which is more consistent with the other checked operations. Also drop
`CheckedShl` and `CheckedShr` from the `PrimInt` trait, to not break
existing code. Add doctests for the two traits.
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.
350: Avoid large intermediate product in LCM r=cuviper a=mhogrefe
Changed the implementation of BigUint LCM from
`((self * other) / self.gcd(other))`
to
`self / self.gcd(other) * other`
The division is exact in both cases, so the result is the same, but the new code avoids the potentially-large intermediate product, speeding things up and using less memory.
I also removed the unnecessary parentheses, because I think it's clear what order everything will be executed in. But if others think differently I can add them back.
351: Remove num-macros r=cuviper a=cuviper
The first commit gives a final deprecation bump to `num-macros`, and
the second removes it from the repo altogether.
- Now uses Toom-3 multiplication for large inputs.
- `BigInt`/`BigUint` parsing now accepts `_` separating digits.
- `BigInt`/`BigUint::assign_from_slice` reinitializes the value, keeping
the same internal buffer.
- `BigUint` now implements many `*Assign` ops.
- `BigUint::modpow(exp, mod)` performs efficient modular exponentiation.
`Complex` now implements `Num`, `Rem`, and `RemAssign`.
(Complex remainders don't have a clear mathematical basis, but we choose
to round toward zero to a gaussian integer.)
342: rational: check for NaN when approximating floats r=cuviper a=cuviper
We had a test for NaN already, but thanks to undefined casts (#119) it
was only passing by luck -- on armv7hl it failed:
https://bugzilla.redhat.com/show_bug.cgi?id=1511187
Now we check for NaN explicitly.
Vinzent Steinberg
Josh Stone
bors[bot]
Toshiki Teramura
Yoan Lecoq
Eduardo Pinho
Fabian Schuiki
svartalf
Mikhail Hogrefe