Write support? about bitter HOT 10 OPEN

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

from bitter.

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?

from bitter.

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.

from bitter.

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?

from bitter.

Yeah that's a good idea.

from bitter.

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

from bitter.

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.

from bitter.

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.

from bitter.

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

from bitter.

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.

from bitter.