15 releases (1 stable)
|Sep 26, 2022
|Jul 15, 2022
|Apr 12, 2022
|Nov 19, 2021
|Jul 23, 2020
#2649 in Magic Beans
718 downloads per month
Used in 12 crates (6 directly)
A general-purpose ternary manipulation, translation and encoding crate.
- Creation of trit and tryte buffers with multiple encodings
- Safe encoding API that allows the efficient manipulation and sharing of trit and tryte buffers and slices
- Mutation of trit buffers and slices
- Ternary BigInt implementation
- Balanced and unbalanced ternary
This crate includes support for many different trit encodings. Encodings allow the trading off of different features against each other.
T1B1 is the canonical default encoding and represents every trit with a single byte of
memory. It is the fastest encoding to manipulate since no bitwise operations are necessary to
pack and unpack it from memory during manipulation. As a result of this, it also permits
certain extra features like mutable chunking and accessing its contents through ordinary
T3B1 is also commonly used. It provides good compression and has the advantage that it has
an identical bit representation as a
Tryte slice. For this reason, it is the only encoding
that can be converted to a tryte slice with no overhead.
T5B1 is the most compressed encoding. It provides very high storage densities (almost
optimal, in fact) and is the densest encoding supported by this crate.
This crate supports creating sub-slices of trit slices. To enable this, it stores extra
metadata along with a trit slice in order to correct identify the index of a buffer it starts
on. With compressed encodings, such as
T3B1, that starting index (and, indeed, the end
index) may not fall exactly on a byte boundary.
This crate makes a best attempt at avoiding the negative ramifications of this fact, but sadly some still leak through into the API. For example, some methods may panic if a slice does not have a byte-aligned starting index or otherwise does not fulfil certain invariants. However, all panicking behaviours are documented on each method such that you can easily avoid circumstances like this.
When the documentation refers to 'byte alignment', it is referring specifically to whether the
starting index is a multiple of the compression factor. For example a byte-aligned
buffer will always start on an index of the original buffer that is a multiple of 3.