Bro just decompile agiannis_text
https://codeberg.org/kagiannis/gdcc-2021/src/branch/main/shu... original source
How is this source code the original source and which parts? Please elaborate.
bzip3
111–120 of 133 posts
Re: bzip3
#112The latest release is a year ago, the last commit is two months ago, and the build is failing. The claim “stronger than bzip2” is strange. What does it even mean? Also, comparing parallel decompression benchmarks with bzip2 instead of pbzip2 seems unfair.
Please report any build errors in the GitHub issue tracker so that the isseu can be fixed for everyone. Thank you!
Re: bzip3
#113It's distasteful to use such a name when it's not created by the bzip authors. For some reason open source developers love using would be trademark infringing names instead of coming up with something unique.
Other than the oppressive trademark law how isn't it bzip3?
Because it's not version 3.0 of bzip, but an entirely different program.
Re: bzip3
#114Re: bzip3
#115Re: bzip3
#116Earlier quoted context omitted.
> “bzip3 is not yet listed on the large text compression benchmark” It is now And it comes in relatively well, in my opinion. I'm a compression amateur, but bzip3 is the first entry I recognize as a general purpose compression program.
Yes, bzip3 compresses that 1GB text file into 170 MB while zstd needs 213 MB (SI units, from my own tests with the "enwik9" file of the GP's page, and the latest releases of both programs, same commands). But the decompression (memory and speed) is a different story. On my desktop, decompressing with zstd requires 128 MB and 1 s, while bzip3 uses 3.2 GB and 90 s. Without `-b 511`, bzip3's ratio decreases and decompre…
This should get more attention - those decompression requirements are a massive impost.
Re: bzip3
#117Previously: “Hi, tool author here.” A useful explanation of Burrows-Wheelers transform as used by bzip3: https://news.ycombinator.com/item?id=42902407 “bzip3 is not yet listed on the large text compression benchmark” It is now: https://mattmahoney.net/dc/text.html (2 years ago, 176 comments) https://news.ycombinator.com/item?id=42899713 (4 years ago, 104 comments) https://news.ycombinator.com/item?id=31324439
> It is now:
Matt added bzip3 to the benchmark seemingly after the last year thread. If the zstd benchmark, last update at max 22 in 2016, were to be updated for today’s zstd (for long-range if nothing else) after coming across this thread, what would be the most compact possible list of option sets to benchmark to reflect the value of LR et al.?
Re: bzip3
#118Re: bzip3
#119Re: bzip3
#120> However, the complexity of the algorithms, and, in particular, the presence of various special cases in the code which occur with very low but non-zero probability make it impossible to rule out the possibility of bugs remaining in the program. Sounds like perhaps a nice testcase for formalization + AI?
It's beyond me why such foundational libraries don't have formal correctness proofs attached these days.
formal correctness proof is ridiculously hard, like, insanely hard, have you ever tried writing one for any real algorithm (not a platonic ideal quicksort)?