What should count as a compression algorithm?

Question

I am working on a new challenge (sandbox link) that has something in common with my old challenge Paint Starry Night. In these challenges the goal is essentially to design a compression algorithm tailored to a particular input. (For the new challenge the input is text rather than an image.)

In Paint Starry Night the most competitive answers simply wrapped an existing image compression format such as FLIF or BPG. These answers are (to me) less interesting than some of the others, which did really clever things with genetic algorithms and deep neural networks. For the new challenge I would like to include a rule against such off-the-shelf implementations of compression algorithms, while still leaving a level playing field for all other approaches.

My question is on the right way to do this --- in short, where and how to draw the line between compression routines like bz2 or gzip, versus language features like Python's base conversion or Jelly's dictionary lookup feature, both of which I think should be allowed. The things I want to avoid are (i) that people come up with loopholes that allow them to produce trivial solutions that wrap existing algorithms, or (ii) I accidentally ban perfectly sensible language features that could be used to build a non-trivial solution.

The sandbox link above has (at the time of writing) a possible way to do this based on what Wikipedia's editors list as compression algorithms, but I am not really sure if this is a good idea. Hence I would like to ask for feedback on it, and/or other suggestions of how to define off-the-shelf compression algorithms for the purposes of this kind of challenge.

Answer 1

It's unrealistic to define this

You have summed up well the reasons that banning certain algorithms will cause problems (whether you ban too many or too few). I don't expect anyone to come up with a clean solution to this that won't cause other problems. If an existing compression algorithm happens to be better than any the contestants can come up with, then their striving towards the best approach will lead some of them to converge on their own implementations of those existing algorithms. Banning an algorithm that people will naturally converge on seems to create an unavoidable grey area.

Observable rules

As has been pointed out elsewhere in similar discussions, it's problematic to try to ban implementation approaches. To keep the rules objective, it's generally better to define them in terms of inputs and outputs, instead of in terms of the internal workings of the code. This has been described elsewhere as avoiding making rules about unobservable behaviour.

Seek the weaknesses of existing algorithms

So I recommend approaching this problem from a different direction. Instead of taking an input that is best compressed with existing algorithms, and trying to carefully ban those algorithms without banning too much, try to find an input or category of inputs that existing algorithms are not the best approach to. Then you don't need to ban them. Early answers may involve existing algorithms, which may not seem as innovative, but later answers will show custom algorithms that suit the specific input types better.

This will be a difficult task, as there are a variety of compression algorithms available that are suited to different input types, but I still think this will be more realistic than trying to find an objective way to ban only some algorithms.