Shitsux

Hi /prog/,

I just finished on my "proof of concept" of a new compression algorithm, and frankly it's awesome.

At current guesstimations I could compress a 10MB file to about ~4MB in less than 30 seconds (Probably less than 5 seconds but I'm being cautious).

To decompress will take about a day. A whole day. Though I'm 100% certain that I could halve that time by using two cores, and CUDA/OpenCL/etc probably couldn't hurt either but I couldn't make a judgement on those.

So basically in 10 years time when we have 64+ cores and new super GPUs it'll be awesome right?

So basically in 10 years time when we have 64+ cores and new super GPUs it'll be awesome right?
No, we'll all be using FV's superior compression algorithm

>>2
i lol'd

>>1,2 I have much different problems:
Compressing time rises exponentially with each byte of input, and there is no way to reduce it(well beside increasing the filesize,which would remove the compression factor)  because the bruteforce search
for representations in formulas is very slow(due having to calculate the formula each time a variable changes).
On the other hand decompression is done in several seconds. It just builds the file by formula and writes it.


____________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
We've arranged a civilization in which most crucial elements profoundly depend on science and technology. We have also arranged things so that almost no one understands science and technology. This is a prescription for disaster. We might get away with it for awhile, but sooner or later this combustible mixture of ignorance and power is going to blow up in our faces.

>>1-5
Morons.

>>5

He he he

>>5 The idea its self isn't "impossible" just consider:
1.every file is number
2.If you get a formula to result in this number, and variables in the formula are smaller then file its compressed.
3.You can get Inexact results, like 9 can be 9.8 or 9.01 and still decompress into the same file.
4.By manipulating the file content/number (e.g. multiplying it by constant like (2^(8*filesize))) you can increase search space enormously and decompression is, just dividing the result by the same constant and discarding fractional parts.
5.You can use any formula(and using multiple formulas provides best convergence btw) to generate numbers, as long as its variables are compact:x*(j^c),x^y mod N, (x^y)*(v^c), (k^m)/(u^g)
and the result must fit into search space:example here:
file is integer 9
floatingpoint space 9.000... to 9.999......
with multiplication by constant(e.g. 100) 900.000... to 999.999....
with multiplication by formula(e.g. 2.45^7.1+1):5224.809348679253 to 5805.343720754726
 
____________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
What Djisktra thinks of machines that could think is as relevant today as Algol Programmer's Guides

Sage for FV.

>>7
ENTERPRISE COUNTING ARGUMENT

a 10MB file
yeah that's real useful-like when discussing compression algorithms.

You are aware modern compression algorithms are better than this, yes?

>>10
Merely to illustrate the insane amount of time it takes to decompress my good friend. I really meant something along the lines of "capable of compressing files to ~40% of their original size" since file size doesn't have any effect with mine (unless you get to ~< 100kb).

>>11
I'm not really into this sort of thing - so I wouldn't know, it was just a "could this really work?" on an idea I had.

I did think that getting to 40% of the original size was pretty good since I thought RZip only got around 65-70% usually.

The whole point of this thread was that the decompression times are HILARIOUSLY BAD, and it is kind of dissappointing that people seem to be taking this so seriously.

>>13 here
I know RZip isn't a compression algorithm, though I realise it sounds like I said that.

>>13
The whole point of this thread was that I am a MASSIVE TROLL, and it is kind of dissappointing that people seem to be taking this so seriously.

>>15
What makes you think he's trolling? I thought it was funny.

>>8
☣ Please try to ignore troll posts! ☣

http://userscripts.org/scripts/show/52726

Hi /prog/,

I just finished on my "proof of concept" of a new compression algorithm, and frankly it's awesome.

File with 100MB of white noise compresses to 10MB. I think Claude Shannon is an idiot.

It's awesome right? I'm not posting code because it's so good you'll steal it.

>>18
Maybe you never finished reading OP - It's useless, noone is going to wait a month to restore from backup just for an extra 20% compression.

>>18
Thread Title: Shitsux
OP: I had the shittiest idea ever isn't that awesome
/prog/: You're too full of yourself you shitty troll

???

>>19,20
You two want me to share my invention, don't you?!

Oh, and,

>>1,18,19
SPAWHBTC

Post your algorithm so that we can analyze it, otherwise you're a big fat liar.

>>19
Maybe you never started reading OP - It's useless, noone is going to wait several times as long to create a backup just for it to be several times as large.

>>22
Okay you got me or whatever I'm leaving now.

>>19
Maybe you don't understand compression.

Hey guys, >>1's codec scheme is so awesome, it's gonna become a fundamental part of Hurd and Duke Nukem Forever.

>>26
(Score:5, Funny)

>>26
But only if Duke Nukem Forever comes with WinFS support!

Compression; People always talk about counting argument,entropy and other esoteric stuff while
using archived files daily. Especially one stupid argument i hear is "You can't compress purely random data!"
Which is so silly, since 'purely random data' is worthless as output.


________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Experience is never limited, and it is never complete; it is an immense sensibility, a kind of huge spider-web of the finest silken threads suspended in the chamber of consciousness, and catching every air-borne particle in its tissue.

>>29
Wtf. Pigeonhole principle, dude. Look it up.

>>29
Oh, so you think entropy is bullshit? If that's the case then please design a lossless compression algorithm that can indefinitely take its own output as input and always produce a considerable compression ratio.

Yeah, true random data can't be compressed to any useful degree because it doesn't contain enough redundancy. Note that it doesn't need to be actual random data. The output of a compression algorithm has enough entropy to be considered random, and an untrained eye can't distinguish the two.

>>17
Thanks.

>>31 Random means "I can't find order in this information" e.g. unsorted list
Entropy means "This ``random' information is magically different from all others" like prime numbers


______________________________
http://xs135.xs.to/xs135/09042/av922.jpg
You're supposed to be developing verbal abilities for your big aptitude test tomorrow.

>>33
lolwut

>>34
Information with high-entropy vs Random.

__________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
A sword is never a killer, it's a tool in the killer's hands.

>>33
No, that's completely incorrect.
Entropy is nothing more than a measure of randomness. Also your example is retarded.

[1111111121111111] is an unsorted list of numbers, but it's not very random.

>>36
It could be random in context of a billion numbers of such length.

________________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Once a man has changed the relationship between himself and his environment, he cannot return to the blissful ignorance he left.

>>37
which is it, a billion numbers or of such length?

e.g.
[1111111121111111] list 1
[1111111111121111] list  2
[1211111111111111] list  3...

________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Having dreams is what makes life tolerable.

>>39
But the measure of entropy obviously depends on the size of the sample.
0 is not at all random, but 068048180605 is. The entropy of the whole is independent of the entropy of its parts.
Your example is invalid in the sense that [1111111121111111][1111111111121111][1211111111111111] is a different set than [1111111121111111].

>>40 Its the same list, with 2 in different places.



___________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
If there is no struggle, there is no progress.

>>40
☣ Please try to ignore troll posts! ☣

http://userscripts.org/scripts/show/52726

>>42
If I didn't want to reply to trolls, I wouldn't come to /prog/.

>>42
☣ Please try to ignore troll posts! ☣

>>43
Then don't!

>>45
But I do! Both!

>>46
Now you have two problems.