15 releases (1 stable)
1.0.0 | Sep 26, 2022 |
---|---|
1.0.0-alpha.1 | Jul 15, 2022 |
0.6.0 | Apr 12, 2022 |
0.5.2 | Nov 19, 2021 |
0.3.1-alpha | Jul 23, 2020 |
#2212 in Magic Beans
303 downloads per month
Used in 12 crates
(6 directly)
94KB
2K
SLoC
bee-ternary
lib.rs
:
A general-purpose ternary manipulation, translation and encoding crate.
Features
- 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
serde
support
Encodings
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
slices.
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.
It is likely that one of the 3 encodings above will suit your requirements. In addition, this
crate also supports T2B1
and T4B1
for completeness.
Byte Alignment
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 T3B1
buffer will always start on an index of the original buffer that is a multiple of 3.
Dependencies
~94–325KB