Re:Badass compression algorithm?
on
Share The Pi!
·
· Score: 1
It's already been established that noting the position of string N of length L takes up (on average) L digits, and then you have to add the actual length to the whole thing. (ex - You find DeCSS at position X, and it takes up 5000 digits or some such.)
Here's an idea: Let's say I'm searching for the value 8362620110. That's a nice weird number with no signifigance at all. So we find it at some location of about 10 digits length. Now, let's go back before that and search for the first value that _doesn't_ contain the digits 83 until my value. Small enough? Keep going back looking for the smallest value that doesn't contain 836 until my value. Distribute offset, length, and minimum number of search tags.
The problem is that, in the end, probability wins, and it all comes out with you either losing space or breaking even.
Possible encryption and/or compression
on
Share The Pi!
·
· Score: 1
So, if pi contains every base 10 string of length n at offset x, at what point do the strings become longer than the offsets? In other words, if I was searching for the base 10 representation of the 9000 names of God (a fairly long string) what is the possibility that I could represent it as an offset within Pi and save space?
If nothing else, this seems like a fairly neat method of encryption, but seems to have very little practical application. Eh, someone probably already said all of this. In fact, this message can be found at Pi offset 386512308951618357012834565.
Slashdot Mirror
It's already been established that noting the position of string N of length L takes up (on average) L digits, and then you have to add the actual length to the whole thing. (ex - You find DeCSS at position X, and it takes up 5000 digits or some such.)
Here's an idea: Let's say I'm searching for the value 8362620110. That's a nice weird number with no signifigance at all. So we find it at some location of about 10 digits length. Now, let's go back before that and search for the first value that _doesn't_ contain the digits 83 until my value. Small enough? Keep going back looking for the smallest value that doesn't contain 836 until my value. Distribute offset, length, and minimum number of search tags.
The problem is that, in the end, probability wins, and it all comes out with you either losing space or breaking even.
So, if pi contains every base 10 string of length n at offset x, at what point do the strings become longer than the offsets? In other words, if I was searching for the base 10 representation of the 9000 names of God (a fairly long string) what is the possibility that I could represent it as an offset within Pi and save space? If nothing else, this seems like a fairly neat method of encryption, but seems to have very little practical application. Eh, someone probably already said all of this. In fact, this message can be found at Pi offset 386512308951618357012834565.