Write support?

[mpetri]

Interested in using this crate but it is a bit unergonomic to having to resort to a different crate to write the bit patterns and then switch to this to read them

[nickbabcock]

Makes sense, I experimented with the writer API a few years ago. Does this API look desirable? If so, I can look to resurrect it. master...io#diff-3e344dc31cd763c82ee7b32eb4d1423b17150a15ade513ff4ab002bdad81ff47

[mpetri]

Looks ok mostly. These two look a bit weird:

pub fn write_bits(&mut self,  bits: i32, value: u64) -> Result<()> {
    let bts = bits as usize;
    let data = value.to_le_bytes();
    let whole_bytes = bts / 8;

    self.write_slice(&data[..whole_bytes])?;

    let remainder = bts % 8;
    if remainder != 0 {
        let mut partial_byte = data[whole_bytes];
        for _ in 0..remainder {
            let bit = partial_byte & 1 == 1;
            self.write_bit(bit)?;
            partial_byte >>= 1;
        }
    }
    Ok(())
}

pub fn write_signed_bits(&mut self, bits: i32, value: i64) -> Result<()> {
    todo!()
}

why is bits signed? and what does write_signed_bits mean? if you pass in a 3 bit number and set bits to 3 you write 3 bits + the sign bits so 4 bit?

[nickbabcock]

Thanks for looking it over.

why is bits signed?

Yeah that's a holdover from something else, and wouldn't be signed if writer support is made live

what does write_signed_bits mean? if you pass in a 3 bit number and set bits to 3 you write 3 bits + the sign bits so 4 bit?

I believe I intended a similar behavior to bitstream's implementation, however it's been a few years and I'm open to suggestions.

[mpetri]

Ok make sense. the bistream implementation also has this SignedNumeric trait for the [write_signed](https://docs.rs/bitstream-io/2.2.0/bitstream_io/write/trait.BitWrite.html#tymethod.write_signed) function which is quite nice to avoid casting?

[nickbabcock]

Yeah that's a good idea.

[mpetri]

FWIW, I'm looking to implement some compression codes such as elias_gamma , elias_delta etc. and I'm looking for a bit-I/O crate.

would you be interested to have these as contributions? e.g. write_elias_gamma and read_elias_gamma or similar

[nickbabcock]

Sure, though if these functions don't introduce anything new in the way of primitives, I'd recommend defining an extension trait in downstream crates where this functionality can be ergonomically exposed. An earlier version of this crate contained a lot of specific APIs that were only relevant to my domain. So, I removed them to better focus on making sure that the right primitives are exposed so others (including myself) can build the right abstractions.

[mpetri]

I would argue if you are writing/reading integers with different bit widths, writing them using codes like elias_gamma delta etc. is something I would expect in a bit-I/O crate. Instead of writing a u32 with 32 bits I would want to encode it using elias_gamma for example and there exist many compression techniques where different numbers in the stream are encoded/decoded that way.

[mpetri]

But if you don't want these here I'll create a separate crate but I would still be interested in write support

[nickbabcock]

I agree, universal codes are useful. Questions arise, like which codes to support? What would the API look like? Should there be separate APIs to handle non-positive numbers? Are there codes that can't be generalized and input has to be positive only?

Very exciting questions. That's why it might be better to iterate outside the main bitter api so that these changes can be incorporated when there's confidence in the design and implementation.