Jeszcze raz definicja:

f(x) = a/2*x+b/2 - gdy x jest nieparzyste
f(x) = x/2 - gdy x jest parzyste

Zjadłem znak dzielnika dla x parzystych.

do góry

W dniu czwartek, 5 grudnia 2019 03:11:18 UTC+1 użytkownik o...@g...com
napisał:
> > swoje droga esli to jest iteracja na stalej 2^128 - 5 to wynik konkretnej liczby
iteracji na tym (np 100) jest znany i nie trzeba tego liczyc wiec wyliczenie tego
wynosi 0 czasu (i dlatego tez niekonkretne pytaia sa nie tylko niecialawe ale i
denerwujace (ziew))
>
> To jest tylko część bardziej złożonego problemu nad którym się głowię. Może on wyda
Ci się ciekawszy. Rozważmy funkcje rekurencyjne o następującej definicji:
>
> f(x) = a/2*x+b/2 - gdy x jest nieparzyste
> f(x) = x2 - gdy x jest parzyste
>
> a i b to jakieś liczby nieparzyste, a x może być dowolną liczbą naturalną.
Określając a i b dostajemy jakiś ciąg zdefiniowany za pomocą funkcji rekurencyjnej.
Najsłynniejszym z nich jest ciąg Collatza, którego dotyczy nierozwiązania do dziś
hipoteza. Ciąg Collatza dostaniemy dla a=3 i b=1. Weźmy pary a, b z przedziału
(-7,-5, ..., 5, 7). Będzie ich tyle co wariacji z powtórzeniami, 2-wyrazowych, w
zbiorze 8-elementowym, czyli 64. Dla każdej z takich 64 par a i b mamy zdefiniowaną
jakąś funkcję rekurencyjną. To co chcę oszacować, to ile zajmie policzenie w każdej z
tych 64 funkcji n iteracji dla kolejnych liczb naturalnych z przedziału od 1 do 2^n.
Np. dla a=5 i b=3 oraz n=3 mamy do policzenia iteracje dla liczb 1,2,3,...,8:
>
> 1,4,2,1
> 2,1,4,2
> 3,9,24,12
> 4,2,1,4
> 5,14,7,19
> 6,3,9,24
> 7,19,49,124
> 8,4,2,1
>
> Rzecz w tym, że interesują mnie duże n, rzędu minimum 50, a najlepiej rzędu 100.
Nie wiem, czy to jest bardziej interesujące? Na pewno żaden komputer tego nie policzy
w żadnym czasie np. dla n=128. Łatwo policzyć, że, jeśli średnio taki ciąg jest
liczony np. przez 100 mikrosekund, to obliczenia dla 64 par a i b zajmą
64*100*1/1000000*2^128 sekund, czyli może jeszcze nastąpi to przed śmiercią cieplną
Wszechświata, a może nie. Dlatego trzeba policzyć średni przypadek i ten, który
podałem jest średnim przypadkiem, można bowiem udowodnić, że średnio w tych ciągach w
przedziale liczb od 1 do 2^n wystąpi tyle samo mnożeń z dodawaniem, co dzieleń.
Natomiast potrzebuję to oszacować, bo zamierzam stworzyć algorytm, który będzie się
wymagał obliczenia losowego x z przedziału od 1 do 2^n dla losowej pary a i b. I chcę
wiedzieć ile średnio zajmie to czasu. W szczególności jakie maksymalne n mogę
przyjąć, aby taki pojedynczy ciąg był liczony około 0,1 mikrosekundy.

dla mnie to wogole nie jest interesujace, a jesli chcesz odpowiedz to raczej staraj
sie zadac pytanie w jakis zachecajacy sposob (bez glupot i dziur logicznych oraz w
miare krotki i nie mulace - bo ludzie sa leniwi, zwlaszcza na starosc ;c)


jak oszacowac czas obliczen napisalem
takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb
calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na
dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy
pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez
2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z
15-20 cykli)

takie cos
> f(x) = a/2*x + b/2 - gdy x jest nieparzyste
> f(x) = x2 - gdy x jest parzyste

(w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma obcinac
bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie oszacowac
na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio optymistycznie)
(jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3 razy wolniej)

napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki - podejrzewam
ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie dawal
nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego - ale
jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w okolicach
kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w granicach
5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)

oczywiste jest ze nie w czasie tego kawalka jest problem tylko w tej kombinatoryce a
ja trzeba jakos optymalizowac w inny sposob (matematycznie, hackerskom itd..nie che
mis ie w to wnikac bo to za nudne dla mnie)

do góry

> dla mnie to wogole nie jest interesujace
Kwestia gustu, mnie fascynują te problemy, zwłaszcza, że mają istotne związki z
hipotezą Collatza. Chaos deterministyczny, Wolfram rules, automaty komórkowe - dla
mnie to wszystko ciekawe rzeczy.

> a jesli chcesz odpowiedz to raczej staraj sie zadac pytanie w jakis zachecajacy
sposob (bez glupot i dziur logicznych oraz w miare krotki i nie mulace - bo ludzie sa
leniwi, zwlaszcza na starosc ;c)
Nie wiem jaki to jest zachęcający sposób, ale wnioskuję, że po prosty zwięzły i
konkretny, to masz pewnie na myśli.

> jak oszacowac czas obliczen napisalem
> takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb
calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na
dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy
pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez
2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z
15-20 cykli)
Ok, rozumiem.

> takie cos
> > f(x) = a/2*x + b/2 - gdy x jest nieparzyste
> > f(x) = x2 - gdy x jest parzyste
>
> (w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma
obcinac bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie
oszacowac na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio
optymistycznie) (jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3
razy wolniej)
Ok, daje mi to jakieś ogólne pojęcie.

> napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki -
podejrzewam ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie
dawal nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego
- ale jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w
okolicach kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w
granicach 5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)
Rozumiem. Czyli wszystko w sumie rozbija się w tym przypadku o napisanie konkretnego
programu od A do Z i sprawdzenie tego. Dodam tylko, że nie umiem programować,
zapomniałem swój kurs programowania z podstaw w C ze studiów, nie pamiętam jak
uruchomić program, w czym to się kompilowało itd. Dlatego pytam Was i nie sprawdzę
sobie tego sam, dopóki nie zrobię solidnej powtórki. Poza tym chciałem mieć tylko
ogólne pojęcie nt. tego, czy realne jest zbliżenie się przy parametrze n=100 do
czasów 0,5 mikrosekundy. Wydaje się to być możliwe, ale tak na 100% nie wiadomo.

do góry

