I had an idea awhile back about treating large files as insanely large hex integers, then dividing that by a huge known prime, and basically storing 3 smaller integers that plug into the equation "ax + b", where x is the known prime, a is what you found when doing the division, and b is the remainder. Plugging those numbers into the equation would give you the huge integer representing the original file.
I'm assuming the known primes would be in a database somewhere, and you could just use the indices, instead of some 512-digit number.
The process could be repeatable if 'a' was too big, theoretically enabling some extreme compression.
You'd need a way to handle extremely large ints, and in the few minutes I thought about it, you'd need at least twice the original file size available for compression/decompression.
I'm also pretty sure my idea is full of shit, but there are more details than in the article.
Let's try your algorithm with the number 25 (11001 in binary).
One formulation is 2(11)+3. The primes up to 25 are 2,3,5,7,11,13,17,19,23, so we'll use the index 4 to represent the prime number 11.
To lay this out, we need to represent three numbers: 2, 4, and 3. Without the inevitable markings you'd need to delineate when numbers started and stopped, the bit string would look like 10 100 11.
Using 11 as the prime, your compression would require laying out 1010011 to represent 11001, which means it's actually anti-compression.
Like I said, probably full of shit, but I think of odd stuff in the shower.
With really, really huge (like the aforementioned 7GB) numbers, you might see something better, sort of how there's a point with most compression methods that the header is bigger than the data being compressed.
I wrote a little Python program that lets you try it with an arbitrary integer. It assumes that for instances where you have to lay out a zero that you need one bit (for 0).
This times out quickly if you use too big of a number, but you can play around with integers here:
http://codepad.org/4mnHI9E3
Based on what I see, it compresses poorly at the beginning and then reaches parity. At 1,000,000 (tested on my machine, not Codepad since it times out), you get one bit of profit, but 1,000,005 is at parity, suggesting that it's not very stable.
Also, this is assuming that the decompressor can make sense of the absolute smallest representation you could lay out these numbers with, which is basically not going to happen. That additional padding would destroy any potential savings you got.
Spectrocable, his first invention to be launched and brought to market, is a new optical fiber system that uses 16 million different colors to increase data transfer speeds significantly, compared to technologies on the market today. With Spectrocable, data transfer will be instantaneous which will revolutionize the way we use the internet and share information. For example, the entire 40TB of the Library of Congress could be downloaded in less than half a second. At Techweek Los Angeles, Dupont will be demoing this technology and revealing how it works for the first time with a working prototype.
hahaha, fun how this thread turns out. But keep in mind: Using R/G/B Lasers won't increase the speed of light, so don't try to debunk BS with BS.
I have read about an indian student 4y ago who invented a geometrical compression algorithm that could save about 80GB onto an image, the size of an A4 document. Never heard back from him
It does work, he just slightly overestimated the maximum density :) There is an open-source implementation (http://ollydbg.de/Paperbak/) that stores ~3mb per page.
Yes and can theoretically increase the bandwith, but light is a wave function and I don't understand the quantum physical part (regarding observer dependent particle/wave formation) to tell, if it could work or not.
"Born in 1999, Nicolas Dupont is currently a high school student attending a prominent Preparatory School in Central Florida. This young prodigy, founder of Cyborg Industries, will be unveiling his four groundbreaking innovations during his unique session at Techweek LA. These innovative inventions will launch the start of a new era in computing, and will offer instantaneous data transfer, limitless data compression, and truly unbreakable encryption. Nicolas will be hosting his session at 2 PM, on November 21st, where he will be revealing his revolutionary technology for the first time ever. Solely developed by Nicolas, these innovations and inventions will provide multiple markets with a truly limitless technology."
I'm all for teenage entrepreneurship and research but... this honestly sounds like the fellow who reads a single computer science text books then has all the answers to those silly issues that have been facing humanity for eternity.
Perhaps he found a way to encode data in neutrons ala Diaspora?
In diaspora, a novel by Greg Egan that I'd heavily recommend if you like insane physics in the post singularity world, an incredible amount of data is encoded onto a single neutron which can then be decoded at realtime. We're talking about Terabytes of data at the minimum on a neutron.
Edit: I've once thought of a system which would allow virtually unlimited compression, the only drawback is that it would take an insane amount of time to execute.
Imagine a chess board, a 8x8 grid of alternating black and white tiles. Now you write an algorithm that performs permutations, 2 by 2, 4 by 4, etc, in a predefined order.
If you do enough permutations, at some point you're going to have all the white tiles on one side of the board, and the black ones on the other side.
You can now store your board as its size, 2 expressions representing the 2 halfs, and the number of permutations you need to reach the original state.
Looking forward to additional info on this joke/hoax!
I hate to break it to you, especially since I don't exactly understand the scheme you're describing, but "virtually unlimited compression" is impossible [1].
Such kind of jokes isn't completely useless if recall "Noise level" by Raymond Jones )
By the way the most unrealistic promise is compression of congress library, because the data is determined.
If kind of video or audio data is not determined (it may be year of black screen or zooming in-out mandelbrot) limitless compression rates is possible.
It's interesting that his claim on possible bitrate for wireless is 10^55000 bits per second while the cable bitrate is 10^54000 bits per second. Wonder what he actually talked about at techweek and if anyone bought it.
I'm assuming the known primes would be in a database somewhere, and you could just use the indices, instead of some 512-digit number.
The process could be repeatable if 'a' was too big, theoretically enabling some extreme compression.
You'd need a way to handle extremely large ints, and in the few minutes I thought about it, you'd need at least twice the original file size available for compression/decompression.
I'm also pretty sure my idea is full of shit, but there are more details than in the article.