Add iter_u32_digits , iter_u64_digits, to_u64_digits to both BigInt and BigUint

[Speedy37]

This adds: iter_u32_digits , iter_u64_digits, to_u64_digits to both BigInt and BigUint

[Speedy37]

I'm wondering if adding iter_u32_digits/iter_u64_digits to BigInt is a good idea.
I guess users can use (magnitude().iter_u32_digits()) if they needs too.

[cuviper]

Hi, thanks for the PR, and sorry for the late review.

I'm wondering if adding iter_u32_digits/iter_u64_digits to BigInt is a good idea.

I think it's fine to keep API parity between BigInt and BigUint for most things.

[Speedy37]

Should iter_u32_digits and iter_u64_digits on BigInt also returns the (Sign, Iterator) couple to match other similar method return types?

[cuviper]

I think it's OK that these methods return just the iterator, because that makes chaining easier, and fn sign can be used separately.

[Speedy37]

I fixed the latest set of requested changes.

[cuviper]

Can you add #[inline] on all of the iterator methods? I tried myself, and it makes a huge difference to the benchmarks:

 name             base.x86_64 ns/iter  inline.x86_64 ns/iter  diff ns/iter   diff %  speedup
 iter_u32_digits  130                  62                              -68  -52.31%   x 2.10
 iter_u64_digits  64                   8                               -56  -87.50%   x 8.00
 to_u32_digits    152                  78                              -74  -48.68%   x 1.95
 to_u64_digits    85                   32                              -53  -62.35%   x 2.66

 name             base.i686 ns/iter  inline.i686 ns/iter  diff ns/iter   diff %  speedup
 iter_u32_digits  136                14                           -122  -89.71%   x 9.71
 iter_u64_digits  111                42                            -69  -62.16%   x 2.64
 to_u32_digits    154                62                            -92  -59.74%   x 2.48
 to_u64_digits    127                68                            -59  -46.46%   x 1.87

(I was going to just do it, but it seems your branch isn't open to maintainer pushes.)

[Speedy37]

Done

[cuviper]

One more bikesheddy thought -- maybe we should drop the iter_/Iter prefixes? e.g. u32_digits -> U32Digits. I was considering the str iterators for prior art with bytes() -> Bytes and chars() -> Chars, or the maps have keys -> Keys, etc. I think it's uncommon to use iter/Iter in the names unless that's all there is to it (Iter/IterMut/IntoIter).

[cuviper]

I suggest:

/// An iterator of the `u32` digits representation of a `BigUint` or `BigInt`,
/// ordered least significant digit first.

Also, we should reexport this struct in the root, because this module is not public.

(Ditto for IterU64Digits.)

[cuviper]

nit: this is identical to the cfg(u64_digit) version, so we could just have a unified version.

[cuviper]

We should add a multi-digit example, like BigUint::from(1u128 << 64).
(ditto for iter_u64_digits, and the BigInt counterparts.)

[cuviper]

Completed in #192.