W dniu czwartek, 5 grudnia 2019 21:18:48 UTC+1 użytkownik osobliwy nick napisał:
> > dla mnie to wogole nie jest interesujace
> Kwestia gustu, mnie fascynują te problemy, zwłaszcza, że mają istotne związki z
hipotezą Collatza. Chaos deterministyczny, Wolfram rules, automaty komórkowe - dla
mnie to wszystko ciekawe rzeczy.
>
> > a jesli chcesz odpowiedz to raczej staraj sie zadac pytanie w jakis zachecajacy
sposob (bez glupot i dziur logicznych oraz w miare krotki i nie mulace - bo ludzie sa
leniwi, zwlaszcza na starosc ;c)
> Nie wiem jaki to jest zachęcający sposób, ale wnioskuję, że po prosty zwięzły i
konkretny, to masz pewnie na myśli.
>
> > jak oszacowac czas obliczen napisalem
> > takie proste obliczenie jak dodawanie, mnozenie, i dzilenie przez dwa dla liczb
calkowitych mozesz optymistycznie zalozyc zajmuja minimum jeden cykl procesora na
dzialanie, ale oprocz arytmetyki moga byc tez tam movy (nalezaloby to napisac przy
pomoy komend w asemblerze by to sobie zwizualizowac), dlatego jabym to pomnozyl przez
2 lub 3, do tego jesli mowa o ifie to ten juz sie robi duzo drozszy (powiedzmy z
15-20 cykli)
> Ok, rozumiem.
>
> > takie cos
> > > f(x) = a/2*x + b/2 - gdy x jest nieparzyste
> > > f(x) = x2 - gdy x jest parzyste
> >
> > (w zaleznosci od tego czym to naprawde jest, np czy to dzielenie przed dwa ma
obcinac bit..oraz czy przypadkiem nie da sie jakos usunac tego if) mozna zgrubnie
oszacowac na okolo 10 nanosekund (20-30 cykli) na iteracje (mowiac srednio
optymistycznie) (jesli mowimy o 64 bitowych intach, dla 128 bit bedzie chyab ze 2-3
razy wolniej)
> Ok, daje mi to jakieś ogólne pojęcie.
>
> > napisz kod w c i sprawdz czy dziala (tj czy daje wogole poprawne wyniki -
podejrzewam ze zanim go napiszesz to przejdziesz przez 15 wersji w ktorych bedzie
dawal nipoprawne ;c i jak juz bedziesz to miec to nie ma problemu ze zmierzeniem tego
- ale jesli chesz zgrubne oszacowanie to z ogory ci mowie takie rzeczy zajmuja w
okolicach kilkudziesieciu cykli na iteracje (w zaleznosci od szczegolow)czyli w
granicach 5,10,20, 30 nanosekund na iteracje (w zaleznosci od szczegolow)
> Rozumiem. Czyli wszystko w sumie rozbija się w tym przypadku o napisanie
konkretnego programu od A do Z i sprawdzenie tego. Dodam tylko, że nie umiem
programować, zapomniałem swój kurs programowania z podstaw w C ze studiów, nie
pamiętam jak uruchomić program, w czym to się kompilowało itd. Dlatego pytam Was i
nie sprawdzę sobie tego sam, dopóki nie zrobię solidnej powtórki. Poza tym chciałem
mieć tylko ogólne pojęcie nt. tego, czy realne jest zbliżenie się przy parametrze
n=100 do czasów 0,5 mikrosekundy. Wydaje się to być możliwe, ale tak na 100% nie
wiadomo.

z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile
to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie
scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne

wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest
glupkowate i przez to traci czas ludziom

jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos
mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno
tlum chetnych

do góry

W dniu czwartek, 5 grudnia 2019 21:18:48 UTC+1 użytkownik o...@g...com
napisał:
> > dla mnie to wogole nie jest interesujace
> Kwestia gustu, mnie fascynują te problemy, zwłaszcza, że mają istotne związki z
hipotezą Collatza. Chaos deterministyczny, Wolfram rules, automaty komórkowe - dla
mnie to wszystko ciekawe rzeczy.

nie watpie ;c problem w tym ze jak sie szuka odpowiedzi trzeba znalezc kogos koho to
interesuje lub zainteresuje a z tym w praktyce bywa ciezko ;< (co znam z zycia gdzie
wiekszosc ciekawych tematow trzeba robic zupelnie samemu a na forum mozn apogadav
glownie o pewnym waskim wycinku tematow o ktorych akurat komus chce sie gadac)

do góry

> Użytkownik <o...@g...com> napisał w wiadomości
news:b7426ee8-be56-48fc-9657-da5a18e0729b@googlegrou
ps.com...
....
> Czy ktoś jest w stanie wykonać takie obliczenia i zmierzyć czas? A może możecie
podsunąć jakiś sensowny sposób oszacowania tego?

Program do testowania wersja 32bit. Wersja 64bit powinna działać szybciej niestety
byłem w podróży i miałem dostęp tylko do laptopa z systemem 32bit.
Zrobiłem testy dla 16,32,64,128 powtórzeń.

Czas obliczeń uzyskany przy pomocy rozkazu RDTSC
Pierwsza liczba do ilość powtórzeń druga średnia ilość cykli zegara

Procesor i5-4200 2,5GHz
16 - 14000
32 - 15900
64 - 19500
128 - 26500

Porcesor i7-6700 3.4GHz
16 - 9800
32 - 12500
64 - 15900
128 - 24000

Porcesor i7-8750 2.2GHz
16 - 7500
32 -10000
64 - 11000
128 - 14000

do góry

> z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund, ile
to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei umie
scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne

Ma to być algorytm szyfrujący. Operacje, które zadałem są, według moich przewidywań,
średnim przypadkiem, który będzie trzeba obliczać. Wykonanie takich obliczeń jest
równoznaczne zaszyfrowaniu 2^n * 1/20 bitów (bo trzeba wykonać 20 rund złożonych z
identycznego rodzaju obliczeń), w zależności od tego jak dobierzemy n. Nie może być
ono jednak za małe, bo obniży to bezpieczeństwo algorytmu. Jeśli 2^n=128, tak jak to
określiłem w pierwszym poście, to oznacza, że algorytm będzie działał na blokach
128-bitowych i każdemu takiemu blokowi przypisze inny 128-bitowy, pseudolosowy blok.
Szyfry 128-bitowe są takim standardem dzisiaj. Więc, jeśli czas pracy będzie
niezadowalający, to może się okazać, że algorytm wielkiej kariery nie zrobi.

Tak jak pisałem, niedoścignionym ideałem, powszechnie dzisiaj stosowanym jest AES,
który potrafi szyfrować, jak pisze wikipedia:

On Intel Core i3/i5/i7 and AMD Ryzen CPUs supporting AES-NI instruction set
extensions, throughput can be multiple GB/s (even over 10 GB/s).

Czyli nawet 10 GB/s. Przy 166 mikrodekundach mój algorytm byłby w stanie zaszyfrować:

1000000/166*128/20*1/2^20= 0.037 MB/s

To mizernie, ale jeszcze pewnie gdzieś na pograniczu praktycznych zastosowań.

> wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest
glupkowate i przez to traci czas ludziom

Ważne dla kogo? Dla mnie jest ważne. Dla ludzi zajmujących się problemem Collatza i
kryptografią to pewnie też ważny temat badań. Apple zgłosiło na przykład wniosek
patentowy na funkcję hashującą opartą o tego rodzaju funkcje (odrzucony):

https://patents.google.com/patent/US20130108038A1/en

Ktoś opublikował inną funkcję hashującą, korzystającą z tych ciągów (swoją drogą
oceniam ją bardzo pozytywnie, myślę, że ma potencjał):

https://arxiv.org/pdf/1801.05079.pdf

Jest też generator liczb (pseudo)losowych bazujący na ciągach Collatza:

https://link.springer.com/article/10.1007/s41870-019
-00307-9

Jest praca dotycząca szyfrowania obrazów, przy użyciu ciągów Collatza (na moje oko
jednak dosyć naiwna i elementarna, więc raczej chleba z tej mąki nie będzie):

https://www.mdpi.com/1099-4300/20/12/901

Jest oto dosyć niszowa dziedzina matematyki teoretycznej, zaś od niedawna co
niektórzy zaczęli dostrzegać w trudnościach związanych z hipotezą Collatza potencjał
kryptograficzny. Nikt nie zaproponował jednak jak dotąd funkcji szyfrującej opartej o
te ciągi, choć myślę, że jest tylko kwestią czasu, gdy to się stanie (wydaje się to
jeszcze poza zasięgiem środowiska naukowego albo poza polem zainteresowań, większość
mimo wszystko porywa się na słynną hipotezę lub twierdzenia poboczne, mające
przybliżyć nas do jej rozwiązania). Dla kogoś z boku może i nie jest to ważny temat.
Ale myślę, że takie Apple z pocałowaniem ręki przyjęłoby kogoś, kto sformułowałby dla
nich taki algorytm i są ludzie oraz firmy, które po prostu nad tym pracują. Inna
sprawa, że jest to po prostu wyabstrahowana część problemu i algorytmu, która sama w
sobie może się wydawać nieinteresująca. Jednocześnie nie chcę publikować algorytmu ot
tak w internecie, dopóki nie ocenię jego potencjału i nie podejmę decyzji, co z nim
zrobić.

> jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos
mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno
tlum chetnych

Współpracowałem już z programistami w różnych, prywatnych celach. Raz zleciłem
napisanie programu związanego z rozwiązaniem pewnej hipotezy pobocznej związanej z
hipotezą Collatza, innym razem pracowałem z pewnym programistą nad strategiami i
algorytmami do gry na giełdzie. 200 zł to nie jest dla mnie problem i pewnie prędzej,
czy później podejmę z kimś doraźną współpracę, żeby zrobić kompleksowe testy, w tym
testy Dieharda, nie tylko pod kątem prędkości działania algorytmu. Tym bardziej, że
chciałbym skomercjalizować temat, jeśli dobrze mi się wydaje, że jest coś wart. Ale,
żeby udać się np. do jakiegoś funduszu zalążkowego, centrum transferu technologii, na
uczelnię, czy skontaktować się z jakąś spółką technologiczną typu IBM, trzeba
wiedzieć choć trochę na czym się stoi (stąd współpraca odpłatna i wstępne napisane
kodu oraz testy są nieuniknione, wiem o tym). Zanim to jednak zrobię chciałem się
choć wstępnie zorientować na co się nastawiać.

do góry

> Program do testowania wersja 32bit. Wersja 64bit powinna działać szybciej niestety
> byłem w podróży i miałem dostęp tylko do laptopa z systemem 32bit.
> Zrobiłem testy dla 16,32,64,128 powtórzeń.
>
> Czas obliczeń uzyskany przy pomocy rozkazu RDTSC
> Pierwsza liczba do ilość powtórzeń druga średnia ilość cykli zegara
>
> Procesor i5-4200 2,5GHz
> 16 - 14000
> 32 - 15900
> 64 - 19500
> 128 - 26500
>
> Porcesor i7-6700 3.4GHz
> 16 - 9800
> 32 - 12500
> 64 - 15900
> 128 - 24000
>
> Porcesor i7-8750 2.2GHz
> 16 - 7500
> 32 -10000
> 64 - 11000
> 128 - 14000

Ok, dzięki! To niesie ważną informację, że nie warto zmniejszać liczby operacji,
bowiem oszczędności na prędkości są bardzo niewielkie w porównaniu do utraty
bezpieczeństwa. Szyfrowanie w blokach 16-bitowych nie może się nawet równać z
szyfrowaniem w blokach 128-bitowych. Jeśli dobrze rozumiem w ostatnim przypadku 128
iteracji zostało wykonanych w czasie 14000/(2,2*1000000000) sekund. A to jest
2.2*1000000000/14000*128/20*1/2^20 = 0,96 MB na sekundę w moim algorytmie. Są to już
praktyczne i użyteczne wartości dla większości zastosowań szyfrów symetrycznych.
Czyli warto pracować nad tym algorytmem! Fakt, aby dogonić AES'a trzeba szyfrować
10-100 razy szybciej, choć te szacunki rozjeżdżają się mocno.

W przypadku mikroprocesorów klasy Pentium Pro, szyfrowanie za pomocą AES'a wymaga 18
cykli zegara na każdy bajt, co jest równoznaczne z wydajnością rzędu 11 MB/s dla
procesora 200 MHz. Z kolei na procesorze klasy Pentium M o szybkości 1.7 GHz
wydajność wynosi ok. 60 MB/s.

do góry

Dodam jeszcze tylko, że najprawdopodobniej szyfrowanie mogłoby się odbywać również w
blokach 64-bitowych lub nawet 32-bitowych. A zatem podobne obliczenia wystarczy
oszacować dla 64 iteracji, zaczynając od liczby 2^64-5 albo dla 32 iteracji
zaczynając od liczby 2^32-5.

Przyjąłem bloki 128-bitowe, ponieważ są one współcześnie standardem. Według mojej
wiedzy nie są one jednak koniecznością i większość symetrycznych szyfrów blokowych
używa tak dużych bloków z konieczności, bowiem mają one ścisły związek z rozmiarem
ich kluczy. Klucze zaś muszą być współcześnie duże, minimum 128-bitowe, aby
zapewniały bezpieczeństwo. W moim algorytmie jednak można zastosować nawet klucz
256-bitowy, zaś szyfrowanie może odbywać się w praktycznie dowolnie małych blokach.

Nie mogą być one jednak za małe. Dla bloków 128-bitowych wszystkie możliwe wektory
binarne o 128 cyfrach można ułożyć na 128! sposobów, czyli 3,86*10^215. Zaś dla
przypadku bloków 64-bitowych można to zrobić na 64!=1,27*10^89. To wciąż znacznie
więcej możliwych sposobów, niż liczba możliwych 128-bitowych kluczy. To również
nieosiągalne do odtworzenia ilości dla kogoś kto podsłuchiwałby transmisje (w celu
odtworzenia permutacji, którą realizuje algorytm), czy w ogóle kogoś, kto chciałby
pomieścić tak ogromne permutacje na dysku. Wydaje się zatem, że bez utraty
bezpieczeństwa można szyfrować również w krótszych blokach (choć muszę jeszcze
zgłębić ten temat).

A to by oznaczało, że mój algorytm mógłby być najszybszym algorytmem na świecie, bo
prawdopodobnie obliczenia dla przypadku n=64 będą o rząd lub kilka rzędów wielkości
szybsze.

do góry

W dniu środa, 11 grudnia 2019 03:09:16 UTC+1 użytkownik osobliwy nick napisał:
> > z tego co napisalem wynika ze moze to byc w granicach 0.5 do kliku mikrosekund,
ile to bedzie zalezy od szczegolow a gadanie z kims takim jak kolega ktory nawet nei
umie scisle wypowiedziec co to ma scisle liczyc jest bardzo nieprzyjemne
>
> Ma to być algorytm szyfrujący. Operacje, które zadałem są, według moich
przewidywań, średnim przypadkiem, który będzie trzeba obliczać. Wykonanie takich
obliczeń jest równoznaczne zaszyfrowaniu 2^n * 1/20 bitów (bo trzeba wykonać 20 rund
złożonych z identycznego rodzaju obliczeń), w zależności od tego jak dobierzemy n.
Nie może być ono jednak za małe, bo obniży to bezpieczeństwo algorytmu. Jeśli
2^n=128, tak jak to określiłem w pierwszym poście, to oznacza, że algorytm będzie
działał na blokach 128-bitowych i każdemu takiemu blokowi przypisze inny 128-bitowy,
pseudolosowy blok. Szyfry 128-bitowe są takim standardem dzisiaj. Więc, jeśli czas
pracy będzie niezadowalający, to może się okazać, że algorytm wielkiej kariery nie
zrobi.
>
> Tak jak pisałem, niedoścignionym ideałem, powszechnie dzisiaj stosowanym jest AES,
który potrafi szyfrować, jak pisze wikipedia:
>
> On Intel Core i3/i5/i7 and AMD Ryzen CPUs supporting AES-NI instruction set
extensions, throughput can be multiple GB/s (even over 10 GB/s).
>
> Czyli nawet 10 GB/s. Przy 166 mikrodekundach mój algorytm byłby w stanie
zaszyfrować:
>

10 GB/s ? moze oni licza to dla jakichs 32 rdzeniowych procesorow wtedy moze - nie
wiem jak wydajne sa te instrukcje aes-ni ale 10 GB/s to raczej dla wielu procesorow
na raz a i tak to wychodziloby kilka/kilkanascie cykli na zaszyfrowanie inta czyli
bardzo malo.. mz idzie to wytlumaczyc tylko tym ze to sa dane dla wielu rdzeni

> 1000000/166*128/20*1/2^20= 0.037 MB/s
>


kolega jest chyab niezle pijany...
pisalem wyzej ze jedna taka iteracja na incie (4 bajty) moze zjac gdzies w granicach
10 ns (powiedzmy, plus minus, byc moze jest to zbytni pesymizm moze zajelo by tylko 3
ns) sto zajmie wiec w okolicach 1 mikrosekundy, na sekunde wiec wyjdzie to 1M intow
czyli 4 MB (na rdzen)

(byc moze jest to zbyt pesymistyczne ale chodzilo mi o zarysowanie rzedu wielkosci,
jesli wziac optymistycznie ze to bedzie ze 3 razy szybsze i masz 32 rdzenie to
wyjdzie 12*32 = 384 MB/s, a jesli sa te specjalne instrukcje przyspieszajace to kilka
razy to moze byc kilka razy wiecej ale i tak z tym 10 GBs tu wydaje sie przesada,
chyab ze to na GPU)

(jesli chodzi tylko o wywolywane tych iteracji, nie wiem czego ten algorytm wymaga i
jest to za nudne dla mnie odrywac sie od ciekawszych rzeczy i tym zajmowac, sory)

ciezko sie z kolega rozmawia bo kolega ma kalasyczny syndropm nooba czyli wyglaszanie
jako pewniki zbioru zalozen ktore kolega uwaza za wazne a ktore widac ze sa mozna
watpliwe lub ewidentnie falszywe

> To mizernie, ale jeszcze pewnie gdzieś na pograniczu praktycznych zastosowań.
>
> > wpieniajace jet tez to ze kolega sugeruje jakoby to bylo wazne pytanie a jest
glupkowate i przez to traci czas ludziom
>
> Ważne dla kogo? Dla mnie jest ważne. Dla ludzi zajmujących się problemem Collatza i
kryptografią to pewnie też ważny temat badań. Apple zgłosiło na przykład wniosek
patentowy na funkcję hashującą opartą o tego rodzaju funkcje (odrzucony):
>
> https://patents.google.com/patent/US20130108038A1/en
>
> Ktoś opublikował inną funkcję hashującą, korzystającą z tych ciągów (swoją drogą
oceniam ją bardzo pozytywnie, myślę, że ma potencjał):
>
> https://arxiv.org/pdf/1801.05079.pdf
>
> Jest też generator liczb (pseudo)losowych bazujący na ciągach Collatza:
>
> https://link.springer.com/article/10.1007/s41870-019
-00307-9
>
> Jest praca dotycząca szyfrowania obrazów, przy użyciu ciągów Collatza (na moje oko
jednak dosyć naiwna i elementarna, więc raczej chleba z tej mąki nie będzie):
>
> https://www.mdpi.com/1099-4300/20/12/901
>
> Jest oto dosyć niszowa dziedzina matematyki teoretycznej, zaś od niedawna co
niektórzy zaczęli dostrzegać w trudnościach związanych z hipotezą Collatza potencjał
kryptograficzny. Nikt nie zaproponował jednak jak dotąd funkcji szyfrującej opartej o
te ciągi, choć myślę, że jest tylko kwestią czasu, gdy to się stanie (wydaje się to
jeszcze poza zasięgiem środowiska naukowego albo poza polem zainteresowań, większość
mimo wszystko porywa się na słynną hipotezę lub twierdzenia poboczne, mające
przybliżyć nas do jej rozwiązania). Dla kogoś z boku może i nie jest to ważny temat.
Ale myślę, że takie Apple z pocałowaniem ręki przyjęłoby kogoś, kto sformułowałby dla
nich taki algorytm i są ludzie oraz firmy, które po prostu nad tym pracują. Inna
sprawa, że jest to po prostu wyabstrahowana część problemu i algorytmu, która sama w
sobie może się wydawać nieinteresująca. Jednocześnie nie chcę publikować algorytmu ot
tak w internecie, dopóki nie ocenię jego potencjału i nie podejmę decyzji, co z nim
zrobić.
>
> > jak jest kolega przy kasie to niech kolega zaplaci komus 200 zlotych i takie cos
mozna napisac i przetestowac spoojnei w ciaggu kilku godzin i znajdzie sie napewno
tlum chetnych
>
> Współpracowałem już z programistami w różnych, prywatnych celach. Raz zleciłem
napisanie programu związanego z rozwiązaniem pewnej hipotezy pobocznej związanej z
hipotezą Collatza, innym razem pracowałem z pewnym programistą nad strategiami i
algorytmami do gry na giełdzie. 200 zł to nie jest dla mnie problem i pewnie prędzej,
czy później podejmę z kimś doraźną współpracę, żeby zrobić kompleksowe testy, w tym
testy Dieharda, nie tylko pod kątem prędkości działania algorytmu. Tym bardziej, że
chciałbym skomercjalizować temat, jeśli dobrze mi się wydaje, że jest coś wart. Ale,
żeby udać się np. do jakiegoś funduszu zalążkowego, centrum transferu technologii, na
uczelnię, czy skontaktować się z jakąś spółką technologiczną typu IBM, trzeba
wiedzieć choć trochę na czym się stoi (stąd współpraca odpłatna i wstępne napisane
kodu oraz testy są nieuniknione, wiem o tym). Zanim to jednak zrobię chciałem się
choć wstępnie zorientować na co się nastawiać.

do góry