Re: Key Points of Improvement of Huffman Codes

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/

Received on Saturday, 9 December 2023 21:57:25 UTC