976 Commits

Author SHA1 Message Date
Manca Bizjak
2b473e9403 Implement optimized sqrt, cbrt methods
This commit overrides default implementations of
Roots::sqrt and Roots::cbrt for BigInt and BigUint
with optimized ones. It also improves tests and
resolves minor inconsistencies.

Signed-off-by: Manca Bizjak <manca.bizjak@xlab.si>
2018-07-13 12:52:40 +02:00
Manca Bizjak
1f2590656b Implement Roots for BigInt and BigUint
This commit implements num-integer::Roots trait
for BigInt and BigUint types, and also adds sqrt,
cbrt, nth_root as inherent methods to allow access
to them without importing Roots trait. For each
type tests were added as submodules in the roots
test module.

Signed-off-by: Manca Bizjak <manca.bizjak@xlab.si>
2018-07-11 12:14:46 +02:00
bors[bot]
86e019bc97 Merge #53
53: switch gen_biguint to fill_bytes r=cuviper a=TheIronBorn

Changes `gen_biguint` from a `push(gen::<u32>)` method to rand's [`fill_bytes`](https://docs.rs/rand/0.5.0/rand/trait.RngCore.html#tymethod.fill_bytes). This should improve performance in most cases.

- For small PRNGs which only natively generate 64 bits (like Xorshift64 or [`splitmix64.c`](http://prng.di.unimi.it/splitmix64.c)), this will no longer throw away half the bits generated. 
- For block PRNGs like `StdRng`, this should reduce overhead.
- For an SIMD PRNG (https://github.com/rust-lang-nursery/rand/issues/377), this would be a significant improvement.

```diff,ignore
 name         no_fill ns/iter  fill ns/iter  diff ns/iter   diff %  speedup 
+rand_1009    256              222                    -34  -13.28%   x 1.15 
+rand_131072  27,366           14,715             -12,651  -46.23%   x 1.86 
+rand_2048    459              357                   -102  -22.22%   x 1.29 
-rand_256     93               130                     37   39.78%   x 0.72 
+rand_4096    842              557                   -285  -33.85%   x 1.51 
-rand_64      69               92                      23   33.33%   x 0.75 
+rand_65536   13,625           7,382               -6,243  -45.82%   x 1.85 
+rand_8192    1,836            869                   -967  -52.67%   x 2.11
```
(i.e. `rand_1009` does `gen_biguint(1009)`. All benches are powers of two except `rand_1009`)

(Let me know if you want the `rand_` benches added)

Co-authored-by: TheIronBorn <>
Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-07-05 23:44:35 +00:00
Josh Stone
8b5a092010 Add tests for PRNG value stability 2018-07-02 11:09:07 -07:00
TheIronBorn
b2c9577f63 rand benches 2018-06-25 18:01:59 -07:00
TheIronBorn
af35fd3035 switch gen_biguint to fill_bytes 2018-06-25 16:09:02 -07:00
Josh Stone
89162481ac Add dates to RELEASES.md 2018-06-21 12:07:31 -07:00
bors[bot]
9309c8b258 Merge #52
52: Make sure benchmarks can be built r=cuviper a=cuviper

This fixes the rand seeds, and builds benches in nightly CI.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-30 20:19:18 +00:00
Josh Stone
40a8e91bd9 Make sure benchmarks can be built
This fixes the rand seeds, and builds benches in nightly CI.
2018-05-30 13:16:45 -07:00
bors[bot]
f87f2e72a0 Merge #50
50: Release 0.2.0 r=cuviper a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-25 20:56:21 +00:00
Josh Stone
de836f6fdc Release 0.2.0 2018-05-25 13:45:38 -07:00
bors[bot]
cf07a88fc3 Merge #49
49: Add a RandomBits distribution r=cuviper a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-25 18:18:30 +00:00
Josh Stone
189331d3b0 release note for RandomBits 2018-05-25 11:18:07 -07:00
Josh Stone
865398adb5 Inline more random helpers 2018-05-23 20:57:29 -07:00
Josh Stone
e679836303 Add a RandomBits distribution 2018-05-23 20:57:29 -07:00
bors[bot]
3a3cb2d574 Merge #48
48: Update to rand 0.5 r=cuviper a=cuviper

This closes #47, choosing to *only* support rand 0.5 (and only for their supported rustc 1.22+).

The `RandBigInt` trait still exists as an extension to all `Rng` types.  It's no longer defined at all when the "rand" feature is not enabled.  That was a misbehavior before, as enabling "rand" adds a blanket implementation, which would be a breaking change just by toggling the feature.

`BigUint` and `BigInt` now implement `SampleUniform` too, which lets them work natively with `Rng::gen_range`, `Rng::sample`, and `Uniform` in general.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-23 05:02:18 +00:00
Josh Stone
b252ccefb6 Add rand 0.5 to the release notes 2018-05-22 17:02:43 -07:00
Josh Stone
ec181ea593 Update rand CI 2018-05-22 16:56:54 -07:00
Josh Stone
b72822bbde impl SampleUniform for BigInt 2018-05-22 14:59:36 -07:00
Josh Stone
4ef07c4625 impl SampleUniform for BigUint 2018-05-22 14:48:52 -07:00
Josh Stone
39104f5732 refactor tests/rand.rs 2018-05-22 14:38:59 -07:00
Josh Stone
9fdec42818 bump to rand 0.5 2018-05-22 14:16:20 -07:00
Josh Stone
d7d6cc3446 optimize random range edge cases 2018-05-22 14:09:12 -07:00
Josh Stone
0becbac9d6 loop gen_bigint retries 2018-05-22 13:37:17 -07:00
Josh Stone
197be3f365 Move randomization to its own module 2018-05-22 13:28:15 -07:00
Josh Stone
ce0fd4c29d add a contributor 2018-05-22 13:04:17 -07:00
bors[bot]
f0022e3f89 Merge #45
45: Document Toom3 algorithm r=cuviper a=tiehuis

Happened to be going through toom3 so thought I'd type this up.

Co-authored-by: Marc Tiehuis <marctiehuis@gmail.com>
2018-05-22 19:47:49 +00:00
Marc Tiehuis
4c7b67226f Document Toom3 algorithm 2018-05-17 19:09:33 +12:00
Josh Stone
57ea5d4f44 Reorganize notes about breaking changes 2018-05-16 15:38:52 -07:00
Josh Stone
2d67ee4fcd Note #44 and #46 in the release notes 2018-05-16 15:33:00 -07:00
bors[bot]
7f59335070 Merge #46
46: Add a mandatory "std" feature r=cuviper a=cuviper

We don't actually support `no_std` yet, and probably won't until `alloc`
is stable.  We're just reserving this ability with the "std" feature
now, and compilation will fail without.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-16 22:22:02 +00:00
Josh Stone
23743e05db Add a mandatory "std" feature
We don't actually support `no_std` yet, and probably won't until `alloc`
is stable.  We're just reserving this ability with the "std" feature
now, and compilation will fail without.
2018-05-16 13:59:29 -07:00
bors[bot]
d449f32bd0 Merge #44
44: Add basic conversions for i128 and u128 r=cuviper a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-16 19:34:23 +00:00
Josh Stone
c6bce8a130 test i128 only on newer rustc 2018-05-16 12:19:47 -07:00
Josh Stone
04252b7716 Add basic conversions for i128 and u128 2018-05-15 18:01:14 -07:00
Josh Stone
275ba23cee chmod -x benches/factorial.rs 2018-05-14 23:04:37 -07:00
bors[bot]
79e5aa9dd7 Merge #43
43: Merge num-bigint-0.1.x and update pending release notes r=cuviper a=cuviper



Co-authored-by: Josh Stone <cuviper@gmail.com>
Co-authored-by: bors[bot] <bors[bot]@users.noreply.github.com>
2018-05-14 20:43:31 +00:00
Josh Stone
fee644e91f Update release notes toward 0.2x 2018-05-14 13:39:35 -07:00
Josh Stone
b374f9ac92 Merge branch 'num-bigint-0.1.x' into master 2018-05-14 13:01:51 -07:00
Josh Stone
2d37c0bb10 Mention the crate comparisons in 0.1.44 too
... if only to give more complete author credits for the release.
2018-05-14 12:06:50 -07:00
bors[bot]
5185cc2b8b Merge #42
42: Add a special case for single-digit divisors r=cuviper a=cuviper

It was pointed out in the blog post [Big Integers in Zig] that we don't
have a special case in `num-bigint` for single-digit divisors.  While
you can already get this optimization by dividing directly by `u32`,
it's easy to make small `BigUint` divisors work like this too.

    $ cargo benchcmp baseline single-div
     name                   baseline ns/iter  single-div ns/iter  diff ns/iter   diff %  speedup
     factorial_div_biguint  5,638,353         1,005,488             -4,632,865  -82.17%   x 5.61

`BigInt` will also gain from this, since it uses `BigUint` division
internally.

Running [zig-bn's facdiv-rs] shows a nice improvement too.  My i7-7700K
with Rust 1.26 goes from 4.15 seconds to just 0.65 -- a 6.38x speedup!

[Big Integers in Zig]: https://tiehuis.github.io/big-integers-in-zig#division-test-single-limb
[zig-bn's facdiv-rs]: https://github.com/tiehuis/zig-bn/tree/master/bench/facdiv/crate-facdiv-rs


Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-14 18:41:57 +00:00
Josh Stone
10e00ff66a Release 0.1.44 2018-05-14 11:24:39 -07:00
Josh Stone
f44bd0aee2 Add a special case for single-digit divisors
It was pointed out in the blog post [Big Integers in Zig] that we don't
have a special case in `num-bigint` for single-digit divisors.  While
you can already get this optimization by dividing directly by `u32`,
it's easy to make small `BigUint` divisors work like this too.

    $ cargo benchcmp baseline single-div
     name                   baseline ns/iter  single-div ns/iter  diff ns/iter   diff %  speedup
     factorial_div_biguint  5,638,353         1,005,488             -4,632,865  -82.17%   x 5.61

`BigInt` will also gain from this, since it uses `BigUint` division
internally.

Running [zig-bn's facdiv-rs] shows a nice improvement too.  My i7-7700K
with Rust 1.26 goes from 4.15 seconds to just 0.65 -- a 6.38x speedup!

[Big Integers in Zig]: https://tiehuis.github.io/big-integers-in-zig#division-test-single-limb
[zig-bn's facdiv-rs]: https://github.com/tiehuis/zig-bn/tree/master/bench/facdiv/crate-facdiv-rs
2018-05-14 11:24:32 -07:00
bors[bot]
351ea5f2b1 Merge #41
41: Implement assignment operators for BigInt r=cuviper a=cuviper

All of these operators were already implemented for `BigUint`, so
now `BigInt` support the same use.

Closes #7.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-12 00:31:28 +00:00
Josh Stone
96c1d69279 Implement assignment operators for BigInt
All of these operators were already implemented for `BigUint`, so
now `BigInt` support the same use.

Closes #7.
2018-05-09 16:36:29 -07:00
Josh Stone
dd4081721f sources shouldn't be executable 2018-05-09 16:18:56 -07:00
bors[bot]
86de320b63 Merge #39
39: Make it explicit that serialization is in u32 r=cuviper a=cuviper

Add explicit type annotations to make sure we serialize `BigUint` like a
`Vec<u32>`.  If we ever change the internal representation, we still
need to remain compatible with serialized data.

Also, deserializing `BigUint` and `BigInt` now uses their normal
constructor methods, to make sure they are normalized.  We shouldn't
assume that all incoming data is already well-formed.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-03 19:55:25 +00:00
Josh Stone
087c4ecfd6 Add serde tests 2018-05-03 12:39:15 -07:00
Josh Stone
f683b9d821 Make it explicit that serialization is in u32
Add explicit type annotations to make sure we serialize `BigUint` like a
`Vec<u32>`.  If we ever change the internal representation, we still
need to remain compatible with serialized data.

Also, deserializing `BigUint` and `BigInt` now uses their normal
constructor methods, to make sure they are normalized.  We shouldn't
assume that all incoming data is already well-formed.
2018-05-02 12:48:21 -07:00
bors[bot]
e22271cbc5 Merge #38
38: Remove big_digit::* from the public API r=cuviper a=cuviper

The *idea* of `big_digit` and its type aliases is that we may someday
use something other than `u32` in the representation, perhaps even
different sizes for different targets.  That's still a possibility, but
I think it's not really feasible to expose this variation in the public
API.  Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you
know what that size is, and users can't really alternate this kind of
thing based on a type definition.  So for now, we just commit to `u32`
units in the public API, no matter what we may do internally.

This removal is a breaking change, part of the 0.2 semver bump.  If I'm
wrong and somebody can show a compelling use case for `big_digit`, we
can always add things back into the public API later.

Co-authored-by: Josh Stone <cuviper@gmail.com>
2018-05-01 04:34:15 +00:00