Compress 7G to 1K with epic vaporware • Hacker News Board

Re: Compress 7G to 1K with epic vaporware

#31

Post by wiml » Sat, Nov 23, 2013, 4:17 AM UTC

patricklorio wrote: post #17

phaed wrote: post #7

Here are more details: 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…

Wouldn't that just be multiplexing on steroids?

You could almost call it ... dense wavelength-division multiplexing.

Re: Compress 7G to 1K with epic vaporware

#32

Post by chalkhed » Sat, Nov 23, 2013, 4:31 AM UTC

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.

Re: Compress 7G to 1K with epic vaporware

#33

Post by ibudiallo » Sat, Nov 23, 2013, 4:36 AM UTC

I read 7G without thinking twice, i thought it was the same 3G,4G,5G marketing terms. then ... wait a minute.

Fun read though.

Re: Compress 7G to 1K with epic vaporware

#34

Post by evanphx » Sat, Nov 23, 2013, 4:41 AM UTC

X4 wrote: post #23

thetwiceler wrote: post #19

Earlier quoted context omitted.

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]. [1] http://en.wikipedia.org/wiki/Shannon's_source_coding_theorem

I hate to break it to you, but if super massive black holes exist, it is maybe possible. (Curious, if this is wrong or can be broken too)

Not if the center of a black hole contains a Einstien-Rosen bridge, then the information is transmitted elsewhere.

Re: Compress 7G to 1K with epic vaporware

#35

Post by desijays » Sat, Nov 23, 2013, 4:41 AM UTC

X4 wrote: post #18

Everlag wrote: post #9

Earlier quoted context omitted.

"Spectrocable, data transfer will be instantaneous" So... he solved the issue of going past the speed of light? I think the DOD just found their MVP for the next 10 000 years for he shall sit upon a golden throne and rule mankind with that kind of intellect.

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

I read that too. I agree..what that Indian student did, is a load of crap..

Re: Compress 7G to 1K with epic vaporware

#36

Post by davvid » Sat, Nov 23, 2013, 4:41 AM UTC

gpcz wrote: post #21

DoggettCK wrote: post #16

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…

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, y…

25 is a small number. Would it make a difference with (much) larger ones?

Re: Compress 7G to 1K with epic vaporware

#37

Post by ricardobeat » Sat, Nov 23, 2013, 4:43 AM UTC

X4 wrote: post #18

Everlag wrote: post #9

Earlier quoted context omitted.

"Spectrocable, data transfer will be instantaneous" So... he solved the issue of going past the speed of light? I think the DOD just found their MVP for the next 10 000 years for he shall sit upon a golden throne and rule mankind with that kind of intellect.

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

You mean this: http://en.wikipedia.org/wiki/Rainbow_Storage

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.

Re: Compress 7G to 1K with epic vaporware

#38

Post by gpcz » Sat, Nov 23, 2013, 4:51 AM UTC

DoggettCK wrote: post #24

gpcz wrote: post #21

Earlier quoted context omitted.

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, y…

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. Kinda doubting it now, though.

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.

Re: Compress 7G to 1K with epic vaporware

#39

Post by datphp » Sat, Nov 23, 2013, 4:58 AM UTC

thetwiceler wrote: post #19

datphp wrote: post #8

It's always April 1st somewhere! 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…

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]. [1] http://en.wikipedia.org/wiki/Shannon's_source_coding_theorem

"I don't understand what you're saying, but you're wrong"

Re: Compress 7G to 1K with epic vaporware

#40

Post by fisadev » Sat, Nov 23, 2013, 5:04 AM UTC

This guy knows everything. From quantum mechanics (http://www.linkedin.com/pub/nicolas-dupont/79/217/325), to wedding journalism (https://nppa.org/profile/XtremlyGeeky)... while still attending to highschool.