| Crates.io | apint |
| lib.rs | apint |
| version | 0.2.0 |
| created_at | 2017-10-23 00:04:17.736194+00 |
| updated_at | 2018-05-16 10:53:57.12092+00 |
| description | Arbitrary precision integers library. |
| homepage | |
| repository | https://github.com/robbepop/apint |
| max_upload_size | |
| id | 36611 |
| size | 330,646 |
| Linux | Windows | Codecov | Coveralls | Docs | Crates.io |
|---|---|---|---|---|---|
Development in progress: The implementation has not been finished and may not work.
Arbitrary precision Integers (ApInt) represent integers that have an arbitrary but fixed runtime bit-width and offers two's complement modulo arithmetic equal to machine integers.
The integer types offered by this library are:
ApInt: A low-level arbitrary-precision integer without static signedness information. (General)Int: A signed arbitrary-precision integer. (Convenience for iN.)UInt: An unsigned arbitrary-precision integer. (Convenience for uN.)The API is based on the LLVM APInt support library.
The design focus is at efficiency and robustness.
ApInt instances are small-value-optimized. This means that only ApInt instances with a bit-width larger than 64 bits allocate dynamic memory.
An ApInt constists of a sequence of 64-bit Digits.
Computations are done within their 128-bit DoubleDigit form to prevent bit-loss on over- or underflows.
This implies a dependency on 128-bit integers which are currently unstable in Rust.
The below table lists public and internal differences between ApInt and num::BigInt.
| Topic | num::BigInt |
ApInt |
|---|---|---|
| Abstraction | High-level unbounded integers. | Twos-complement machine integers. |
| Behaviour | Behaves like an immutable type most often. This results in lots of copies and better usability. | API design with a focus on efficient operations and machine emulation. |
| Small Value Optimization | No | Yes: Up to 64-bits. |
| Building Blocks | 32-bit BigDigit aka u32 |
64-bit Digit |
| Compute Unit | 64-bit DoubleBigDigit aka u64 |
128-bit DoubleDigit |
| Signed | Yes: num::BigUint is for unsigned. |
No: Operations know signedness instead. |
mem::size_of<..> |
About 24 bytes + some signedness info. | Exactly 128 bits (16 bytes). |
| Width interoperability | No restriction to operate between BigInt instances with different bit-widths. |
Only ApInt instances with the same bit-width can interoperate. |
| Memory footprint | Determined by current value stored. | Determined by bit-width. |
| Can grow and shrink? | Yes | No, see above. |
| Unstable features? | None | Stable as of Rust 1.26. |
Currently only a few parts of the implementation are done - especially the implementation of ApInt's with bit-widths greater than 64 bits is incomplete.
State of the API modules implemented so far:
| Module | Design | Implementation | Testing | TODO |
|---|---|---|---|---|
arithmetic |
done | unfinished | unfinished | |
constructors |
done | done | done | |
casting |
done | done | not started | issue #4 |
bitwise |
done | done | not started | |
shift |
done | done | done | |
relational |
done | done | not started | |
utils |
done | done | not started | |
serialization |
done | unfinished | unfinished | depends on arithmetic |
to_primitive |
done | done | done | |
serde_impl (opt.) |
done | done | done | |
rand_impl (opt.) |
done | done | done |
ApInt implementation and decent test coverage.ApsInt wrapper around ApInt that stores a run-time sign information.
This is different from Int and UInt since those types store
their sign immutable in their type. This is the same as LLVM's APSInt data type.Licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Binary, LowerHex and UpperHex impls to Int, UInt and ApInt.Octal are still missing.ApInt, Int and UInt.into_bitnot to ApInt, Int and UInt.ApInt::sign_extend and Int::extend (issue #15). Thanks AaronKutch for reporting!ApInt::from_{i128, u128}.