Re: Multiple Huffman code tables

One more thing. You said "no limit to the complexity one can advocate for
to squeeze out additional small bits", but the bits that can be squeezed
out are big, and I think there is no reason not to squeeze out these big
bits. Look at the number of bits reduced in the proposal.

2023年12月9日(土) 9:03 姓名 <falsandtru@gmail.com>:

> I leave it to you to decide how much to squeeze out. My proposal is the
> squeezing method itself. This approach especially squeezes a lot of bits
> out of tokens even with my simple implementation.
>
> 2023年12月9日(土) 8:44 姓名 <falsandtru@gmail.com>:
>
>> Very easy to implement. Just determine from the context. Look at the
>> source code.
>>
>> 2023年12月9日(土) 8:39 Watson Ladd <watsonbladd@gmail.com>:
>>
>>> On Fri, Dec 8, 2023 at 8:11 AM 姓名 <falsandtru@gmail.com> wrote:
>>> >
>>> > HPACK/QPACK uses only one static table of Huffman coding, but the
>>> compression ratio can be improved by combining multiple tables. There is no
>>> overhead in data size due to the combination. Theoretically, two code
>>> tables can reduce the bit length of one code table by an average of one
>>> bit, since the two code tables itself has one bit of information. This
>>> proposal especially reduces the token size increasing in recent years. Let
>>> me know the link to the conclusions if this approach has been considered.
>>> The following is a comparison based on my proof of concept code. The
>>> leftmost number is the reduced bit size.
>>>
>>> How do you signal which table is used? This is a crude approximation
>>> to a more sophisticated encoder that understands a single hidden bit
>>> of which alphabet is used: if we go down that road there really is no
>>> limit to the complexity one can advocate for to squeeze out additional
>>> small bits.
>>>
>>> Sincerely,
>>> Watson
>>> --
>>> Astra mortemque praestare gradatim
>>>
>>