Re: Multiple Huffman code tables

Here is an excerpt of the bit that was squeezed out large just to be sure.
Of course, this is a reduced number of bits from HPACK. Is this small?

-45, 'CKa1yQEIj7bJAQiltskBCKmdygEI5tTKAQieicsBCJahywEIhaDNAQjwsc0BCNy9zQEI38TNAQi1xc0BCLnKzQEI1dDNAQiR0s0BCIrTzQEIwtTNAQjJ1s0BCPnA1BUYwcvMARi4v80B'
-50, 'Ap+qNlnLzJDKSmEHjzM5ilaa908GuehlLqGb6ezME5lkhelj20qVzfv06zPmQ3LodoeujZuphAolrnhnPA8w4AIAAABfeyJvcmlnaW4iOiJodHRwczovL3d3dy5nb29nbGUuY29tOjQ0MyIsImZlYXR1cmUiOiJQZXJtaXNzaW9uc1BvbGljeVVubG9hZCIsImV4cGlyeSI6MTY4NTY2Mzk5OX0='
-82, 'AvudrjMZqL7335p1KLV2lHo1kxdMeIN0dUI15d0CPz9dovVLCcXk8OAqjho1DX4s6NbHbA/AGobuGvcZv0drGgQAAAB9eyJvcmlnaW4iOiJodHRwczovL3d3dy5nb29nbGUuY29tOjQ0MyIsImZlYXR1cmUiOiJCYWNrRm9yd2FyZENhY2hlTm90UmVzdG9yZWRSZWFzb25zIiwiZXhwaXJ5IjoxNjkxNTM5MTk5LCJpc1N1YmRvbWFpbiI6dHJ1ZX0='
-23, 'AEC=Ackid1QH6gVXB6Rn68KWRmRtOGSW1unAfUHYsxuZh3Zs8cyWCZdKy8vrhQ;
expires=Mon, 20-May-2024 18:46:19 GMT; path=/; domain=.google.com;
Secure; HttpOnly; SameSite=lax'
-40, 'NID=511=fx_DiN-XffVTX7QHZe7UgP5GQd0mx2HY9B0Hz6MgzEpOESnD8DldcSLyj-U6AHIo8t4-dcOKelciAyOK2j03GJE1r_31zKvXnECnKWvOQiFPO6mtTTaCZWqtn2x8m5lnzbB_CyUA-HzXz-Vw3TXC0eeW_AQlcu8CybBgyxtW5Kc;
expires=Thu, 23-May-2024 18:46:19 GMT; path=/; domain=.google.com;
Secure; HttpOnly; SameSite=none'


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

> 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
>>>>
>>>