Re: Key Points of Improvement of Huffman Codes

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