interesting problem

[[Gandalf]]

It's actually a pretty straightforward problem, just look at the output for the examples. The result is the length of the compressed string. So instead of having BARXFOO you would have *2X*1 because *2 is BAR and *1 is FOO. "*2X*1" is 5 characters so that is what you would get as a result (as opposed to 7 characters without the compression).

[wtd]

Of course, in reality, you have to add 6 characters to communicate what the keys are.

[[Gandalf]]

Yes, so it's only really a compression technique if there are more than one of the 'keys' in the string. You could also add detection for that, so that you don't make some file bigger instead of smaller .

[bugzpodder]

[Gandalf] wrote:

It's actually a pretty straightforward problem, just look at the output for the examples. The result is the length of the compressed string. So instead of having BARXFOO you would have *2X*1 because *2 is BAR and *1 is FOO. "*2X*1" is 5 characters so that is what you would get as a result (as opposed to 7 characters without the compression).

the more interesting case is when keys overlap.
such as for keys AAA and AAB

[wtd]

bugzpodder wrote:

[Gandalf] wrote:

It's actually a pretty straightforward problem, just look at the output for the examples. The result is the length of the compressed string. So instead of having BARXFOO you would have *2X*1 because *2 is BAR and *1 is FOO. "*2X*1" is 5 characters so that is what you would get as a result (as opposed to 7 characters without the compression).

the more interesting case is when keys overlap.
such as for keys AAA and AAB

Yes, since "compressing" based on the first key inherently changes the result of "compressing" using the second key.

[[Gandalf]]

Hmm, ya I see. What I would do though is just replace the first key, and then you have nothing to worry about since the overlap doesn't exist anymore . Yes, me and my lazy ways...