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
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`.
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.
Also update to use https instead of http. This avois mixed content
degradation on docs.rs.
The doc root URLs are correct as they are, the URL does not include the
crate name itself.
Rust 1.4 through 1.7 will issue warnings that `pub extern crate` does
not work as expected, although it appears to be fine. But Rust 1.8 and
later issue `#[warn(private_in_public)]` for `pub use num_foo as foo` if
that crate isn't public, and that's headed toward a hard error.
@bluss suggested instead `pub mod foo { pub use num_foo::*; }`, which
I thought I had tried before, but it appears to work fine on all
versions of Rust. Let's do it!
A small downside is that docs for `num::foo` now just show the wildcard
reexport, instead of direct documentation, but at least there's a link
to follow to the sub-crate.
It's a breaking change that `num::num_foo` paths are no longer public,
but we didn't really want those exposed in the first place. I consider
this minor -- people should either use the `num::foo` module as before
the split-up, or use the `num_foo` crate directly.
Fixes#189.
Serde 0.7 dropped it's dependency on num, so this patch moves
the implementations here. For the sake of a better implementation,
this just serializes BigUint as a `Vec<u32>`, `BigInt` as a
`(u8, Vec<u32>)`, `Complex<T>` as a `(T, T)`, and `Ratio<T>`
as a `(T, T)`.
- Integer only needs to require Ord explicitly, and then PartialOrd, Eq,
and PartialEq come transitively.
- Generics on Integer can implicitly use all of those comparison traits.
This should not be a breaking change, as it doesn't actually change any
effective trait requirements -- only what's explicit for simplicity.
Previously, the `rand` and `rustc-serialize` dependencies were optional
except they were required for the `bigint` feature.
Make the dependency on the `rand` crate optional in all cases.
including when the `bigint` feature is selected. Some of the tests for
the bigint feature are randomized so, while `rand` is now an optional
dependency, it is a non-optional dev-dependency.
Similarly, make the dependency on the `rustc-serialize` crate optional
in all cases, including when the `bigint` feature is selected.
We can save a multiplication if we start the accumulation basically at
the first set bit of the exponent, rather than starting at one and
waiting to multiply. We only need one itself if the exponent is zero,
which is easy to pre-check.
Before:
test pow_bench ... bench: 8,267,370 ns/iter (+/- 93,319)
After:
test pow_bench ... bench: 7,506,463 ns/iter (+/- 116,311)
The default implementations of to_f32, to_f64, from_32 and from_f64 are
limited to numbers fitting in i64 but BigInt can of course be much bigger.
The default to_f32 also has double rounding.
from_f32 and from_f64 have undefined behaviour if the float is too big to
fit in an i64.
This fixes these issues and keeps the rounding consistant with other float
to int conversions.
Also add ToBigUint and ToBigInt implementations for f32 and f64.
The hidden "mod test" layout of the first example has been broken for a
while, but it wasn't noticed because rustdoc wasn't passing any features
at all. That was fixed in rust-lang/rust#30372, and now we need to get
our ducks in a row too.
bigint: simplify Hash
There cannot be any leading zeros in a BigUint so just derive Hash which will just hash the Vec directly.
Add Hash to Sign so we can derive it for BigInt as well.
There cannot be any leading zeros in a BigUint so just derive Hash which will just hash the Vec directly.
Add Hash to Sign so we can derive it for BigInt as well.
The main idea here is to do as much as possible with slices, instead of
allocating new BigUints (= heap allocations).
Current performance:
multiply_0: 10,507 ns/iter (+/- 987)
multiply_1: 2,788,734 ns/iter (+/- 100,079)
multiply_2: 69,923,515 ns/iter (+/- 4,550,902)
After this patch, we get:
multiply_0: 364 ns/iter (+/- 62)
multiply_1: 34,085 ns/iter (+/- 1,179)
multiply_2: 3,753,883 ns/iter (+/- 46,876)
Since the Num constraint only requires val-val ops, we ended up cloning
everything in Complex ops when they were forwarded to ref-ref. By using
val-val, we can reduce how often clones are needed.
Implement arithmetic with real for complex
Hello,
It might be handy to be able to perform basic arithmetic operations in expressions mixing complex numbers and numeric primitives; see #116. I would be grateful for any feedback, especially regarding the subsets of primitives for which certain operations are implemented.
Regards,
Ivan
- Use explicit asserts for should-panic tests, since overflow is not
checked in release mode.
- Add positive tests where gcd min_value() can be represented.
- In all cases, test min_value() in both positions.
Closes#127
Removing extra parentheses in a for loop fixes this warning:
src/bigint.rs:1636:18: 1636:31 warning: unnecessary parentheses around `for` head expression, #[warn(unused_parens)] on by default
Making bignum optional allows skipping the rustc-serialize and rand
dependencies too, and it makes a big difference in num's build time.
With default (all) features, clean build time including dependencies: 27
seconds.
With no default features, clean build time including dependencies (none):
5 seconds.
Dan Barella
Josh Stone
Clar Charr
bors[bot]
Vinzent Steinberg
Yoan Lecoq
Eduardo Pinho
Fabian Schuiki
svartalf
Jacob Kiesel
bluss
Łukasz Jan Niemier
Murarth
Erick Tryzelaar
Mike MacDonald (crazymykl)
Felix S. Klock II
est31
Oliver Middleton
Colin Davidson
Alex Burka
Homu
Brian Smith
Kent Overstreet
Abhishek Chanda
Ivan Ukhov
David Ripton
William Rieger
Emerentius
Gustorn
Alex Crichton
root
Oliver Mader