Ya know, I don't think he does get that part yet.<br><br>This scheme is essentially how data compression already works. Not in gigantic swaths of bits, as being proposed here, but in smalish numbers a few bits represents a bigger set of bits. Huffman coding is a basic example.
<br><br>The infeasability of this idea is all about the data size. As someone already pointed out 2^4000 is not 16,000,000 (that's 4000^2). 2^4,000 is large enough to just call it infinite and be done with it.<br><br>
For comparison, there's something like 2^100 to 2^130 or so atoms in the known universe. The hardware you'd need to implement a database of that size would require more matter than exists. Period.<br><br>This idea is only interesting if it works at the scale proposed. It doesn't. On a smaller scale, this is how data compression is already done.
<br><br>Rob<br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>On Fri, Jul 06, 2007 at 01:52:55 -0500, Dan Becker wrote:<br>> So we generate a packet using the idpacket field of a database to
<br>> describe which packets should be assembled in which order then send<br>> it. 1 packet to send 500.<br><br>Do you realize the id of the packet(s) would be equivalent to the contents<br>of the package(s)?<br><br>
See also <a href="http://en.wikipedia.org/wiki/Information_entropy#Entropy_as_information_content">http://en.wikipedia.org/wiki/Information_entropy#Entropy_as_information_content</a><br><br><br>_______________________________________________
<br>Full-Disclosure - We believe in it.<br>Charter: <a href="http://lists.grok.org.uk/full-disclosure-charter.html">http://lists.grok.org.uk/full-disclosure-charter.html</a><br>Hosted and sponsored by Secunia - <a href="http://secunia.com/">
http://secunia.com/</a><br></blockquote></div><br>