91–100 of 150 posts
Earlier quoted context omitted.
> Or the machine language expression of the most advanced expert systems, though by then the notch might be small enough that Planck’s constant got in the way. With Planck's length being roughly 10^-35m, I'd say you'd hit the limit trying to store more than 15 bytes.
Also depends on the length of the metal rod, doesn't it?
Earlier quoted context omitted.
> Or the machine language expression of the most advanced expert systems, though by then the notch might be small enough that Planck’s constant got in the way. With Planck's length being roughly 10^-35m, I'd say you'd hit the limit trying to store more than 15 bytes.
This is insightful. 15 bytes is not a lot. I wonder what are other narural limits on information density? For example, magnetic field. Is there a least measurable difference?
Earlier quoted context omitted.
Did you proove it formally or only by experiment. If it were a real proof, did you publish it somewhere?
In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input. The best you can hope for is an algorithm that compresses the kind of data that humans want to store, at the expense of making other data a bit longer. If you're trying to compress random data then you just can't do it. Here's a proof: consider the strings of length n or less, suppose there are…
I don't think this is true. If it was, lossless compression would be useless in a lot of applications. It's pretty easy to come up with a counter example.
E.g.
(simple huffman code off the top of my head, not optimal)
symbol -> code
"00" -> "0"
"01" -> "10"
"10" -> "110"
"11" -> "111"
If "00" will appear 99.999% of the time, and the other 3 symbols only appear 0.001% of the time, the output will "on average" be slightly more than half the length of the input.
Earlier quoted context omitted.
In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input. The best you can hope for is an algorithm that compresses the kind of data that humans want to store, at the expense of making other data a bit longer. If you're trying to compress random data then you just can't do it. Here's a proof: consider the strings of length n or less, suppose there are…
>In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input I don't think this is true. If it was, lossless compression would be useless in a lot of applications. It's pretty easy to come up with a counter example. E.g. (simple huffman code off the top of my head, not optimal) symbol -> code "00" -> "0" "01" -> "10" "10" -> "110" "11" -> "111" If "00" wi…
Earlier quoted context omitted.
>In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input I don't think this is true. If it was, lossless compression would be useless in a lot of applications. It's pretty easy to come up with a counter example. E.g. (simple huffman code off the top of my head, not optimal) symbol -> code "00" -> "0" "01" -> "10" "10" -> "110" "11" -> "111" If "00" wi…
Sure, I'm assuming that (a) you are trying to encode all strings of length at most n and (b) you have the uniform distribution over those strings. This makes sense in the original context of encoding random data.
Lossless compression is nothing more than taking advantage of prior knowledge of the distribution of the data you are compressing.
Random data isn't always (or even often) uniformly distributed. Everything we compress is "random" (in the context of information theory), so I disagree that it makes sense to assume uniformly distributed data.
Earlier quoted context omitted.
Sure, I'm assuming that (a) you are trying to encode all strings of length at most n and (b) you have the uniform distribution over those strings. This makes sense in the original context of encoding random data.
>you have the uniform distribution over those strings. This makes sense in the original context of encoding random data. Lossless compression is nothing more than taking advantage of prior knowledge of the distribution of the data you are compressing. Random data isn't always (or even often) uniformly distributed. Everything we compress is "random" (in the context of information theory), so I disagree that it makes s…
This reminds me a bit of the science of nanoinformatics as described in one of the Expanse novellas (The Vital Abyss): " A thought experiment from my first course in the program: Take a bar of metal and put a single notch in it. The two lengths thus defined have a relationship that can be expressed as the ratio between them. In theory, therefore, any rational number can be expressed with a single mark on a bar of met…
As if this were a practical means of storing data.
Earlier quoted context omitted.
In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input. The best you can hope for is an algorithm that compresses the kind of data that humans want to store, at the expense of making other data a bit longer. If you're trying to compress random data then you just can't do it. Here's a proof: consider the strings of length n or less, suppose there are…
>In fact, any lossless compression algorithm has the property that the output is (on average) at least as long as the input I don't think this is true. If it was, lossless compression would be useless in a lot of applications. It's pretty easy to come up with a counter example. E.g. (simple huffman code off the top of my head, not optimal) symbol -> code "00" -> "0" "01" -> "10" "10" -> "110" "11" -> "111" If "00" wi…
Earlier quoted context omitted.
>you have the uniform distribution over those strings. This makes sense in the original context of encoding random data. Lossless compression is nothing more than taking advantage of prior knowledge of the distribution of the data you are compressing. Random data isn't always (or even often) uniformly distributed. Everything we compress is "random" (in the context of information theory), so I disagree that it makes s…
Then the original statement about not being able to use pi as a data compression method is false. It could be the case that 99% of the time you want to encode the string "141592653".