Wiemy, że π jest nieskończone i całkiem prawdopodobne, że zawiera każdy możliwy skończony ciąg cyfr ( sekwencja rozłączna ).

Ostatnio widziałem prototyp πfs, który zakłada, że ​​każdy plik, który utworzyłeś (lub ktokolwiek inny) lub utworzysz, już tam jest, więc jest to kwestia wyodrębnienia go. Istnieje również piFile, który może konwertować pliki do metadanych pi.

Istnieje już formuła typu BBP (jako część matematyki eksperymentalnej), która pozwala nam obliczyć n- tą dwójkową cyfrę pi. Przechowując pozycję początkową i długość danych, teoretycznie możemy wyodrębnić dane, które nas interesują. Istnieją argumenty przeciwko temu, że nasze metadane (np. Przesunięcie w stosunku do naszych danych) mogą być większe niż wyodrębnione dane. Symbole macierzy i π można zakodować w bazie-256, aby uczynić ją bardziej wydajną (patrz żart ).

W oparciu o powyższe moje główne pytanie brzmi:

• Czy są jakieś algorytmy kompresji oparte na PI?

Jeśli nie, czy ma to sens? A może były jakieś badania w tej dziedzinie?

A może π nie jest właściwy, więc co ze stałą Eulera lub Tau (τ)? Czy to coś zmieni?

^{Zdjęcia: Dinosaur Comics}

Zobacz też:

• Czy dowolny skończony ciąg bitów można znaleźć w liczbie pi w rozsądnym czasie? w SO
• Czy przechowywanie indeksu w π nie byłoby tak duże (lub większe) niż oryginalne dane? w GitHub

Twoja sugestia nie ma większego sensu z wielu powodów. Przede wszystkim, gdy próbujesz skompresować duży plik, powiedzmy plik o rozmiarze bajtów, będziesz musiał znaleźć miejsce w binarnym rozszerzeniu które zgadza się z twoim plikiem. Ponieważ plik ma długość bitów, można oczekiwać, że miejsce to będzie około . Trudno byłoby więc znaleźć. Nie tylko dlatego, że musimy przejść daleko do rozszerzenia, ale także dlatego, że spodziewamy się wypróbowania różnych lokalizacji przed znalezieniem trafienia.$16$$\pi$$128$$2^{128}$$2^{128}$

Po drugie, podczas gdy w niektórych przypadkach twój schemat spowoduje znaczną kompresję, stanie się to tylko wtedy, gdy określony ciąg pojawi się stosunkowo wcześnie w rozszerzeniu . Nie ma powodu, dla którego chciałbyś kiedykolwiek kompresować taki ciąg. Natomiast inne algorytmy kompresji próbują znaleźć strukturę w danych i mają gwarancje, które pokazują, że jeśli taka struktura istnieje, to zawsze mogą ją wykorzystać.$\pi$

Zmieniam$\pi$ z dowolnym innym numerem nie zmieni obrazu. Algorytm jest zbyt specyficzny, kompresuje tylko ciągi, które tak naprawdę nas nie interesują; i bardzo nieefektywny w fazie kompresji.

Na podstawie odpowiedzi Yuvala, z nieco innym wyjaśnieniem i przykładem, który pomoże wyjaśnić problem.

Teoria

$16$$128$

1. $\pi$
2. $128$

$2^{128}$

• głębokie poszukiwanie wzoru bitowego; i
• $2^{128}$

$\pi$$\pi$

Zobacz także, entropia informacji .

Przykład

$log_2(938933556)$$29.8$$30$

$\pi$$597,507,393$$log_2(597507393)$$29.2$$30$

Może możemy poruszyć liczby?

• $1,124$
• $1,216$
• $11,727$

$36$

• $15,312,393$
• $8$

$27$$30$

$N$

Czy są jakieś algorytmy kompresji oparte na PI?

tak, https://github.com/divinity76/pi_compression

czy ma sens?

nie, przechowywanie przesunięć zwykle zajmuje więcej miejsca na dysku niż oszczędzasz, przynajmniej przy powyższej implementacji (3 znaczące rzeczy, które można poprawić, ale bierze pod uwagę tylko pierwsze 2 ^ 32 bajty binarnej reprezentacji pi, i to używa nadmiernej ilości bitów do przechowywania liczby pasujących bajtów na przesunięcie, a mianowicie 8 bitów, podczas gdy testy pokazują, że 3 bity byłyby optymalne, i bierze pod uwagę tylko dopasowanie pełnych bajtów, więc jeśli gdzieś jest dopasowanie 15 bitów, to będzie traktowane jest tylko jako dopasowanie 8-bitowe. także, jeśli ostatnie 4 bity bajtu pasują, ale nie bit # 3, i pierwsze 4 bity kolejnych pasujących bajtów, ale nie bit # 5, to nie jest uważane za dopasowanie przy wszystko)

A może były jakieś badania w tej dziedzinie?

uhm jasne, dlatego napisałem powyższą implementację, a wyniki wydają się być takie, że w ciągu pierwszych 4 GB pi, prawdopodobnie znajdziesz 4 pasujące bajty .. prawie wszystkiego, co jest bardzo trudne, jeśli nie niemożliwe, aby uzyskać kompresję, przynajmniej mi się nie udało. (ale moja implementacja nie jest optymalna, jak wyjaśniono powyżej) - również kompresja jest bardzo powolna, ale moja implementacja jest jednowątkowa, ale algorytm pozwala na wielowątkowość, jeśli ktoś mógłby arsesować pisać kod, co pozwoliłoby na skalowanie wydajności za pomocą liczba dostępnych rdzeni.

dekompresja jest jednak bardzo szybka.

Czy są jakieś algorytmy kompresji oparte na PI?

$\pi$$\pi$

$X$$\pi$$X$

$\pi$$\pi$

nawet jeśli wykazano, że jakakolwiek stała matematyczna ma niezwykłą właściwość „zawierającą wszystkie ciągi”, prosty argument polega na tym, że algorytm kompresji poświęciłby „zbyt dużo czasu” na szukanie pozycji ciągu, a opisanie jego położenia często wymagałoby długi (er) ciąg cyfr.

patrz także / kontrast / spróbuj pogodzić z podobnym pytaniem o wysokim głosowaniu, w jaki sposób można zadecydować, czy pi zawiera pewną sekwencję cyfr . (cs.se) (wskazówka: tytuł można uznać za nieco mylący)