A venit vara la numere
Și-am ajuns și în luna iunie 2019, care începe sâmbăta într-un an prebisect, cum a fost și luna iunie 1991.
1991 și 2019.
Nu știu dacă la începutul lunii iunie 1991 ploua tot așa de mult, dar în 2019 avem apă destulă și din cer, și de pe pământ.
Că se poate bea acasă de la robinet cu toptanul.
Și așa, când organismul este bine hidratat, curge și robinetul numerelor mai departe. Joi în 30 mai, am trecut și pragul cel așteptat de 29000 de numere al căror numitor abundențial este cel mult egal cu 10.
Dar descoperirile nu s-au oprit acolo - până s-a terminat luna mai erau deja 29022.
Pe 1 iunie, am ajuns până la 29043.
Acuma pe 3, suntem deja la cota 29077 și mai sunt așteptate și altele.
Bătălia se dă pe „partea de sus” a numărului de cifre ale numerelor, și asta este pe XPOWER, THREADRIPPER și ASUSPRIME.
Ca număr de threaduri implicate, foarte călărite sunt acum XPOWER-ul și „ASUSPRAIMUL”, iar pe Threadripper o parte mică din cele 64 de threaduri. Absurd, dar asta este viața.
La ASUSPRIME mă axez pe numerele de la 241 la 500 de cifre, unde am văzut că încă este rost de destule noutăți, deși și peste 500 cred că aș mai găsi. Iau zonele pe rând. La THREADRIPPER am început să las în pace zona cea mai de jos (111-120), că abia mai sus de ea apar noutățile. La XPOWER tot arealul de 161-240 de cifre este interesant.
Și totuși, tendința în ultima săptămână este ca, dincolo de câteva elemente noi pe la Threadripper între 125 și 160 de cifre, restul de prospături numerice să vină de dincolo de 180-200 de cifre, deci zona de interes de luptă numerică se restrânge în sus, către cumătrul ASUSPRIME. Pe la AORUS și mai ales la SLI PLUS nici n-am mai încercat de nu știu câte zile.
Și acum, schema monotonă de lucru cu căutarea numerică merge așa (NU „și-așa”, chiar dacă trăim la noi în țară):
Luăm XPOWER-ul ca exemplu, cu ale sale zone de la 161 la 240 de cifre. Ele sunt puse astfel:
161-170 (GIG170.TXT), 171-180 (GIG180), 181-190 (GIG190), 191-200 (unde e, normal, GIG200), 201-210 (cu GIG210) și... GIG240 (ultimul, cu GIG240.TXT).
După ce un fișier GIG din ăsta se actualizează cu numerele cele mai noi (și deci se face un fișier nou de câțiva TB și se șterge vechiul GIG), se construiește alt fișier mai mic, de maxim câteva sute de GB, bazat strict pe numerele noi care au fost puse în GIG (ca pe baza lor să se facă noua căutare de numere noi, restul numerelor din GIG considerându-se deja folosite și trebuind înmagazinate deoparte și lăsate deocamdată în pace).
Fișierul mai mic se construiește la rândul lui din alte bucăți și mai mici, care pot fi zece sau treizeci la număr și au extensia LPKP de regulă (de pildă LIT170.LPT, cu 161-170 de cifre, se face din zece LPKP-uri care au, respectiv, 161, 162 și tot așa până la 170 de cifre. Doar din numerele mai nou-găsite pentru marile fișiere GIG.
Și prin contopirea celor zece LPKP-uri în ordinea crescătoare a numărului de cifre al numerelor conținute, iese noul fișier .LPT (sau LIT, extensia poate varia), ordonat strict crescător, și această contopire se face printr-un program pe care l-am numit CREPITUS.
Mai departe, LPT-ul va fi efectiv folosit la o nouă căutare, cu NUMSIMPL, MODPRIME și HMODIFSUM. Prefer ca NUMSIMPL să folosească factori primi până la 40000, din plaja de factori primi componenți care corespund cu zona aceea de numere (161-170 de cifre), MODPRIME factori primi până la 40 de milioane și HMODIFSUM numere impare compuse (NU prime), care la XPOWER pot fi până la 3360, dar prin alte părți limita poate fi alta, ca de exemplu 2000 la ASUSPRIME, unde și numerele sunt mai mari și e mai greu.
Mai pe scurt, imediat ce se termină construirea noului GIG170 (cu ERMETE/vecungul) și s-a scris și sortat crescător și LPKP-ul cu 170, imediat se declanșează CREPITUS care să facă fișierul LPT cu noutăți de 161-170 de cifre, pregătit următoarei căutări; mai înainte de asta, eu încerc să calculez când ar fi LPT-ul gata și, pe alt thread de lucru (fereastră în Guake), pun sleep de un anumit număr de secunde și apoi să pornească noua căutare cu numsimpl, MODPRIME și HMODIFSUM.
Poate să fie ceva așa:
sleep 20000
/numsimpl 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 40000
/numsimpl 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 40000
/MODPRIME 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 40000000
/MODPRIME 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 40000000
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 1680
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 s 1680 3360
sleep 80
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 1680
sleep 80
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 j 1680 3360
„a” și „b” țin de felul cum vor fi numite fișierele cu rezultate: a = „va fi numit exact cum scrie în codul-sursă”, b = „va mai avea un caracter în plus în nume, unul distinct și distinctiv de la fișier la fișier”, ca să-și aibă fiecare program fișierul său, să nu se intercălărească.
1 înseamnă că se pornește de la numerele cu prima cifră 1 (în cazul nostru, de la începutul începutului).
„s” înseamnă că numerele din LPT vor fi înmulțite cu factori primi (sau neprimi la HMODIFSUM), deci căutare în sus, iar „j” înseamnă împărțire sau „în jos”.
Dar în fereastra inițială unde trebuie să se termine povestea cu ERMETE/vecungul, după ce se face noul LPT trebuie apelat programul „reconst” cu parametrii a, b și c, care întrerupe pe rând programele de căutare numerică aflate deja în rulare (de regulă numai HMODIFSUM-uri, care țin mai mult), redenumește fișierele de rezultate ale căutărilor proaspăt întrerupte din .NUM2 în .NUM1, ca să fie pregătite de segmentare (dacă-s prea mari pentru memoria calculatorului) și sortarea crescătoare a conținutului și apoi redeclanșează programul respectiv de căutare, aproximativ de la faza în care se afla prin fișierul LPT (și uneori GIG) atunci când s-a întrerupt; programele se resuscitează, așadar, unul câte unul, cu o pauză de „sleep” de un minut și ceva între ele, ca fiecare să apuce să-și populeze cu conținut noul fișier de rezultate corespunzător și următorul program să nu acceseze același fișier de rezultate la scriere.
Iar după ce au fost așa repornite toate, se apelează CIRCENTE (pentru segmentare, la fișierele NUM1 prea mari pentru memoria de 128 GB, dacă există) și PARONTE care sortează crescător toate NUM1-urile de care este nevoie la numere.
După asta se termină tot reconst-ul și mai departe dau ERMETE pentru viitorul GIG180.TXT (deci următorul după 170).
Și atunci poate să arate așa:
/CREPITUS 160 170 a
/reconst a b c
/ERMETE /run/media/root/T10/GIG180.TXT a
Mai departe vine rândul lui GIG180 să fie terminat de actualizat cu numere noi (apoi îl șterg pe cel vechi, mai curăț fișierele sortate .NUM care au fost folosite la actualizarea de conținut din GIG-uri și văd ce numere noi de fond 1 sunt; și o dată gata LPT-ul pot să-i șterg LPKP-urile din care s-a făcut).
Când GIG180 e gata, fac CREPITUS de 170-180, alt reconst și apoi ERMETE de la 190; iar în altă fereastră, până atunci, alt „sleep” mare cum e cel de și mai sus și numsimpl, MODPRIME, HMODIFSUM din LPT-ul 180 nou rezultat.
Mai departe ciclul se reia cu 190, 200, 210, 240 și apoi iar 170, 180... până când o fi.
Analog, la THREADRIPPER pot să fac așa cu GIG-urile de la 120 la 160, sau în ce altă ordine vreau (dar să fiu sigur că fișierele pentru noul GIG sunt suficient de actualizate, din schema de consecutivitate de mai sus rezultă că tind să las destul timp ca pentru un GIG și un LPT date (cum e la 170) să se termine complet noile căutări, inclusiv la HMODIFSUM-uri, chiar dacă mai apar întreruperi de reconst pe parcurs - 170 este gata, îi încep căutările, între timp se face 180, apoi alte aranjări de treburi, apoi 190, 200 și tot așa... până ajungem iar la 170, a și trecut destul (mai multe zile) și era timp ca HMODIFSUM-urile întrerupte și reluate cu reconst, la 170, să-și atingă sfârșitul la urma urmei.
MODPRIMELE și numsimpl-ele se termină mai repede, de obicei ele sunt gata înainte de reconst-ul dat la sfârșitul următorului GIG, dar HMODIFSUM-urile atârnă mai mult și de aceea este bine ca un același GIG cu LPT să fie rebăgat în seamă după MAI MULTĂ vreme, să se treacă între timp și prin celelalte, ca să fie mai sigură terminarea lucrului de căutare la HMODIFSUM-urile sale și noutățile de la actualizare să fie mai bine puse la punct.
Iar atunci când se face ERMETE/vecungul, de îndată ce toate numerele noi cu un anumit număr de cifre sunt gata puse în LPKP (care este generat și scris atunci) și LPKP-ul sortat crescător după ce noutățile de, să zicem, 161 de cifre au fost puse în noul GIG, asupra LPKP-ului (LIT161.LPKP în acest caz) se face o FILTRARE care să depisteze dacă există prin el vreun număr nou de fond 1 (cu numitorul acela abundențial egal cu maxim 10), că în principiu în acest LPKP nu pot fi decât numere nemaiîntâlnite - de aceea se cheamă noutăți. La capătul filtrării, se apelează programul „vecung2” care caută după fișierul FOND161.TXT, unde, în mod ideal, ar trebui să se afle vreun număr nou de 161 de cifre, și, fie că-i gol sau nu, se actualizează cu el conținuturile din N.TXT și N3.TXT (depozitele de numere de fond 1, unde N3 este sortat crescător).
Iar pe parcurs mai dau și „vecun” cu înmulțire și împărțire cu factori de legătură strict între numerele de fond 1 (primi sau compuși), și așa mai pot să găsesc niște noutăți pe lângă ce au adus NUMSIMPL, MODPRIME și HMODIFSUM.
Și așa, în mod permanent pe timpul actualizării GIG-urilor, se poate afla dacă și cât de mult mai apar numere prețioase noi (că numere de manevră, cu numitorul abundențial peste 10, tot apar și-apar; mă ajut de ele ca să le găsesc pe cele prețioase).
Așadar: actualizare de depozit mare (GIG), facere de depozit de noutăți ale actualizării (LPT), căutare de alte noutăți pe noul LPT, întrerupere de căutări (pentru ordonarea deoparte a conținutului curent al rezultatelor căutărilor) și reluarea lor imediată, plus actualizare la următorul GIG din schemă - de preferat următorul în ordinea crescătoare a numelor).
Și căutarea de mai sus de pe noul LPT poate să fie cronologic declanșată în timpul reconst-ului, care afectează alte LPT-uri preexistente (și uneori căutări pe GIG, dar mai rar), pe câtă vreme la apelarea lui cu a, b și c el memorează rapid programele preexistente și le întrerupe rând pe rând doar pe ele, fără să le vadă pe cele noi. Atât doar, ca noua căutare să nu fie declanșată înainte de prima clipă de rulare a reconst-ului, ca el să apuce să memoreze numai acele numsimpl, MODPRIME și HMODIFSUM preexistente.
Ca să nu întrerupem prea repede o căutare atât de nouă.
De aceea, când se actualizează un GIG și eu calculez cam cât ar mai dura ca să dau căutarea de numere de pe viitorul nou LPT, trebuie să socotesc și timpul alocat scrierii LPT-ului, până la procesul de întrerupere-reluare de la acel reconst, ca să nu fie conflict cu întreruperea.
Dacă acel „sleep” este prea mic, se poate ca LPT-ul nou încă să nu existe (și atunci noile programe se sting de la sine, pentru apelarea unui fișier care NU ESTE), ori să fie incomplet scris (trebuiesc întrerupte și reluate cu el complet), ori, dar mai puțin probabil, să apuce să fie prinse în reconst-ul acela, pornit îndată ce LPT-ul este gata - de fapt, acolo poate fi cazul când LPT-ul este incomplet, altfel clipa în care se iau PIDOF-urile proceselor este una foarte scurtă și greu de prins.
Schema aceasta de actualizare consecutivă a GIG-urilor și de întrerupere sistematică pentru pregătirea de nou conținut numeric ordonat pentru actualizări duce la o bună rată de creștere a cantității de numere noi de fond 1 - de când a început 2019 este cea mai bună rată de creștere de până acum.
Așadar, când era „HABEMUS IANUARIE” 2019, erau 26623 de numere, cu 2533 mai multe decât când pornise 2018;
Când a venit februarie erau vreo 27156, când a venit martie - 27615 cu aproximație.
Primul sfert din an s-a terminat cu 28001 (bucurie mare-n seara de 31 martie), iar în noaptea de Armindeni cota totală era pe la 28550 și ceva, 28552 prin zonă.
Iar când să vină iunie, 29022. Și deja alte cincizeci și ceva în două zile și jumătate din lună.
De când a venit 2019, 2454 de numere și NU suntem la jumătate din an; în tot 2018, au fost 2533, iar în 2017 1241 (dar până printr-a doua lui jumătate era numai Veritonul), în 2016 46, în 2015 26 de numere noi.
Să vedem mai departe... poate că acum în 2019 este și capătul odiseei numerice, dacă găsesc tot ce mai este. Pe la numerele sub 110-120 de cifre și peste 500 mai vreau să caut, și poate că mai este și pe la ele câte ceva. Dacă seva noutăților numerice se stinge, o să fie interesant cum o să rămân mai departe cu tot hardware-ul ăsta pe cap, și cum o să pot să-l folosesc fructuos, după cât de mult am băgat (!) în el.
Că totuși NU vreau să mă apuc să dau din el, dar ar și trebui să câștig mai mulți bani în 2019 (și de la serviciu...) pentru că din dragostea asta de hardware și de numere am plătit mult.
Deocamdată, povestea cu numerele SE SUSȚINE.
Și continuă drumul spre pragul de 30000 la prețioase (dacă se atinge).
1991 și 2019.
Nu știu dacă la începutul lunii iunie 1991 ploua tot așa de mult, dar în 2019 avem apă destulă și din cer, și de pe pământ.
Că se poate bea acasă de la robinet cu toptanul.
Și așa, când organismul este bine hidratat, curge și robinetul numerelor mai departe. Joi în 30 mai, am trecut și pragul cel așteptat de 29000 de numere al căror numitor abundențial este cel mult egal cu 10.
Dar descoperirile nu s-au oprit acolo - până s-a terminat luna mai erau deja 29022.
Pe 1 iunie, am ajuns până la 29043.
Acuma pe 3, suntem deja la cota 29077 și mai sunt așteptate și altele.
Bătălia se dă pe „partea de sus” a numărului de cifre ale numerelor, și asta este pe XPOWER, THREADRIPPER și ASUSPRIME.
Ca număr de threaduri implicate, foarte călărite sunt acum XPOWER-ul și „ASUSPRAIMUL”, iar pe Threadripper o parte mică din cele 64 de threaduri. Absurd, dar asta este viața.
La ASUSPRIME mă axez pe numerele de la 241 la 500 de cifre, unde am văzut că încă este rost de destule noutăți, deși și peste 500 cred că aș mai găsi. Iau zonele pe rând. La THREADRIPPER am început să las în pace zona cea mai de jos (111-120), că abia mai sus de ea apar noutățile. La XPOWER tot arealul de 161-240 de cifre este interesant.
Și totuși, tendința în ultima săptămână este ca, dincolo de câteva elemente noi pe la Threadripper între 125 și 160 de cifre, restul de prospături numerice să vină de dincolo de 180-200 de cifre, deci zona de interes de luptă numerică se restrânge în sus, către cumătrul ASUSPRIME. Pe la AORUS și mai ales la SLI PLUS nici n-am mai încercat de nu știu câte zile.
Și acum, schema monotonă de lucru cu căutarea numerică merge așa (NU „și-așa”, chiar dacă trăim la noi în țară):
Luăm XPOWER-ul ca exemplu, cu ale sale zone de la 161 la 240 de cifre. Ele sunt puse astfel:
161-170 (GIG170.TXT), 171-180 (GIG180), 181-190 (GIG190), 191-200 (unde e, normal, GIG200), 201-210 (cu GIG210) și... GIG240 (ultimul, cu GIG240.TXT).
După ce un fișier GIG din ăsta se actualizează cu numerele cele mai noi (și deci se face un fișier nou de câțiva TB și se șterge vechiul GIG), se construiește alt fișier mai mic, de maxim câteva sute de GB, bazat strict pe numerele noi care au fost puse în GIG (ca pe baza lor să se facă noua căutare de numere noi, restul numerelor din GIG considerându-se deja folosite și trebuind înmagazinate deoparte și lăsate deocamdată în pace).
Fișierul mai mic se construiește la rândul lui din alte bucăți și mai mici, care pot fi zece sau treizeci la număr și au extensia LPKP de regulă (de pildă LIT170.LPT, cu 161-170 de cifre, se face din zece LPKP-uri care au, respectiv, 161, 162 și tot așa până la 170 de cifre. Doar din numerele mai nou-găsite pentru marile fișiere GIG.
Și prin contopirea celor zece LPKP-uri în ordinea crescătoare a numărului de cifre al numerelor conținute, iese noul fișier .LPT (sau LIT, extensia poate varia), ordonat strict crescător, și această contopire se face printr-un program pe care l-am numit CREPITUS.
Mai departe, LPT-ul va fi efectiv folosit la o nouă căutare, cu NUMSIMPL, MODPRIME și HMODIFSUM. Prefer ca NUMSIMPL să folosească factori primi până la 40000, din plaja de factori primi componenți care corespund cu zona aceea de numere (161-170 de cifre), MODPRIME factori primi până la 40 de milioane și HMODIFSUM numere impare compuse (NU prime), care la XPOWER pot fi până la 3360, dar prin alte părți limita poate fi alta, ca de exemplu 2000 la ASUSPRIME, unde și numerele sunt mai mari și e mai greu.
Mai pe scurt, imediat ce se termină construirea noului GIG170 (cu ERMETE/vecungul) și s-a scris și sortat crescător și LPKP-ul cu 170, imediat se declanșează CREPITUS care să facă fișierul LPT cu noutăți de 161-170 de cifre, pregătit următoarei căutări; mai înainte de asta, eu încerc să calculez când ar fi LPT-ul gata și, pe alt thread de lucru (fereastră în Guake), pun sleep de un anumit număr de secunde și apoi să pornească noua căutare cu numsimpl, MODPRIME și HMODIFSUM.
Poate să fie ceva așa:
sleep 20000
/numsimpl 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 40000
/numsimpl 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 40000
/MODPRIME 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 40000000
/MODPRIME 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 40000000
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT a 1 s 2 1680
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 s 1680 3360
sleep 80
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 j 2 1680
sleep 80
/HMODIFSUM 160 170 /run/media/root/T1/LOT170.LPT b 1 j 1680 3360
„a” și „b” țin de felul cum vor fi numite fișierele cu rezultate: a = „va fi numit exact cum scrie în codul-sursă”, b = „va mai avea un caracter în plus în nume, unul distinct și distinctiv de la fișier la fișier”, ca să-și aibă fiecare program fișierul său, să nu se intercălărească.
1 înseamnă că se pornește de la numerele cu prima cifră 1 (în cazul nostru, de la începutul începutului).
„s” înseamnă că numerele din LPT vor fi înmulțite cu factori primi (sau neprimi la HMODIFSUM), deci căutare în sus, iar „j” înseamnă împărțire sau „în jos”.
Dar în fereastra inițială unde trebuie să se termine povestea cu ERMETE/vecungul, după ce se face noul LPT trebuie apelat programul „reconst” cu parametrii a, b și c, care întrerupe pe rând programele de căutare numerică aflate deja în rulare (de regulă numai HMODIFSUM-uri, care țin mai mult), redenumește fișierele de rezultate ale căutărilor proaspăt întrerupte din .NUM2 în .NUM1, ca să fie pregătite de segmentare (dacă-s prea mari pentru memoria calculatorului) și sortarea crescătoare a conținutului și apoi redeclanșează programul respectiv de căutare, aproximativ de la faza în care se afla prin fișierul LPT (și uneori GIG) atunci când s-a întrerupt; programele se resuscitează, așadar, unul câte unul, cu o pauză de „sleep” de un minut și ceva între ele, ca fiecare să apuce să-și populeze cu conținut noul fișier de rezultate corespunzător și următorul program să nu acceseze același fișier de rezultate la scriere.
Iar după ce au fost așa repornite toate, se apelează CIRCENTE (pentru segmentare, la fișierele NUM1 prea mari pentru memoria de 128 GB, dacă există) și PARONTE care sortează crescător toate NUM1-urile de care este nevoie la numere.
După asta se termină tot reconst-ul și mai departe dau ERMETE pentru viitorul GIG180.TXT (deci următorul după 170).
Și atunci poate să arate așa:
/CREPITUS 160 170 a
/reconst a b c
/ERMETE /run/media/root/T10/GIG180.TXT a
Mai departe vine rândul lui GIG180 să fie terminat de actualizat cu numere noi (apoi îl șterg pe cel vechi, mai curăț fișierele sortate .NUM care au fost folosite la actualizarea de conținut din GIG-uri și văd ce numere noi de fond 1 sunt; și o dată gata LPT-ul pot să-i șterg LPKP-urile din care s-a făcut).
Când GIG180 e gata, fac CREPITUS de 170-180, alt reconst și apoi ERMETE de la 190; iar în altă fereastră, până atunci, alt „sleep” mare cum e cel de și mai sus și numsimpl, MODPRIME, HMODIFSUM din LPT-ul 180 nou rezultat.
Mai departe ciclul se reia cu 190, 200, 210, 240 și apoi iar 170, 180... până când o fi.
Analog, la THREADRIPPER pot să fac așa cu GIG-urile de la 120 la 160, sau în ce altă ordine vreau (dar să fiu sigur că fișierele pentru noul GIG sunt suficient de actualizate, din schema de consecutivitate de mai sus rezultă că tind să las destul timp ca pentru un GIG și un LPT date (cum e la 170) să se termine complet noile căutări, inclusiv la HMODIFSUM-uri, chiar dacă mai apar întreruperi de reconst pe parcurs - 170 este gata, îi încep căutările, între timp se face 180, apoi alte aranjări de treburi, apoi 190, 200 și tot așa... până ajungem iar la 170, a și trecut destul (mai multe zile) și era timp ca HMODIFSUM-urile întrerupte și reluate cu reconst, la 170, să-și atingă sfârșitul la urma urmei.
MODPRIMELE și numsimpl-ele se termină mai repede, de obicei ele sunt gata înainte de reconst-ul dat la sfârșitul următorului GIG, dar HMODIFSUM-urile atârnă mai mult și de aceea este bine ca un același GIG cu LPT să fie rebăgat în seamă după MAI MULTĂ vreme, să se treacă între timp și prin celelalte, ca să fie mai sigură terminarea lucrului de căutare la HMODIFSUM-urile sale și noutățile de la actualizare să fie mai bine puse la punct.
Iar atunci când se face ERMETE/vecungul, de îndată ce toate numerele noi cu un anumit număr de cifre sunt gata puse în LPKP (care este generat și scris atunci) și LPKP-ul sortat crescător după ce noutățile de, să zicem, 161 de cifre au fost puse în noul GIG, asupra LPKP-ului (LIT161.LPKP în acest caz) se face o FILTRARE care să depisteze dacă există prin el vreun număr nou de fond 1 (cu numitorul acela abundențial egal cu maxim 10), că în principiu în acest LPKP nu pot fi decât numere nemaiîntâlnite - de aceea se cheamă noutăți. La capătul filtrării, se apelează programul „vecung2” care caută după fișierul FOND161.TXT, unde, în mod ideal, ar trebui să se afle vreun număr nou de 161 de cifre, și, fie că-i gol sau nu, se actualizează cu el conținuturile din N.TXT și N3.TXT (depozitele de numere de fond 1, unde N3 este sortat crescător).
Iar pe parcurs mai dau și „vecun” cu înmulțire și împărțire cu factori de legătură strict între numerele de fond 1 (primi sau compuși), și așa mai pot să găsesc niște noutăți pe lângă ce au adus NUMSIMPL, MODPRIME și HMODIFSUM.
Și așa, în mod permanent pe timpul actualizării GIG-urilor, se poate afla dacă și cât de mult mai apar numere prețioase noi (că numere de manevră, cu numitorul abundențial peste 10, tot apar și-apar; mă ajut de ele ca să le găsesc pe cele prețioase).
Așadar: actualizare de depozit mare (GIG), facere de depozit de noutăți ale actualizării (LPT), căutare de alte noutăți pe noul LPT, întrerupere de căutări (pentru ordonarea deoparte a conținutului curent al rezultatelor căutărilor) și reluarea lor imediată, plus actualizare la următorul GIG din schemă - de preferat următorul în ordinea crescătoare a numelor).
Și căutarea de mai sus de pe noul LPT poate să fie cronologic declanșată în timpul reconst-ului, care afectează alte LPT-uri preexistente (și uneori căutări pe GIG, dar mai rar), pe câtă vreme la apelarea lui cu a, b și c el memorează rapid programele preexistente și le întrerupe rând pe rând doar pe ele, fără să le vadă pe cele noi. Atât doar, ca noua căutare să nu fie declanșată înainte de prima clipă de rulare a reconst-ului, ca el să apuce să memoreze numai acele numsimpl, MODPRIME și HMODIFSUM preexistente.
Ca să nu întrerupem prea repede o căutare atât de nouă.
De aceea, când se actualizează un GIG și eu calculez cam cât ar mai dura ca să dau căutarea de numere de pe viitorul nou LPT, trebuie să socotesc și timpul alocat scrierii LPT-ului, până la procesul de întrerupere-reluare de la acel reconst, ca să nu fie conflict cu întreruperea.
Dacă acel „sleep” este prea mic, se poate ca LPT-ul nou încă să nu existe (și atunci noile programe se sting de la sine, pentru apelarea unui fișier care NU ESTE), ori să fie incomplet scris (trebuiesc întrerupte și reluate cu el complet), ori, dar mai puțin probabil, să apuce să fie prinse în reconst-ul acela, pornit îndată ce LPT-ul este gata - de fapt, acolo poate fi cazul când LPT-ul este incomplet, altfel clipa în care se iau PIDOF-urile proceselor este una foarte scurtă și greu de prins.
Schema aceasta de actualizare consecutivă a GIG-urilor și de întrerupere sistematică pentru pregătirea de nou conținut numeric ordonat pentru actualizări duce la o bună rată de creștere a cantității de numere noi de fond 1 - de când a început 2019 este cea mai bună rată de creștere de până acum.
Așadar, când era „HABEMUS IANUARIE” 2019, erau 26623 de numere, cu 2533 mai multe decât când pornise 2018;
Când a venit februarie erau vreo 27156, când a venit martie - 27615 cu aproximație.
Primul sfert din an s-a terminat cu 28001 (bucurie mare-n seara de 31 martie), iar în noaptea de Armindeni cota totală era pe la 28550 și ceva, 28552 prin zonă.
Iar când să vină iunie, 29022. Și deja alte cincizeci și ceva în două zile și jumătate din lună.
De când a venit 2019, 2454 de numere și NU suntem la jumătate din an; în tot 2018, au fost 2533, iar în 2017 1241 (dar până printr-a doua lui jumătate era numai Veritonul), în 2016 46, în 2015 26 de numere noi.
Să vedem mai departe... poate că acum în 2019 este și capătul odiseei numerice, dacă găsesc tot ce mai este. Pe la numerele sub 110-120 de cifre și peste 500 mai vreau să caut, și poate că mai este și pe la ele câte ceva. Dacă seva noutăților numerice se stinge, o să fie interesant cum o să rămân mai departe cu tot hardware-ul ăsta pe cap, și cum o să pot să-l folosesc fructuos, după cât de mult am băgat (!) în el.
Că totuși NU vreau să mă apuc să dau din el, dar ar și trebui să câștig mai mulți bani în 2019 (și de la serviciu...) pentru că din dragostea asta de hardware și de numere am plătit mult.
Deocamdată, povestea cu numerele SE SUSȚINE.
Și continuă drumul spre pragul de 30000 la prețioase (dacă se atinge).
Comentarii
Trimiteți un comentariu