4 ms·

And the corresponding decompressor: https://bugfix-66.com/d548f3abf6faa823a829e4c770a8babca648a5fdcbf69f9a7ba385bb3199f8f0 https://bugfix-66.com/d548f3abf6faa8

And the corresponding decompressor: https://bugfix-66.com/d548f3abf6faa823a829e4c770a8babca648a5fdcbf69f9a7ba385bb3199f8f0 https://bugfix-66.com/d548f3abf6faa823a829e4c770a8babca648a5... Does a simpler compressor/decompressor exist with comparable bits-per-byte performance?

deleted 4y ago
[deleted]
JPLeRouzic 4y ago
Is there some more info on this algorithm, who designed it, when, where? Is it related to: https://en.wikipedia.org/wiki/Prediction_by_partial_matching https://en.wikipedia.org/wiki/Prediction_by_partial_matching Or, considering the web site title, is there a bug in this algorithm? Thanks!
- bugfix-66 4y ago
  This is a folk algorithm of unknown origin. All I know is the original author was probably a hacker from Finland and it was originally written in x86 assembly. This is my modernized implementation of his algorithm. As for solving the BUGFIX-66 puzzles, to fix the bug in the compressor, add to = append(to, 0) on the line after loc = len(to) The original code was not inserting a placeholder for every control byte. To fix the decompressor, add at++ on the line after ctrl := int(from[at]) The original code was not stepping past a control byte after loading it.
  - JPLeRouzic 4y ago
    Thank you!
  - asiekierka 4y ago
    Doe it literally check for the specific solution? Writing to = append(to, ctrl) which is functionally equivalent and, in my personal opinion, with clearer intent (ctrl = 0 at that point in the code), returns "incorrect". In fact, it seems that any placeholder value should work - as it is always overwritten by the final value of ctrl for a given set of bytes at the end; however, the checker rejects this.
    - bugfix-66 4y ago
      Your fix is wrong, so the site rejects it. Go doesn't do integer type conversions implicitly, to avoid the implicit-type-casting bugs endemic to C. Go (thankfully) doesn't allow an implicit conversion from int to byte. You must do the cast explicitly. So you would have to say to = append(to, byte(ctrl)) and that's correct. The site builds and executes the code you submit, and any correct solution is accepted.
- CamperBob2 4y ago
  Seems like something that might have been written as an evolutionary step towards LZ77.
  - deleted 4y ago
    [deleted]

deleted 4y ago

[deleted]

JPLeRouzic 4y ago

Is there some more info on this algorithm, who designed it, when, where? Is it related to: https://en.wikipedia.org/wiki/Prediction_by_partial_matching https://en.wikipedia.org/wiki/Prediction_by_partial_matching Or, considering the web site title, is there a bug in this algorithm? Thanks!

bugfix-66 4y ago
This is a folk algorithm of unknown origin. All I know is the original author was probably a hacker from Finland and it was originally written in x86 assembly. This is my modernized implementation of his algorithm. As for solving the BUGFIX-66 puzzles, to fix the bug in the compressor, add to = append(to, 0) on the line after loc = len(to) The original code was not inserting a placeholder for every control byte. To fix the decompressor, add at++ on the line after ctrl := int(from[at]) The original code was not stepping past a control byte after loading it.
- JPLeRouzic 4y ago
  Thank you!
- asiekierka 4y ago
  Doe it literally check for the specific solution? Writing to = append(to, ctrl) which is functionally equivalent and, in my personal opinion, with clearer intent (ctrl = 0 at that point in the code), returns "incorrect". In fact, it seems that any placeholder value should work - as it is always overwritten by the final value of ctrl for a given set of bytes at the end; however, the checker rejects this.
  - bugfix-66 4y ago
    Your fix is wrong, so the site rejects it. Go doesn't do integer type conversions implicitly, to avoid the implicit-type-casting bugs endemic to C. Go (thankfully) doesn't allow an implicit conversion from int to byte. You must do the cast explicitly. So you would have to say to = append(to, byte(ctrl)) and that's correct. The site builds and executes the code you submit, and any correct solution is accepted.
CamperBob2 4y ago
Seems like something that might have been written as an evolutionary step towards LZ77.
- deleted 4y ago
  [deleted]