Re: Key Points of Improvement of Huffman Codes

[姓名 <[e-mail]>]

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 <[e-mail]>:

> On Sun, 10 Dec 2023 at 07:18, 姓名 <[e-mail]> 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/
>