What if it was real?
Add a string, and this post would be a 2TB porn collection.
TCP-Infinite, every packet=entire file.
Hard disks would drop in price after IC filesystems appear.
You could tell someone a code for entire warez site and he could enter it and decompress the results.
Packet Radio all around the world/space at infinite bandwidth.
HD videos downloaded and streamed in microseconds.
An entire wikipedia could be edited in memory and saved into a single string, taking near zero space.
Books and DVDs becomes completely obsolete.
What else could be possible?
Name:
Anonymous2011-10-01 11:28
The only problem would be the infinite time needed to decompress it.
>>7
In a way, yes, but in practice, no.
For example, you could generate all possible data by starting from 0 and getting next successor of that number (and so on, infinitely). However, your data is precisely its address.
Think of it in a different way as well: if you had the exact laws of physics that govern this (multi)verse, you would be able to generate everything that exists within it, but you would require immense amounts of memory to hold it (bigger than what can exist within this particular universe), not to mention immense amounts of time to find the data that you're looking for. If given an address, the adress may even be bigger than the data that you're looking for, depending on what it is you're looking for.
What if you don't know the laws? All possible programs are enumerable (you can assign a natural number to each of them). You could even run all possible programs (and thus all computable universes), this is traditionally modeled using what is called a ``Universal Dovetailer'' (a program that runs a step from program 0 for time 0, then it runs the next step from program 0 and step 0 from program 1 for time 1, and so on (think of it as a scheduler which launches the next program each step)), such dovetailer may even contain self-aware substructures such as ourselves within it.
In a way, this means you require 0 bits to store all that can possibly exist, as long as non-computable objects don't exist (an example would be various real numbers which cannot be expressed algorithmically). However, finding what you want within such an infinite object may very well take a very long amount of time that it is not feasible to use it for the task that you seek (the amount of time should be finite, but incredibly long, as long as you don't ask an uncomputable question).
You could use more than one hash alg, or a few different salts?
i'd bet brute-force decompression would be rather slow, if not nearing impossible for large enough data though
Hash small chunks of data at a time, with small & simple hashes? Eg. aa bb (x) bb cc (y) cc dd (z) doubling up values [bb cc (y)] might help a bit with collisions, and using a fairly small number of bits per chunk might even make it feasible to reverse? plus integrity checks are as easy as hashing aa bb cc dd -> (w) with one or more salts..
Name:
Anonymous2011-10-02 3:10
I have an idea
(2 different hashes(less sollisions)+Filesize(disambig. between various files))
Hashes chosen to be easily bruteforceable, not like that SHA crap which takes years on a normal CPU.
If it can compress most things to 10% or less, and get it back again (preferably quick) that would be pretty good / as good as the best compressions in recent times (~'05?)
Name:
Anonymous2011-10-02 11:02
Can you store 8 bits in 7? I don't think so. 2^7 inputs will yield 2^7 outputs.
You can predict with high accuracy what is the 8th bit, but never store it in 7(lossy compression vs lossless).
Name:
Anonymous2011-10-02 11:08
>>15
zipped files are more random. If there was a function which changes zipped file entropy to be less random, it can be zipped again and again.
Only thing to store additionally is function parameters for each change(very small compared to the entire file).
Shit, I don't know man. Maybe you could, like, make each bit bigger. So instead of just being "on" or "off", it could be like "blue", and "repeat this". And then, like, you wouldn't need so many of them. That'd be pretty far out.
>>15
Actually you can store 2 + 2^2 + 2^3 + 2^4 .. + 2^7 (=2^8 -1) in seven or less bits, but you need extra data to specify the length(s)... which typically does bring it back to eight bits