Is it even proven that every finite sequence of digits exist somewhere in pi? about pifs

[TheInvoker]

There is a math stack exchange post that says basically, that this project is a joke (see accepted answer)

http://math.stackexchange.com/questions/1771771/how-to-find-sequence-of-digits-in-pi/1771809#1771809

because for practical reasons, the compression value itself would be larger than the file you are trying to compress because the start index would be so big, also for other reasons described there.

Would you agree with that post?

[vndmtrx]

Best response

http://www.askamathematician.com/2009/11/since-pi-is-infinite-can-i-draw-any-random-number-sequence-and-be-certain-that-it-exists-somewhere-in-the-digits-of-pi/

[vndmtrx]

Also very instructive

http://math.stackexchange.com/questions/216343/does-pi-contain-all-possible-number-combinations

[TheInvoker]

So if its not proven and we just think that it's the case, there's no guarantee that what you want to compress will even work. Also, even if the finite sequence were to exist, how does this program even find the starting index without trial and error brute force? How does it do this http://www.angio.net/pi/piquery basically?

[vndmtrx]

Basically, it inferred that because it is an endless and randomly distributed sequence, there is a probability of finding a finite sequence within this, given the existence of enough time and computational factor to integrate up to the point to locate this finite sequence, as we can not prove its non-existence because it would be necessary forever integrate this number.

In particular, if we generate a number from an infinite stream of digits selected uniformly at random, then there is a probability of 100% that such a number contains each and every finite sequences of digits. Your statement remains true, we can't prove it unless we run all of the pi number. The only true statement is that a normal number cannot contain another normal number as a subset, but I can't present this proof by now.

https://en.wikipedia.org/wiki/Normal_number

[vndmtrx]

About the query, it simply does an integral math on the number and extract the sequence by brute force. When he located the sequence, the contained information it's more easily calculated with the position and offset of the sequence.

This, if we use a easily mathematically calculated normal number, like pi, sqrt(2) or e, for example. Since we don't know the problem extension, we can't even assure how is the Big-O notation for this, or for any other number, and even if we can find the related sequence on the normal number.

So, essentially this is a logic statement that we can't directly verify, but we can play with the idea.

[vndmtrx]

Yes, it is a joke, on the fact that we can't even prove if it coalesces into something palpable...

[vndmtrx]

In the fact, it doesn't compress anything, it simply stores it by provide a index and offset of the finite sequence we are searching, into the infinite normal set. The "compression" factor exists in the only need to store the index and the offset (and the integration formula) outside.

[vndmtrx]

In some (in fact, many) cases, the index number could be greater than the "encoded" itself. So, the fact remains that we can't consider it as "compression" but "store".

[TheInvoker]

So on the home page it says like They said 100% compression was impossible? You're looking at it!, but really its more like almost all of the time, increasing the size needed to store the new data...lol

[vndmtrx]

I think this can be used in a sort of encryption, since if we hide the normal number / integration formula, we can easilly create a good crypto system, based on the indexes and offsets. This virtually cannot be targeted by frequency analysis in a traditional way, IMHO.

[TheInvoker]

I think it becomes a good practical idea in the sense that it's not meant for compression but more for something like encryption.

[sam3d]

@isapol what do you reckon?