(no subject)

[arethinn]

http://www.qwantz.com/index.pl?comic=354

Does that even make sense? Would it work? (not that it's practical, but just in the "proof of concept" sense)

Comments

[mmsword.livejournal.com]

Technically... Yes. It's possible. But it would require a very tight system, still be prone to a lot of errors (Heaven forbid your bit didn't get there at precisely the right time), and overall would it be more work then it's worth. Also, writing the interpeter to do that would be a pain in the arse.

[soundwave106.livejournal.com]

It would work, but it would be impractical. It's definitely not data compression.

You can't *store* this data, as you would need to store the "tick" value of the endpoint. This would have to equal the resolution of the massive number the file size represents.

You can't use this for communication, as the range of ticks is very large. A simple eight byte file represents a maximum numeric value of 18,446,744,073,709,551,615. So you can transmit a start bit, but you'll have to wait possibly that many ticks just to get to the end point. Far simpler to transmit 8 on and off pulses, then wait for a pulse and count the ticks based on synchronized timers (which are based on pulses anyway). The "tick" algorithm only becomes efficient when the byte sum is below 8, which won't be very often.

Data compression tends to involve looking for matching patterns within the data.

[featheredfrog.livejournal.com]

don't forget, the clocks have to be synchronized. this itself is likely to impose a data-transfer overhead, thus, not "two bits"...

This is like being able to encode all the information in the universe on a one-meter rod: just inscribe a mark such that the ratio of lengths of the two parts is the irrational number that represents the byte-stream as a decimal. Of course, you'd have to make the incsribed mark many many orders of magnitude smaller than the smallest subatomic particle, and there's the problem of MEASURING the lengths...

[baxil.livejournal.com]

What xe said. The first thing that leapt into my mind when I read it was how useless it would be for data of any useful size.

Let's say that the tick interval is in milliseconds. iirc there's (pi * 10^8) seconds in a year and 10^3 ms in a second; so waiting for a whole year allows you to send a number of up to ~10^12 (all numbers from here on out rounded to order of magnitude, making charitable assumptions toward feasibility). One byte is 8 bits = 2^8, which is greater than 10^2. So two bytes of data = 2^8 * 2^8 > 10^4, etc.

Your data transmission rate thus has an upper bound of 6 bytes per year.

On the other hand, you could modify this technique to get reasonable throughput, if there really was some weird circumstance that made transmission of bits hideously expensive. Just break the data down into, say, byte-sized chunks; send a single bit as a start bit at T=(-1), and then send a second bit somewhere in the range of T=0-255, which resets the timer to -1, rinse, lather, repeat. You are transmitting 8 bits of data per bit sent (plus the first bit's initial cost) and the throughput, assuming your tick is a millisecond, is no worse than 32 bits/sec, about 1.5% the speed of a 2400-baud modem.