Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is there a way to create a BitVec from an u8? #6

Closed
emlautarom1 opened this issue Apr 2, 2019 · 9 comments
Closed

Is there a way to create a BitVec from an u8? #6

emlautarom1 opened this issue Apr 2, 2019 · 9 comments

Comments

@emlautarom1
Copy link

emlautarom1 commented Apr 2, 2019

I would like to do something like this:

fn main() {
    let source: u8 = 0b1010_0101;
    let bv = BitVec::from(source);
}

I think I can convert a u8 to a Vec<bool>, but I would like to avoid as many conversions as possible, since performance is critical.

@myrrlyn
Copy link
Collaborator

myrrlyn commented Apr 2, 2019

Hi! Thanks for your issue; I really appreciate feedback from people using this in their work.

At present, I do not have any methods to create a collection from a single scalar. I do provide methods to convert Rust collections into the collections of this crate, such as:

let source: u8 = 0b1010_0101;
let bs: &BitSlice = (&[source] as &[u8]).into();
let bv: BitVec = (&[source] as &[u8]).into();
let bv: BitVec = vec![source].into();

with the traits impl From<&'a [T]> for BitSlice<_, T>, impl From<&'_ [T]> for BitVec<_, T>, and impl From<Vec<T>> for BitVec<_, T>. The BitSlice conversion will never allocate, and solely creates a handle over the source data. The BitVec conversion must allocate at least once, however, From<Vec<_>> for BitVec<_, _> seizes the original Vec's allocation, and will not cause a realloc.

I will add implementations for single values and small arrays for the 0.12 release (0.11 is being wrapped up, and is serde support); in the meantime, do the implementations listed above suffice?

@emlautarom1
Copy link
Author

emlautarom1 commented Apr 2, 2019

Thank you for your answer. By the way, the library is great, thanks for sharing your work.
Those methods might suffice, but I think I can do better.

What I'm trying to achieve is reading a file as a Vec buffer and then convert it into a BitVec. The original buffer can be discarded after this point.

Thanks to your anwer, I have the following code:

    let mut buffer = Vec::new();
    // Fill buffer with file content
    let total_read = file.read_to_end(&mut buffer).unwrap();
    // Consume original buffer in u8 to a BitVec buffer
    let mut bit_buff = bitvec![BigEndian, u8;];
    for n in buffer.into_iter() {
        let mut bv: BitVec = (&[n] as &[u8]).into();
        bit_buff.append(&mut bv);
    }

This, so far, is the best approach I've found. But I'm a little worried about performance (especially memory allocations). Do you think It's the right way to do it, or is there another way?

@myrrlyn
Copy link
Collaborator

myrrlyn commented Apr 2, 2019

Short answer:

Fill the Vec, and then call .into() or BitVec::from on it, and you're ready to go.

let mut buffer = Vec::new();
let total_read = file.read_to_end(&mut buffer).unwrap();
let mut bit_buff: BitVec<BigEndian, u8> = buffer.into();

bit_buff now covers all of the data that was placed in buffer by read_to_end, ready for use.

Detailed answer:

The implementation of the Vec-to-BitVec conversion takes ownership of the existing Vec's buffer, and creates an equivalent BitVec handle over the same raw buffer. This does not touch the buffer at all; there is no move, no reallocation, no involvement with the allocator or the heap data. It only changes the way your program looks at the buffer. It is not a free conversion -- creating a bits handle of any type involves a lot of assertions I haven't yet managed to elide -- but it is a relatively small, fixed, cost.

Any Rust borrowed slice &[T], boxed slice Box<[T]>, or vector Vec<T> can be turned into the corresponding type from this crate (&BitSlice<C, T>, BitBox<C, T>, BitVec<C, T>, respectively) using .into(), and this call will use the range you give it and only change the way you access it. That's the cheapest and preferred path to make a bitvec type out of existing data.

I will add this example to the README, since the low-cost creation of bit ranges from existing data is a very important part of the crate's usage.

@emlautarom1
Copy link
Author

Thank you so much for the detailed answer. I got a lot more insight in how this crate works.
Tinkering around I found that I can do the oposite: BitVec to Vec. Is it using the same logic under the curtains?

let output: Vec<u8> = bit_buff.into();

If you want to see the full code I'm working on for examples please check this repo:
https://github.com/lautaroem1/Hamming_Encoder

If you need any help with the README I would gladly collaborate.

@myrrlyn
Copy link
Collaborator

myrrlyn commented Apr 3, 2019

Yes; the library is written with the full intention that users will turn byte slices into bit slices, and bit slices back into byte slices, and .into() works in both directions.

I'll add named functions akin to Vec::into_boxed_slice so that it's more clear how to transform back and forth, though.

@myrrlyn
Copy link
Collaborator

myrrlyn commented May 11, 2019

bitvec 0.11.0 adds methods from_element on BitSlice, BitBox, and BitVec to produce those structures directly from a single source element, as well as from_slice to produce them from multiple.

@myrrlyn myrrlyn closed this as completed May 11, 2019
@HamishWHC
Copy link

Sorry to revive an old issue, but wondering what the current way to do this is? from_element no longer exists on BitVec.

myrrlyn added a commit that referenced this issue Feb 13, 2021
@myrrlyn
Copy link
Collaborator

myrrlyn commented Feb 13, 2021

Thank you for doing so! I have discarded and rebuilt this crate a couple times and I am utterly unsurprised that I've forgotten about some of my APIs.

I have restored BitVec::from_element, and added BitVec::from_slice. These are present immediately on develop, and will go up on crates.io by the end of the month.

@HamishWHC
Copy link

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants