La ce reorganizări a mai dus refiltrarea de numere din noiembrie (Partea II)
Dar cu refacerea numerică pornită după prima vizită la Catedrală au mai venit și niște fișiere speciale noi, în codul pentru numere.
Astfel, până pe 25 noiembrie 2018 exista un header numit DETRITO.h, unde erau trecute metodic, pentru zonele de maxim 52, 80, 100, 130, 160, 240, 420 și 1910 cifre (plus mini-zona de numere cu divizorii impari sub 64 de biți, plus varianta extinsă cu marele fișier de numere prime GIG.TXT), date ca:
-Totalul de numere prime din fișier (NTOT = 8762, N1910 = 5815, N420 = 3653 și tot așa, până jos la N52 = 3339 și... NP = 2705 (astea erau primele numerelor de maxim 30 de cifre, ai căror divizori impari maximi erau pe 64 de biți), așadar N-uri;
-Totalul de numere prime pe 64 de biți, anume DTOT = 7229, D1910 = 5394 și tot așa, jos de tot fiind tot 3339 cu 2705, prin urmare D-uri;
-Totalul de factori primi multiputere, care sigur erau o submulțime a D-urilor, fiind toți numere prime pe 64 de biți; de astă dată erau redați cu H-uri, adică HTOT (cel integral, valabil la GIG.TXT și la P2.TXT alias CF1910) = 538, H420 = 337 și tot mai jos până la H52 = 221 și HP = 125;
-La numerepe peste 160 de cifre, o categorie nouă și specifică de factori primi, submulțimi ale zonelor de H-multiputere, unde puterea maximă de apariție a numerelor prime în numerele mari trece de 2 la puterea 64 (și care necesită tratament special la calculul sumelor de divizori), ca atare K-uri, date atent la alegere, ca să acopere bine cazurile numerice: KTOT (sus de tot) lua în DETRITO valoarea 27, dar pe la FACTORSUBM și SCLEPAMORIS K e 50 (ăștia sunt două programe care generează aleator puteri de factori primi de legătură între numere, tot cu căutări prin înmulțire și împărțire, care însă acolo sunt luate împreună, nu la alegere cu 1 sau 0, ca la alte fișiere căutătare).
K420 era 14, iar K240 8, mai jos nefiind valabil (trecut totuși ca 0, așa, pentru viitor).
Și mai era constanta ETOT = 1533, totalul numerelor prime de peste 64 de biți care s-au luat.
******
Numai că după refiltrarea lăsată cu facere de fișiere noi (și mai multe) de numere prime, se impunea cumva o separare a noilor constante corespunzătoare (N, D, H, K) de cele vechi, ca în același timp și cele vechi să rămână bine depozitate deoparte, CF-urile și P2 cu GIG.TXT nefiind astfel șterse, ci doar scoase din uzul numeric cotidian.
Astfel, am făcut dualism headeristic pentru:
- TOLIL.h, principalul header cu funcții pentru numere (secundantul său se cheamă Z.h), care a fost asociat noilor CFV-uri, ce reclamau acum alte valori în constantele omonime cu cele vechi, plus modificarea unor funcții tolilice din cauza creșterii numărului de constante și de fișiere invocate, plus schimbarea numelor fișierelor acelora; TOLIL0.h este copia lui TOLIL care păstrează referințele vechi, legate de DETRITO.h și de CF-urile acelea mai bogate în numere prime;
- DETRITO.h, pentru care a apărut DETRITO2.h, care a copiat conținuturile de constante prim-numerice ale lui DETRITO și, cu mărirea numărului de înregistrări, s-a adaptat noii situații a CFV-urilor. Vechiul DETRITO.h este inclus în TOLIL0.h, iar DETRITO2 cel nou merge cu TOLIL;
- CARONTE.cc, care actualizează fișierele de factori primi - l-am trecut la varianta nouă, cu TOLIL.h și CFV-urile, iar în continuare CARONTELE.cc se referă la varianta veche, unde TOLIL0.h duce spre datele din CFV-uri, dar în practică stă nefolosit Carontele.
Acea separație de headere este necesară.
Și carontizarea să aibă cele două fețe.
TOLIL0.h, ca referent al plajelor largi de numere prime componente, este folosit la filtrarea de fond 1, pentru eventualitatea ca pe-acolo, pentru un interval dat de numere mari, să apară vreo noutate de fond 1 cu ceva prim component adițional, care astfel să fie captat unde trebuie; la filtrarea de fond 2 ne restrângem la parametrii lui TOLIL.h cel obișnuit.
Și la VECUNG2, care bagă propriu-zis numere noi de fond 1 în N.TXT și-n N3.TXT cel sortat crescător, de asemenea tot cu extinsele lui TOLIL0.h se lucrează la verificarea sumelor de divizori ale noutăților numerice.
De asemenea, la VECUN se lucrează tot cu TOLIL0.h, ca să fie largă plaja de numere prime atunci când numerele prețioase se caută exclusiv unele din altele.
La DETRITO2 toate constantele prim-numerice sunt mai mici decât dincolo, iar K-urile peste 160 sunt chiar inexistente la mai-noile zone apărute, 180 și 200. La (201-)240 există un singur factor prim de tip K, 3, care la puterea 46 depășește de circa 480.46 de ori valoarea lui 2 la 64.
K420 este 3, iar K general 13.
Acele reîmbogățiri parțiale ale CFV-urilor ar fi bine să dea loc mai mult pentru numere prețioase noi, altfel sunt iar redundante și GIG-urile cu LIT-urile vor trebui iarăși refiltrate, ca să se reajungă strict la limitele vectorilor de numere prime componente pe intervale, așa cum le dă VECUN când sondează numerele de fond 1.
Dar această limitare vecunică are rost cât timp, astfel, mai este loc pentru acele noutăți, cu dimensiuni rezonabile ale depozitelor de prime componente; dacă nu se mai pot găsi numere de fond 1 sub limitele vecunice, îmbogățirea cu factori primi este binevenită, în măsura în care mai există apoi noutăți.
Deja am văzut că în zonele cu maxim 110 cifre, de ceva vreme, nu mai este mai deloc loc de numere prețioase noi, acum centrul cel fructuos de bătălie este între 110 și 240 de cifre (THREADRIPPER și XPOWER), cu câte ceva nou, când și când, și peste 240 (la ASUSPRIME).
Mă gândesc. de pildă pentru AORUS, care răspunde de numerele de la 81 la 110 cifre, ca dacă chiar NU mai pot găsi astfel de numere noi la fondul 1, atunci să folosesc și la el niște variante complementare ale GIG-urilor mai mari de 110 cifre, pe unde încă o fi loc de noutăți, ca să nu fie Aorusul degeaba. Și așa, oricum, sunt tare mulți TB rămași neocupați pe discuri, chit că pot fi priviți ca spațiu de acoperire.
Mai vreau numere.
Astfel, până pe 25 noiembrie 2018 exista un header numit DETRITO.h, unde erau trecute metodic, pentru zonele de maxim 52, 80, 100, 130, 160, 240, 420 și 1910 cifre (plus mini-zona de numere cu divizorii impari sub 64 de biți, plus varianta extinsă cu marele fișier de numere prime GIG.TXT), date ca:
-Totalul de numere prime din fișier (NTOT = 8762, N1910 = 5815, N420 = 3653 și tot așa, până jos la N52 = 3339 și... NP = 2705 (astea erau primele numerelor de maxim 30 de cifre, ai căror divizori impari maximi erau pe 64 de biți), așadar N-uri;
-Totalul de numere prime pe 64 de biți, anume DTOT = 7229, D1910 = 5394 și tot așa, jos de tot fiind tot 3339 cu 2705, prin urmare D-uri;
-Totalul de factori primi multiputere, care sigur erau o submulțime a D-urilor, fiind toți numere prime pe 64 de biți; de astă dată erau redați cu H-uri, adică HTOT (cel integral, valabil la GIG.TXT și la P2.TXT alias CF1910) = 538, H420 = 337 și tot mai jos până la H52 = 221 și HP = 125;
-La numerepe peste 160 de cifre, o categorie nouă și specifică de factori primi, submulțimi ale zonelor de H-multiputere, unde puterea maximă de apariție a numerelor prime în numerele mari trece de 2 la puterea 64 (și care necesită tratament special la calculul sumelor de divizori), ca atare K-uri, date atent la alegere, ca să acopere bine cazurile numerice: KTOT (sus de tot) lua în DETRITO valoarea 27, dar pe la FACTORSUBM și SCLEPAMORIS K e 50 (ăștia sunt două programe care generează aleator puteri de factori primi de legătură între numere, tot cu căutări prin înmulțire și împărțire, care însă acolo sunt luate împreună, nu la alegere cu 1 sau 0, ca la alte fișiere căutătare).
K420 era 14, iar K240 8, mai jos nefiind valabil (trecut totuși ca 0, așa, pentru viitor).
Și mai era constanta ETOT = 1533, totalul numerelor prime de peste 64 de biți care s-au luat.
******
Numai că după refiltrarea lăsată cu facere de fișiere noi (și mai multe) de numere prime, se impunea cumva o separare a noilor constante corespunzătoare (N, D, H, K) de cele vechi, ca în același timp și cele vechi să rămână bine depozitate deoparte, CF-urile și P2 cu GIG.TXT nefiind astfel șterse, ci doar scoase din uzul numeric cotidian.
Astfel, am făcut dualism headeristic pentru:
- TOLIL.h, principalul header cu funcții pentru numere (secundantul său se cheamă Z.h), care a fost asociat noilor CFV-uri, ce reclamau acum alte valori în constantele omonime cu cele vechi, plus modificarea unor funcții tolilice din cauza creșterii numărului de constante și de fișiere invocate, plus schimbarea numelor fișierelor acelora; TOLIL0.h este copia lui TOLIL care păstrează referințele vechi, legate de DETRITO.h și de CF-urile acelea mai bogate în numere prime;
- DETRITO.h, pentru care a apărut DETRITO2.h, care a copiat conținuturile de constante prim-numerice ale lui DETRITO și, cu mărirea numărului de înregistrări, s-a adaptat noii situații a CFV-urilor. Vechiul DETRITO.h este inclus în TOLIL0.h, iar DETRITO2 cel nou merge cu TOLIL;
- CARONTE.cc, care actualizează fișierele de factori primi - l-am trecut la varianta nouă, cu TOLIL.h și CFV-urile, iar în continuare CARONTELE.cc se referă la varianta veche, unde TOLIL0.h duce spre datele din CFV-uri, dar în practică stă nefolosit Carontele.
Acea separație de headere este necesară.
Și carontizarea să aibă cele două fețe.
TOLIL0.h, ca referent al plajelor largi de numere prime componente, este folosit la filtrarea de fond 1, pentru eventualitatea ca pe-acolo, pentru un interval dat de numere mari, să apară vreo noutate de fond 1 cu ceva prim component adițional, care astfel să fie captat unde trebuie; la filtrarea de fond 2 ne restrângem la parametrii lui TOLIL.h cel obișnuit.
Și la VECUNG2, care bagă propriu-zis numere noi de fond 1 în N.TXT și-n N3.TXT cel sortat crescător, de asemenea tot cu extinsele lui TOLIL0.h se lucrează la verificarea sumelor de divizori ale noutăților numerice.
De asemenea, la VECUN se lucrează tot cu TOLIL0.h, ca să fie largă plaja de numere prime atunci când numerele prețioase se caută exclusiv unele din altele.
La DETRITO2 toate constantele prim-numerice sunt mai mici decât dincolo, iar K-urile peste 160 sunt chiar inexistente la mai-noile zone apărute, 180 și 200. La (201-)240 există un singur factor prim de tip K, 3, care la puterea 46 depășește de circa 480.46 de ori valoarea lui 2 la 64.
K420 este 3, iar K general 13.
Acele reîmbogățiri parțiale ale CFV-urilor ar fi bine să dea loc mai mult pentru numere prețioase noi, altfel sunt iar redundante și GIG-urile cu LIT-urile vor trebui iarăși refiltrate, ca să se reajungă strict la limitele vectorilor de numere prime componente pe intervale, așa cum le dă VECUN când sondează numerele de fond 1.
Dar această limitare vecunică are rost cât timp, astfel, mai este loc pentru acele noutăți, cu dimensiuni rezonabile ale depozitelor de prime componente; dacă nu se mai pot găsi numere de fond 1 sub limitele vecunice, îmbogățirea cu factori primi este binevenită, în măsura în care mai există apoi noutăți.
Deja am văzut că în zonele cu maxim 110 cifre, de ceva vreme, nu mai este mai deloc loc de numere prețioase noi, acum centrul cel fructuos de bătălie este între 110 și 240 de cifre (THREADRIPPER și XPOWER), cu câte ceva nou, când și când, și peste 240 (la ASUSPRIME).
Mă gândesc. de pildă pentru AORUS, care răspunde de numerele de la 81 la 110 cifre, ca dacă chiar NU mai pot găsi astfel de numere noi la fondul 1, atunci să folosesc și la el niște variante complementare ale GIG-urilor mai mari de 110 cifre, pe unde încă o fi loc de noutăți, ca să nu fie Aorusul degeaba. Și așa, oricum, sunt tare mulți TB rămași neocupați pe discuri, chit că pot fi priviți ca spațiu de acoperire.
Mai vreau numere.
Comentarii
Trimiteți un comentariu