325: Implement assign_from_slice r=cuviper
This commit implements `assign_from_slice(..)` for `BigUint` and `BigInt`. `assig_from_slice` is for performance : it allows to reassign a value to a `BigInt` or a `BigUint` without useless reallocations. It would be useful for loops for example. I need it to implement the Toom-3 algorithm.
I also added a missing test for `BigInt::from_slice(..)`.
323: Add CI badge r=cuviper
324: Add CI badge r=cuviper
This adds the CI badge to the pages on crates.io, #323 adds it to the README. Sorry for the separate PRs, but I didn't feel like forking and cloning the repository down to my laptop and simply used the GitHub online editor instead :-)
317: Feature/complex from str r=cuviper
This commit adds a basic parser for Complex types in Cartesian form, per https://github.com/rust-num/num/issues/289. It will take numbers of the form `a + bi`, `ai + b`, `a - bi`, `ai - b`, `a`, or `ai`. At least one space between the real/imaginary parts and the operator is mandatory; without bringing in a dependency on some regex crate, it's nontrivial to handle cases like, e.g., 0.217828e+1+31.4159E-1, or a similar case with polar coordinates. I could work on these issues later if you like.
320: complex: implement real ops directly r=cuviper
It's more efficient to implement these without creating an intermediate
complex value -- at the least, we don't have to rely on the compiler
optimizing out zero-ops.
274: Implement OpAssign for Complex r=cuviper
Design choice: Use by-value forms of OpAssign and use Clone to forward the reference arguments. That matches what the other traits do (for example Add).
Design choice: The complex += complex operation needs Add, not just AddAssign. The complex += real operation can use just AddAssign. You could just use Add for both, not sure which way is preferable.
It's more efficient to implement these without creating an intermediate
complex value -- at the least, we don't have to rely on the compiler
optimizing out zero-ops.
313: Scalar operations across all integer types r=cuviper
With my apologies for opening a new PR, and also for the 8 month delay, this continues the work started in #237 - the discussion there outlines the goals I was aiming for. I suppose this supersedes that PR and the other one can now be closed.
This PR adds support for Add, Sub, Mul, Div and Rem operations involving one BigInt/BigUint and one primitive integer, with operands in either order, and any combination of owned/borrowed arguments.
314: Derive ToPrimitive for enums r=cuviper
I had to double the compile fail tests, as they will bail on the first error.
I have some ideas for more complex to/from primitive derives (with inner values that implement to/from primitive), but I'll save those for a future PR.
311: rational: make sure Hash agrees with Eq r=cuviper
We can't use a derived `Hash` when we have a manual `Eq`, because we
need to uphold the invariant `a == b` → `h(a) == h(b)`. Since `Eq`
doesn't require them to be in reduced form, `Hash` also needs to be
normalized.
Fixes#310.
315: Fix float NaN positive/negative assumptions r=cuviper
These are the minimal assumptions to make about `NaN`. Fixes part of #312 (but not the `next` branch).
Isaac Carruthers
Nicolas Kirchner
bors[bot]
Martin Geisler
Josh Stone
Alan Liddell
bluss
Keith Wansbrough
Keith Wansbrough
Alan Liddell