Progresul hardware, episodul 70: Treburi de sfârșit de toamnă la numere (octombrie-noiembrie 2018)
16 octombrie: Am redat aseară drumul Aorusului să sorteze restul de fișiere .NUM1, dar dimineața l-am găsit stins. Îi spusesem să dea stingerea la sfârșit. După miezul nopții am dat la CEZ indexul autocitit (5826, cu 2214 peste cel de dinainte). În dimineața asta am pus și Threadripperul la treabă, să sorteze și el restul de fișiere, dar nu i-am pus parolă la TeamViewer, trebuie și asta. Am văzut că la Aorus liberii folosibili sunt 58579 de GB din 58590, iar la Threadripper 75986 din 76000 (așa zice CIRCENTE), adică totuși tot vreo 25 de GB în minus la ele două.
Inodizarea propriu-zisă NU poate să ocupe atât, nici măcar la discurile de sistem, unde sunt sub 500000*256 de octeți pe disc (șase sisteme), pe când la celelalte 33 (fără acel IDE de la Veriton) inode-urile se numără la sub 50000 pe disc, maxim vreo 200000 și ceva pe cele de 14 TB, dacă sunt maxim vreo trei milioane și ceva de inode-uri, ceva pe la 3200000 sau 3250000, pe cele 39 (fără IDE), și toate sunt de câte 256 de octeți, ceea ce înseamnă că ele cu totul fac vreo 800 de MB (zecimali), eventual vreo 825 de MB în 208330 de GB (fără 40 la IDE).
Atunci, oricum partiționarea cu format ext4 își ocupă un spațiu specific peste tot, de aproape 1 GB sau chiar 1 GB și ceva, spre 2, la cele mari de 14 TB, și în total tot or să mai fie niște zeci de GB în minus pentru partiționare. Aorusul și Threadripperul au cele mai mari spații de stocare, urmate îndeaproape de XPOWER (nu l-am repus încă la numere) și de triada de jos, mă gândesc că totalul de GB răpiți de partiționare este între 40 și 50, dar măcar nu mai este diferența aceea de aproape 2 TB (1800, 1900, 1935 de GB) de pe când erau multe noduri de intrare.
Un inode poate să aibă și 128 de octeți, doar să nu fie prea neîncăpător față de 256, care are loc de atribute în plus pentru fișiere. Sper să nu fie pierdere dacă le-aș seta la 128, pentru câteva sute de MB în plus la spațiul general. Comanda mke2fs poate să stabilească și asta. Dar iar trebuie salvare mișcătoare de fișiere pe alt disc și reformatare. Și așa o să trebuiască iar refiltrarea tuturor GIG-urilor...
Pe la 25 noiembrie 2018, după ce am făcut un BAZSUS cu 26068 de numere de fond 1 și am văzut că ele rămân prinse în acei 5173 de factori primi ai numerelor multiperfecte și semiperfecte de pe Numericana și de pe pagina lui Achim Flammenkamp, m-am gândit că ar fi mai optim pentru numere ca și fondul 2 să fie, temporar cel puțin, resetat între limitele originale ale numerelor de fond 1 (pornind de la CF52, gradual în sus, până la 1910), ca pe cât posibil să trag de aici restul de numere de fond 1 și să mai reextind plaja de numere prime componente atunci când este necesar. De această dată sunt șaisprezece trepte (și tot 16 fișiere GIG) de compunere pe factori primi a numerelor:
52, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 180, 200, 240*, 420 și 1910.
*Are un singur factor prim (pe 3) care depășește 64 de biți.
Făcând abstracție de marele fișier prim GIG.TXT, cu 7229 de factori pe 64 de biți și 1533 peste, conținătorul mare de numere prime, P2.TXT, avea 5394 de numere prime mici și 421** peste 64 de biți. La cele 5173, sunt 4752 cu 421, și tocmai aici diferența este cea mai mică, pentru că la fișierele mai mici diferența de numere prime se lărgește tot mai tare, încât la CF52, de la 3339 se ajunge la... doar 121 de factori primi pentru fondul 1, și desigur că și partea de H scade zdravăn. 328 a rămas numărul de H sus, pe când 538 ajunsese punctul de H-uri pe la P2.TXT, pentru fondul 2 numeric, care însă avea și are ca scop final tot creșterea numărului de numere prețioase (fond 1), astfel că reducerea numărului de factori primi la limitele propriu-zise ale fondului 1 nu face altceva decât să servească interesul numerelor prețioase, cum l-a făcut și lărgirea lor progresivă trecută. La CF52, H a scăzut de la 221 (?) la doar 22.
**Tot cu 421 am rămas și după anii ăștia.
Acum la factorii primi ale căror puteri se încadrează în 64 de biți fără semn intră și numerele până la 200 de cifre, nu doar până la 160 (deși la 200 3 ajunge taman la puterea 40, maximul său pe 64 de biți, care are douăzeci de cifre și începe cu 1 și cu 2, când 2 la 64 este cu 1 și 8). Am păstrat toate CF-urile celelalte pe care le-am făcut și ajustat în timp, iar noile fișiere de numere prime se generează cu ajutorul lui vecun, de pildă ./vecun 0 200 ia toate numerele de fond 1 de maxim 200 de cifre din fișierul /N3.TXT și le scoate numerele prime în fișierul /CFV200.TXT, puterile supraunitare în /PUTERIV200.TXT și factorii primi supraunitari, singularizați, în /VPV200.TXT (văd că totuși nu pune și VCV, după modelul cu VC.TXT de dincolo care punea factorii primi mai mari de 64 de biți, dar cred că asta este tocmai când suntem la CFV240 sau mai sus, că acum este mai greu să punem factori primi peste 64 de biți, o dată ce la revenirea între limitele prime stricte ale fondului 1 se mai taie din factorii primi - mari și mulți, în special - pe care i-am tot luat în seamă sus la fondul 2).
Am pornit refiltrarea masivă a GIG-urilor pe baza noilor CFV-uri făcute cu vecun și reajustate din timp în timp, ceea ce nu a avut cum să nu ducă la pierderi de terabaiți întregi de numere „inutile” din GIG-uri. Am dat și refiltrare de LPT-uri, la care tot mai este de lucru, și am reformat grupul de funcții de căutare în sus și în jos, acum că până la 200 de cifre ne putem purta ca până la 160. Am să exploatez această formă redusă a numerelor prime de căutare cât de mult se poate, pentru găsirea optimă de noi numere de fond 1, reextinzând H-urile și primele în general atunci când e nevoie - dar cu atenție, cu măsură, ținând seama în primul rând de cât de găsibile sunt numerele de fond 1 cu factori primi străini de cei 5173 (și chiar și în interiorul celor 5173, la extinderea de la plaje mai mici, precum 70 sau 90, la cele mai mari, peste 100, de pildă, nu trebuie să adaug factori primi pe degeaba, trebuie să capăt convingerea că eventualii factori primi „împrumutați” dintr-un CFV superior într-unul inferior chiar au rost pentru noi numere de fond 1.
Chiar și extinderea factorilor primi de tip H în interiorul unuia și aceluiași CFV este limitată acum, la MODIFSUM). Am reformat partea de MODIFSUM între timp - am pus matrici noi, numite PRIMP (asta și la MODPRIMSUM), unde se memorează, pe baza factorilor primi acceptați pentru legăturile neprime, puterea fiecărui factor prim component al neprimelor de legătură, ca la MODSUS-sumările modifsumice să se ia direct valoarea puterii acesteia, ca index de folosit la div1/sum1, în loc să tot verific divizibilitatea factorului de legătură neprim cu fiecare component prim în parte, chiar dacă asta presupunea tot parcurgerea div1 și nu înmulțirea repetată cu numărul prim - dar acum nu mai este nevoie de folosirea neprimului de legătură (coef) la MODSUS/MODJOS și nu se mai ia un întreg k care să se tot incrementeze prin div1 până ce coef nu se mai divide cu indexul din div1, ci direct PRIMP[a], unde a este alt index care stabilește pe la care factor prim component al neprimului suntem (asta poate fi și în div, și în div1).
De asemenea, pentru noile CFV-uri și noua abordare a numerelor prime din componența numerelor mari, am pus la punct MODIFSUM-ul în două părți: HMODIFSUM, care tratează numai partea de factori primi multiputere și ajustează secțiunea de neprimi din COEFLEG în funcție de împărțirea lor exclusivă la cei H termeni (și H-ul este ajustat pentru fondul 1, adică micșorat de la cât ajunsese prin CF-uri), permițând în sus numai factori bazați pe cele H prime, ca să nu aducă H-uri noi la CFV până nu vreau eu, iar în jos, din zona de D-H se permit factori (și din H, desigur, D fiind totalul de factori primi pe 64 de biți - că legături neprime peste 64 de biți sigur nu folosesc în afară de vecun/FACTORSUBM și SCLEPAMORIS), dar numai D-H cu o singură împărțire în cadrul factorilor neprimi, din moment ce în numerele din GIG-ul și LPT-ul CFV-ului aceluia nu are sens să căutăm D-H - uri multiputere), și de asemenea HMODIFSUM trebuie să respingă acei factori neprimi (străinezi numerici) care conțin prime neaflate în CFV-ul corespunzător; așadar, HMODIFSUM și respectiv MODIFSUM cel cu numele clasic, ajustat însă să facă exact ceea ce NU face HMODIFSUM, anume să dea voie în sus căutare cu D-H și cu străinezi numerici (care automat sunt și ei ca niște D-H pentru CFV-ul curent, neavând cum să fie multiputere în el, fiind străini) și, prin permiterea de factori primi D-H + străinezi numerici, să dea voie acelor coeficienți de legătură neprimi care fie sunt făcuți numai din numere prime D-H + străinezi numerici, fie făcuți amestecat - toți coeficienții neprimi din COEFLEG care sunt în mod normal interziși (la HMODIFSUM), dar asta numai la căutarea în sus, menită să și aducă prin MODIFSUM coeficienți primi noi pentru compunerea numerelor mari; la MODIFSUM căutarea în jos este interzisă, tot ceea ce se poate face în jos la modulul modifsumic fiind deja definit dincolo la HMODIFSUM.
Așa că și menirea MODIFSUM-ului s-a schimbat. La MODPRIMSUM încă nu am făcut parte strictă de H, în fapt MODPRIMSUM, MODSPAR și MODPARSUM sunt deocamdată nefolosite, și nici pe la FACTORSUBM și SCLEPAMORIS nu am mai umblat în ultima săptămână.
Am mai implementat din codul pentru Veriton, dar și acolo partea de GIGM va veni mult scăzută, acum cu refiltrarea cu mai puține numere prime de componență, și-o să văd cât rost are, mai cu seamă că oricum la zona sub 80 de cifre găsirea de numere noi de fond 1 pare acum o șansă moartă - cu tot cu numerele prime multe.
Am făcut reforme și la partea de SUMADIV-uri, adăugând metode noi de sumare și ștergând din cele învechite (până și numele propriu-zis de SUMADIV a dispărut, acum cele mai puternic elaborate funcții de însumat divizorii numerelor fiind SUMIMENS și SUMIMENS1). Mă bazez mult pe scoaterea celui mai mare divizor impar din numărul de bază citit din GIG sau LPT, al cărui nume preferat este mpz_t p, știut fiind că se verifică divizibilitatea cu numere impare prime - 2 având regim special cu mpz_scan1, chiar și la acele programe cu coeficienți pari de legătură, unde de asemenea am separat părțile pare de cele impare, la factorii de legătură, fiind tratat separat chiar și cazul când coeficientul par este putere pură de 2. Asta la MODSPAR și la MODPARSUM. Pentru numerele cu puteri prime peste 64 de biți, am introdus și niște vectori speciali numiți mem (plus modpmem la MODPRIM, nu MODPRIME), care memorează puterile prime maxime din zona de 64 de biți pentru numerele prime de tip K, adică acelea care depășesc 2 la 64 în puterea de apariție - scopul este să stabilesc repede dacă la un număr anume este sau nu cazul de umblat la puterile peste 64 de biți ale numărului prim.
Acum K-urile scad și ele, cu reforma CFV-urilor. În anumite situații, există doar trei numere prime peste 64 de biți, și acelea mai mici cu 1 decât o putere de 2 (asta la numerele de 70-200 de cifre), și chiar doar două dintre ele (la 52-70), și atunci fac alt tratament special, stabilind prin valoarea mpz_scan1 dacă numărul mare respectiv este susceptibil să se împartă la așa ceva (adică dacă puterea lui de 2 este 126, precis se împarte și la 2 la 127 minus 1, sau când suntem la puterea 88/89 ori la 106/107), și atunci divizorul impar se împarte și la acel număr prim Mersenne, rămânând ca la parcurgerea restului de numere prime susceptibile din CFV să se compare suma de divizori în construcție anume cu acest divizor impar convenabil redus, pe principiul că mepezetelele mai mici fac comparații mai rapide - iar la sfârșit, dacă suma întrece divizorul impar se consideră calculată toată suma de divizori pe zona aceea și înmulțesc suma cu suma divizorilor puterii de 2 și, unde este cazul, și cu suma divizorilor numărului prim Mersenne de mai sus, ca să fie completă suma divizorilor. Acolo unde avem două înmulțiri suplimentare, situația este așa: fiind primul acela Mersenne implicat, fie că-i 2 la 89 minus 1, fie 2 la 107 minus 1 ori 2 la 127 minus 1, puterea maximă de 2 a numărului mare, dată de mpz_scan1, este 88 sau 106 ori 126, iar suma divizorilor puterii de 2 este chiar acel număr prim Mersenne, și pe de altă parte suma divizorilor numărului prim Mersenne este puterea de 2 următoare, 89 ori 107 sau 127, și atunci, pentru puterea 107 de pildă, suma divizorilor numerelor prime impare pe 64 de biți care compun numărul mare se înmulțește cu 2 la 107 minus 1 și apoi și cu 2 la 107 (două numere mari consecutive și speciale).
Introducerea vectorilor de mem la numerele de peste 200 de cifre (peste 160, pe stil vechi) are ca rost rapidizarea calculării sumei divizorilor pentru zona de K factori primi și, la numerele peste 420 de cifre, chiar și pentru restul de factori H, adică H-K, unde se pornește de sus în jos cu indexul mem-ului, adică de la puterea primă maximă pe 64 de biți a numărului în jos până la prima putere primă care divide numărul mare, considerându-se că acolo deja puterile prime sunt foarte mari și pe unde nu se trece de pragul de 2 la 64 și nu merită pornit de jos la căutarea puterii, ci direct de sus. Dar asta doar la numerele cele mai mari, de la 421 la 1910 cifre, care se găsesc numai pe ASUSPRIME.
Pe 26 noiembrie am adus în casă un nou portabil Maxtor de 2 TB, urmând că acum la XPOWER, AORUS și THREADRIPPER marginalele trebuie să stea pe portabile de 2 TB (toate Maxtor M3 negre), pe când portabilul ADATA de 1 TB stă acum la ASUSPRIME. După 14 decembrie plănuiesc să mai comand de la Senetic un HGST de 8 TB pe care să îl pun la XPOWER, de acolo mutând la Threadripper un disc de 4 TB, ca la XPOWER să fie 59 de TB zecimali în loc de 55 și la Threadripper 80 în loc de 76 câți sunt acum pe 4 decembrie. Poate că pe 19 decembrie noul hard disk va fi și el instalat în casă. Să dea Domnul să fie totul mai departe bine. Iar în 2019, mai vedem cum, când și dacă mai este progres hardware, că trebuie să am grijă și de alte lucruri. Mă mai gândesc la niște NVME-uri PCI-E, poate și vreun U.2, dar acum, în 2018, mai vreau cei 8 TB. Și mai departe să fie loc pentru mai multe treburi, inclusiv cu îmbunătățirea casei. Și desigur, tot cu numere noi și prin 2019, dacă tot se mai găsesc ele.
Inodizarea propriu-zisă NU poate să ocupe atât, nici măcar la discurile de sistem, unde sunt sub 500000*256 de octeți pe disc (șase sisteme), pe când la celelalte 33 (fără acel IDE de la Veriton) inode-urile se numără la sub 50000 pe disc, maxim vreo 200000 și ceva pe cele de 14 TB, dacă sunt maxim vreo trei milioane și ceva de inode-uri, ceva pe la 3200000 sau 3250000, pe cele 39 (fără IDE), și toate sunt de câte 256 de octeți, ceea ce înseamnă că ele cu totul fac vreo 800 de MB (zecimali), eventual vreo 825 de MB în 208330 de GB (fără 40 la IDE).
Atunci, oricum partiționarea cu format ext4 își ocupă un spațiu specific peste tot, de aproape 1 GB sau chiar 1 GB și ceva, spre 2, la cele mari de 14 TB, și în total tot or să mai fie niște zeci de GB în minus pentru partiționare. Aorusul și Threadripperul au cele mai mari spații de stocare, urmate îndeaproape de XPOWER (nu l-am repus încă la numere) și de triada de jos, mă gândesc că totalul de GB răpiți de partiționare este între 40 și 50, dar măcar nu mai este diferența aceea de aproape 2 TB (1800, 1900, 1935 de GB) de pe când erau multe noduri de intrare.
Un inode poate să aibă și 128 de octeți, doar să nu fie prea neîncăpător față de 256, care are loc de atribute în plus pentru fișiere. Sper să nu fie pierdere dacă le-aș seta la 128, pentru câteva sute de MB în plus la spațiul general. Comanda mke2fs poate să stabilească și asta. Dar iar trebuie salvare mișcătoare de fișiere pe alt disc și reformatare. Și așa o să trebuiască iar refiltrarea tuturor GIG-urilor...
Pe la 25 noiembrie 2018, după ce am făcut un BAZSUS cu 26068 de numere de fond 1 și am văzut că ele rămân prinse în acei 5173 de factori primi ai numerelor multiperfecte și semiperfecte de pe Numericana și de pe pagina lui Achim Flammenkamp, m-am gândit că ar fi mai optim pentru numere ca și fondul 2 să fie, temporar cel puțin, resetat între limitele originale ale numerelor de fond 1 (pornind de la CF52, gradual în sus, până la 1910), ca pe cât posibil să trag de aici restul de numere de fond 1 și să mai reextind plaja de numere prime componente atunci când este necesar. De această dată sunt șaisprezece trepte (și tot 16 fișiere GIG) de compunere pe factori primi a numerelor:
52, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 180, 200, 240*, 420 și 1910.
*Are un singur factor prim (pe 3) care depășește 64 de biți.
Făcând abstracție de marele fișier prim GIG.TXT, cu 7229 de factori pe 64 de biți și 1533 peste, conținătorul mare de numere prime, P2.TXT, avea 5394 de numere prime mici și 421** peste 64 de biți. La cele 5173, sunt 4752 cu 421, și tocmai aici diferența este cea mai mică, pentru că la fișierele mai mici diferența de numere prime se lărgește tot mai tare, încât la CF52, de la 3339 se ajunge la... doar 121 de factori primi pentru fondul 1, și desigur că și partea de H scade zdravăn. 328 a rămas numărul de H sus, pe când 538 ajunsese punctul de H-uri pe la P2.TXT, pentru fondul 2 numeric, care însă avea și are ca scop final tot creșterea numărului de numere prețioase (fond 1), astfel că reducerea numărului de factori primi la limitele propriu-zise ale fondului 1 nu face altceva decât să servească interesul numerelor prețioase, cum l-a făcut și lărgirea lor progresivă trecută. La CF52, H a scăzut de la 221 (?) la doar 22.
**Tot cu 421 am rămas și după anii ăștia.
Acum la factorii primi ale căror puteri se încadrează în 64 de biți fără semn intră și numerele până la 200 de cifre, nu doar până la 160 (deși la 200 3 ajunge taman la puterea 40, maximul său pe 64 de biți, care are douăzeci de cifre și începe cu 1 și cu 2, când 2 la 64 este cu 1 și 8). Am păstrat toate CF-urile celelalte pe care le-am făcut și ajustat în timp, iar noile fișiere de numere prime se generează cu ajutorul lui vecun, de pildă ./vecun 0 200 ia toate numerele de fond 1 de maxim 200 de cifre din fișierul /N3.TXT și le scoate numerele prime în fișierul /CFV200.TXT, puterile supraunitare în /PUTERIV200.TXT și factorii primi supraunitari, singularizați, în /VPV200.TXT (văd că totuși nu pune și VCV, după modelul cu VC.TXT de dincolo care punea factorii primi mai mari de 64 de biți, dar cred că asta este tocmai când suntem la CFV240 sau mai sus, că acum este mai greu să punem factori primi peste 64 de biți, o dată ce la revenirea între limitele prime stricte ale fondului 1 se mai taie din factorii primi - mari și mulți, în special - pe care i-am tot luat în seamă sus la fondul 2).
Am pornit refiltrarea masivă a GIG-urilor pe baza noilor CFV-uri făcute cu vecun și reajustate din timp în timp, ceea ce nu a avut cum să nu ducă la pierderi de terabaiți întregi de numere „inutile” din GIG-uri. Am dat și refiltrare de LPT-uri, la care tot mai este de lucru, și am reformat grupul de funcții de căutare în sus și în jos, acum că până la 200 de cifre ne putem purta ca până la 160. Am să exploatez această formă redusă a numerelor prime de căutare cât de mult se poate, pentru găsirea optimă de noi numere de fond 1, reextinzând H-urile și primele în general atunci când e nevoie - dar cu atenție, cu măsură, ținând seama în primul rând de cât de găsibile sunt numerele de fond 1 cu factori primi străini de cei 5173 (și chiar și în interiorul celor 5173, la extinderea de la plaje mai mici, precum 70 sau 90, la cele mai mari, peste 100, de pildă, nu trebuie să adaug factori primi pe degeaba, trebuie să capăt convingerea că eventualii factori primi „împrumutați” dintr-un CFV superior într-unul inferior chiar au rost pentru noi numere de fond 1.
Chiar și extinderea factorilor primi de tip H în interiorul unuia și aceluiași CFV este limitată acum, la MODIFSUM). Am reformat partea de MODIFSUM între timp - am pus matrici noi, numite PRIMP (asta și la MODPRIMSUM), unde se memorează, pe baza factorilor primi acceptați pentru legăturile neprime, puterea fiecărui factor prim component al neprimelor de legătură, ca la MODSUS-sumările modifsumice să se ia direct valoarea puterii acesteia, ca index de folosit la div1/sum1, în loc să tot verific divizibilitatea factorului de legătură neprim cu fiecare component prim în parte, chiar dacă asta presupunea tot parcurgerea div1 și nu înmulțirea repetată cu numărul prim - dar acum nu mai este nevoie de folosirea neprimului de legătură (coef) la MODSUS/MODJOS și nu se mai ia un întreg k care să se tot incrementeze prin div1 până ce coef nu se mai divide cu indexul din div1, ci direct PRIMP[a], unde a este alt index care stabilește pe la care factor prim component al neprimului suntem (asta poate fi și în div, și în div1).
De asemenea, pentru noile CFV-uri și noua abordare a numerelor prime din componența numerelor mari, am pus la punct MODIFSUM-ul în două părți: HMODIFSUM, care tratează numai partea de factori primi multiputere și ajustează secțiunea de neprimi din COEFLEG în funcție de împărțirea lor exclusivă la cei H termeni (și H-ul este ajustat pentru fondul 1, adică micșorat de la cât ajunsese prin CF-uri), permițând în sus numai factori bazați pe cele H prime, ca să nu aducă H-uri noi la CFV până nu vreau eu, iar în jos, din zona de D-H se permit factori (și din H, desigur, D fiind totalul de factori primi pe 64 de biți - că legături neprime peste 64 de biți sigur nu folosesc în afară de vecun/FACTORSUBM și SCLEPAMORIS), dar numai D-H cu o singură împărțire în cadrul factorilor neprimi, din moment ce în numerele din GIG-ul și LPT-ul CFV-ului aceluia nu are sens să căutăm D-H - uri multiputere), și de asemenea HMODIFSUM trebuie să respingă acei factori neprimi (străinezi numerici) care conțin prime neaflate în CFV-ul corespunzător; așadar, HMODIFSUM și respectiv MODIFSUM cel cu numele clasic, ajustat însă să facă exact ceea ce NU face HMODIFSUM, anume să dea voie în sus căutare cu D-H și cu străinezi numerici (care automat sunt și ei ca niște D-H pentru CFV-ul curent, neavând cum să fie multiputere în el, fiind străini) și, prin permiterea de factori primi D-H + străinezi numerici, să dea voie acelor coeficienți de legătură neprimi care fie sunt făcuți numai din numere prime D-H + străinezi numerici, fie făcuți amestecat - toți coeficienții neprimi din COEFLEG care sunt în mod normal interziși (la HMODIFSUM), dar asta numai la căutarea în sus, menită să și aducă prin MODIFSUM coeficienți primi noi pentru compunerea numerelor mari; la MODIFSUM căutarea în jos este interzisă, tot ceea ce se poate face în jos la modulul modifsumic fiind deja definit dincolo la HMODIFSUM.
Așa că și menirea MODIFSUM-ului s-a schimbat. La MODPRIMSUM încă nu am făcut parte strictă de H, în fapt MODPRIMSUM, MODSPAR și MODPARSUM sunt deocamdată nefolosite, și nici pe la FACTORSUBM și SCLEPAMORIS nu am mai umblat în ultima săptămână.
Am mai implementat din codul pentru Veriton, dar și acolo partea de GIGM va veni mult scăzută, acum cu refiltrarea cu mai puține numere prime de componență, și-o să văd cât rost are, mai cu seamă că oricum la zona sub 80 de cifre găsirea de numere noi de fond 1 pare acum o șansă moartă - cu tot cu numerele prime multe.
Am făcut reforme și la partea de SUMADIV-uri, adăugând metode noi de sumare și ștergând din cele învechite (până și numele propriu-zis de SUMADIV a dispărut, acum cele mai puternic elaborate funcții de însumat divizorii numerelor fiind SUMIMENS și SUMIMENS1). Mă bazez mult pe scoaterea celui mai mare divizor impar din numărul de bază citit din GIG sau LPT, al cărui nume preferat este mpz_t p, știut fiind că se verifică divizibilitatea cu numere impare prime - 2 având regim special cu mpz_scan1, chiar și la acele programe cu coeficienți pari de legătură, unde de asemenea am separat părțile pare de cele impare, la factorii de legătură, fiind tratat separat chiar și cazul când coeficientul par este putere pură de 2. Asta la MODSPAR și la MODPARSUM. Pentru numerele cu puteri prime peste 64 de biți, am introdus și niște vectori speciali numiți mem (plus modpmem la MODPRIM, nu MODPRIME), care memorează puterile prime maxime din zona de 64 de biți pentru numerele prime de tip K, adică acelea care depășesc 2 la 64 în puterea de apariție - scopul este să stabilesc repede dacă la un număr anume este sau nu cazul de umblat la puterile peste 64 de biți ale numărului prim.
Acum K-urile scad și ele, cu reforma CFV-urilor. În anumite situații, există doar trei numere prime peste 64 de biți, și acelea mai mici cu 1 decât o putere de 2 (asta la numerele de 70-200 de cifre), și chiar doar două dintre ele (la 52-70), și atunci fac alt tratament special, stabilind prin valoarea mpz_scan1 dacă numărul mare respectiv este susceptibil să se împartă la așa ceva (adică dacă puterea lui de 2 este 126, precis se împarte și la 2 la 127 minus 1, sau când suntem la puterea 88/89 ori la 106/107), și atunci divizorul impar se împarte și la acel număr prim Mersenne, rămânând ca la parcurgerea restului de numere prime susceptibile din CFV să se compare suma de divizori în construcție anume cu acest divizor impar convenabil redus, pe principiul că mepezetelele mai mici fac comparații mai rapide - iar la sfârșit, dacă suma întrece divizorul impar se consideră calculată toată suma de divizori pe zona aceea și înmulțesc suma cu suma divizorilor puterii de 2 și, unde este cazul, și cu suma divizorilor numărului prim Mersenne de mai sus, ca să fie completă suma divizorilor. Acolo unde avem două înmulțiri suplimentare, situația este așa: fiind primul acela Mersenne implicat, fie că-i 2 la 89 minus 1, fie 2 la 107 minus 1 ori 2 la 127 minus 1, puterea maximă de 2 a numărului mare, dată de mpz_scan1, este 88 sau 106 ori 126, iar suma divizorilor puterii de 2 este chiar acel număr prim Mersenne, și pe de altă parte suma divizorilor numărului prim Mersenne este puterea de 2 următoare, 89 ori 107 sau 127, și atunci, pentru puterea 107 de pildă, suma divizorilor numerelor prime impare pe 64 de biți care compun numărul mare se înmulțește cu 2 la 107 minus 1 și apoi și cu 2 la 107 (două numere mari consecutive și speciale).
Introducerea vectorilor de mem la numerele de peste 200 de cifre (peste 160, pe stil vechi) are ca rost rapidizarea calculării sumei divizorilor pentru zona de K factori primi și, la numerele peste 420 de cifre, chiar și pentru restul de factori H, adică H-K, unde se pornește de sus în jos cu indexul mem-ului, adică de la puterea primă maximă pe 64 de biți a numărului în jos până la prima putere primă care divide numărul mare, considerându-se că acolo deja puterile prime sunt foarte mari și pe unde nu se trece de pragul de 2 la 64 și nu merită pornit de jos la căutarea puterii, ci direct de sus. Dar asta doar la numerele cele mai mari, de la 421 la 1910 cifre, care se găsesc numai pe ASUSPRIME.
Pe 26 noiembrie am adus în casă un nou portabil Maxtor de 2 TB, urmând că acum la XPOWER, AORUS și THREADRIPPER marginalele trebuie să stea pe portabile de 2 TB (toate Maxtor M3 negre), pe când portabilul ADATA de 1 TB stă acum la ASUSPRIME. După 14 decembrie plănuiesc să mai comand de la Senetic un HGST de 8 TB pe care să îl pun la XPOWER, de acolo mutând la Threadripper un disc de 4 TB, ca la XPOWER să fie 59 de TB zecimali în loc de 55 și la Threadripper 80 în loc de 76 câți sunt acum pe 4 decembrie. Poate că pe 19 decembrie noul hard disk va fi și el instalat în casă. Să dea Domnul să fie totul mai departe bine. Iar în 2019, mai vedem cum, când și dacă mai este progres hardware, că trebuie să am grijă și de alte lucruri. Mă mai gândesc la niște NVME-uri PCI-E, poate și vreun U.2, dar acum, în 2018, mai vreau cei 8 TB. Și mai departe să fie loc pentru mai multe treburi, inclusiv cu îmbunătățirea casei. Și desigur, tot cu numere noi și prin 2019, dacă tot se mai găsesc ele.
Comentarii
Trimiteți un comentariu