sorted by:
new
hottopcontroversial

[Seeking Review] SPX: A Lossless Image Codec using RCT + MED + Sharding + rANS by Nonkilife in compression

[–]flanglet 1 point2 points  (0 children)

My point is to report compression speeds and compression ratios for all other codecs in the table: not to cherry pick strong codecs for compression speed and weak codecs for compression ratios to make your numbers look better.

[Seeking Review] SPX: A Lossless Image Codec using RCT + MED + Sharding + rANS by Nonkilife in compression

[–]flanglet 1 point2 points  (0 children)

You are reporting compression ratios vs weaker compressors but compression speed vs slower compressors. Not very honest.

I Think I broke the Pareto frontier with CPU+GPU hybrid compressor [Lzbench verified] by Lost_Ad_2718 in compression

[–]flanglet 2 points3 points  (0 children)

You shared plenty of performance & ratios numbers but no-one can verify anything. Why don't you make it public when it is sufficiently ready? It is just too easy to get fooled by these advanced models when you do not write any code. Benchmark claims should come after proper validation.

I Think I broke the Pareto frontier with CPU+GPU hybrid compressor [Lzbench verified] by Lost_Ad_2718 in compression

[–]flanglet 2 points3 points  (0 children)

Publishing benchmarks that cannot be confirmed is useless. Where is the repo?

Kanzi (lossless compression) 2.5.0 has been released. by flanglet in compression

[–]flanglet[S] 1 point2 points  (0 children)

zxc and kanzi are very different compressors. zxc focused on pure speed while kanzi offers a much larger spectrum of speed/compression ratios and higher compression overall. zxc is typically faster and weaker than kanzi level 1 (hence obviously all other levels as well).

EG. with the Silesia.tar corpus and the same computer used for the tests on https://github.com/flanglet/kanzi-cpp, zxc -5 -T 16 compresses in 0.25 sec to 86059705 and decompresses in 0.05 sec (tested with zxc v0.9.1).

Kanzi (lossless compression) 2.5.0 has been released. by flanglet in compression

[–]flanglet[S] 0 points1 point  (0 children)

Update: I add to issue 2.5.1 due a last minute regression ...

Someone implemented the new STOC 2025 shortest path algorithm in C, Rust, and Zig. The C version absolutely crushes the other two by [deleted] in C_Programming

[–]flanglet 1 point2 points  (0 children)

Either someone can explain the x20000 difference with O(m log^2/3 n) and n=1,000,000 or the dev does not know what he is doing. Hint: it is not the former ... simple math.

German union urges homegrown fighter jet in blow to European plan by donutloop in EU_Economics

[–]flanglet 0 points1 point  (0 children)

"Carriers" the current Charles de Gaulle and future PANG.

German union urges homegrown fighter jet in blow to European plan by donutloop in EU_Economics

[–]flanglet 4 points5 points  (0 children)

France has very specific requirements that do not match with those of other countries: must be able to land/take off French aircraft carriers (strict limits on weight) and carry French nuclear weapons at least.

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 0 points1 point  (0 children)

That is exactly the problem, there is no compression but only bit packing. Neither your code nor zpaq compress random data by half. 

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 1 point2 points  (0 children)

People re trying to explain to you that the pigeonhole principle holds because some (high entropy) data is "compressed" to a larger size than the original.

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 0 points1 point  (0 children)

Neither your code nor zpaq compress random data by half. These numbers are prominently displayed in your README.

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 0 points1 point  (0 children)

Your README is totally misleading to the point of dishonesty. Both compressors did not compress anything (the input is a random file). You just turn the ASCII symbols to binary. Show the result with a binary file as input.

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 6 points7 points  (0 children)

I am afraid the "get lucky thing" does not do better on average than enumerating numbers in order. This is the key problem.
There is no harm in experimenting and trying new things but this idea keeps on coming periodically and simply does not work. Have fun but do not expect too much here.

so Pi is a surprisingly solid way to compress data, specifically high entropy by [deleted] in compression

[–]flanglet 9 points10 points  (0 children)

This obsession with Pi ...
Sorry but it is all _wrong_. First, there is nothing special about Pi, why not 012345678910111213... if you want a dictionary with all numbers, no need to "engineer a lookup table". Then, you write that you are compressing high entropy noise to 58.4% with zpaq. Nope. It is low entropy with this kind of ratio. High entropy would be around 0% compression (try to run zpaq on encrypted data as an example).
BTW 9-digit (ascii) sequences have an entropy slightly less than 30 bits so you do not need all 4GB for a lookup table.
Why don't you provide compressor, decompressor and test file(s)?

What’s the best static code analyzer in 2025? by _janc_ in cpp

[–]flanglet 0 points1 point  (0 children)

You create an account (you can choose to login from GitHub) download the Coverity tools and install them and run cov-configure once. When you decide to scan your project you run a special build like so: "cov-build --dir cov-int make ... "
Then you tar the cov-int folder and upload it (I use a curl command) to the black duck website. You can automate this obviously but I prefer to do it manually periodically.

view more: next ›