Re: Key Points of Improvement of Huffman Codes

Therefore, the evaluation needs to be done on two axes. Can this proposal
be introduced on its own? If not, can it be introduced simultaneously with
other changes? These are the two axes. Note that it is theoretically
impossible to reach such high performance with a single code table. And
improvements in a single code table are directly reflected in this
algorithm without interference. This is an almost flawless upward
compatible encoding algorithm.

2023年12月10日(日) 7:19 姓名 <falsandtru@gmail.com>:

> I am not sure if this is balanced against the minimum cost, so I need to
> have it evaluated by an expert. However, even if my proposal is not
> cost-balanced on its own, I consider this to have high performance that
> should be adopted together with another proposal when it is adopted.
>
> 2023年12月10日(日) 7:05 姓名 <falsandtru@gmail.com>:
>
>> I have been waiting for just such a starting point. Whether this proposal
>> will be adopted should be debated on whether such a minimum cost is
>> balanced by the return I have offered.
>>
>> 2023年12月10日(日) 6:57 Matthew Kerwin <matthew@kerwin.net.au>:
>>
>>> On Sun, 10 Dec 2023 at 07:18, 姓名 <falsandtru@gmail.com> wrote:
>>> >
>>> [snip]
>>> >
>>> > ## Are the installation costs acceptable?
>>> >
>>> > There are no additional costs specific to this proposal. Thus, there
>>> are no more costs than would be incurred by other methods. If this proposal
>>> cannot be adopted because of cost, then all other methods of improving the
>>> compression ratio of Huffman coding cannot be adopted either.
>>> >
>>>
>>> I would propose an alternative interpretation: the inherent cost of
>>> implementing *any* change such as this is very high, so for any
>>> individual proposal to be worthwhile it has to provide enough of a
>>> benefit to overcome that inherent cost as well as whatever immediate
>>> problem it is improving on. That doesn't mean they will all fail -- if
>>> they're valuable enough they might get traction -- but it also means
>>> you can't amortise the cost of a single change over all potential
>>> changes.
>>>
>>> > ## What is the cost of the additional Huffman code?
>>> >
>>> > The added Huffman code is so regular that any encoder or decoder using
>>> it should be able to convert it to simple conditionals. Therefore, no new
>>> arrays or trees are required.
>>> >
>>>
>>> There are other costs / benefit reductions:
>>>
>>> * the cost of implementing the new encoding scheme and distributing
>>> the implementations, deploying software, etc.
>>> * integrating it with the protocol, describing how and where in the
>>> workflow it can be integrated, extension values, etc.
>>> * verifying that the integration doesn't undo a large part of the
>>> benefit -- e.g. the new encoding scheme potentially not being
>>> available in the first round-trip, when much of the compression (and
>>> thus benefit) would occur
>>>
>>> They may not necessarily be unique to this particular proposal, but
>>> they still exist and must be addressed.
>>>
>>> Cheers
>>> --
>>>   Matthew Kerwin
>>>   https://matthew.kerwin.net.au/
>>>
>>