Numerele în septembrie 2015 și după - Partea III: Marea refacere
(Lunea însorită de 16 noiembrie 2015, o zi de scris mult despre asta.)
*
La 27 septembrie 2015 am pornit procesul de regenerare numerică pentru fondul 2 alături de fondul 1, ca la vechiul GIG.TXT, devenit acum Vechea Glorie. După ora 12 pe 27 septembrie. Am început tot cu un fişier numit GIG.TXT, punând întâi în el, dacă ţin minte bine, numere de 100-120 de cifre, şi numere de pe la 60-80 de cifre (din zona lui "3.1"). Acum GIG.TXT stătea, într-adevăr, pe noul SSD, unde în noaptea distrugerii pusesem Ubuntu 15.04 după ce nu construisem corect pe stick o versiune beta de kit de Ubuntu 15.10, care era deja. Acum pe hard diskul Samsung era vechiul Ubuntu; GIG.TXT trebuia să meargă spre Noua Glorie.
Până în noaptea care a urmat, am reuşit să pun în el cam 40 de GB de numere, cu NUMSIMPL ca program de acumulare de numere. Am intuit că voi avea cu mare probabilitate nevoie de timp mai mult, peste o lună zi şi noapte, ca să ajung la dimensiunea pierdută (GIG + GIGNOU).
Dar am vrut mai multe numere decât cele pierdute. Astfel, am părăsit sub forţă situaţia de capitol 3 extins, cu fondul cu numitori peste 500000 şi până la un milion. 1048577 a devenit noua limită de neatins a numitorilor abundenţiali pentru viitorul fond 2, fără limită inferioară. Ca să urce numitorii până la 1048576 (2 la puterea 20), mai sus de un milion cum ar fi fost dacă nu murea hard diskul Seagate. Am ales totuşi astfel de limite măsurate, ştiind că mulţimea numerelor naturale şi cea a fracţionărilor abundenţiale sunt infinite şi estimând că paleta <=1048576 este rezonabil de compatibilă cu 2 sau 3 TB de spaţiu, chiar cu pierduţii teraocteţi înapoi.
În noua situaţie, voind multe numere repede, ca acest chin nedorit al regenerării să nu fie foarte lung, am văzut, în toamna 2015, ocazia altor reforme în proiectul cel numeric. Deşi am început pe 27 septembrie tot cu un singur GIG.TXT, am ştiut că este mai eficient ca de acum să fiu cu mai multe fişiere GIG, pe game de mărime numerică, după modelul de distribuire a vectorilor de factori primi pentru numere în funcţie de zonele de putere de 10: de exemplu, GIG52.TXT să aibă numerele mai mici de 10^52, apoi GIG80 pe cele de la 10^52 la 10^80 şi tot aşa după împărţirea vectorilor primi. Acum TRAT la NUMSIMPL a recăpătat o singură verificare dacă numitorul ireductibil înmulţit cu pragul abundenţial îl depăşeşte pe cel iniţial, şi cu un singur prag, cel de sus şi neatins 1048577, în loc de 1000001 cu 500000 la GIGNOU.TXT, sau în loc de 500001 la vechiul GIG.TXT.
Am revenit la statul târziu la calculator, chiar şi până la ziua următoare, şi la folosirea calculatorului în stil carenti termino*.
*Fără pauză, în limba latină.
Pornind noul fond 2 de la zero + fondul 1, cu NUMSIMPL (şi cu MODMIN, următorul fructuos la numerele mici, mai apoi şi cu MODSPRIM şi MODPRIM), la NUMSIMPL am realizat mai bine cum trebuie să pun factorii primi de legătură (de căutare) ca să vină mai repede multe numere: la umplerea unei zone goale, de exemplu [10^110, 10^130], întâi se caută (o dată, de două ori) în sus şi-n jos cu numere prime mai mici, până la 100, poate până la câteva sute, apoi trebuie repede trecut cu curaj la numere prime mai mari, care trec de 500, chiar de 1000, ajung la nivelul miilor.
La NUMSIMPL vor fi eficiente numerele prime mai mici de 1048577, în special cele până în 10000 au fost deja folosite, dar trebuie sărit cu curaj dincolo de 100-200 şi se adună mai multe numere în gama de populat.
Am reformat aparatul de actualizare a depozitului numeric: mai întâi, în ACTUAL.h în zonele unde se pot aduna foarte multe numere (cum sunt numerele de 30 până la 70 de cifre), chiar dacă se face actualizarea mergând crescător din putere de 10 în putere de 10 (din 1 în 1), tot vin prea multe numere pentru memoria calculatorului (chiar cu swap-ul de pe SSD). De exemplu pot să fie 400 de milioane de numere cu 49 de cifre, 450 de milioane cu 51 de cifre.
Atunci şi spaţiul de numere cu acelaşi număr de cifre trebuie împărţit, în trei zone sau chiar în patru (de exemplu: prima cifră 1 şi 2; apoi prima cifră 3 şi 4; 5 şi 6; 7, 8 şi 9) şi scade numărul de numere care intră în vector la un pas de actualizare. Acum chiar nu se mai poate sări, de exemplu, de la 44 la 47, sau de la 48 la 50.
De fapt, şi vechiul GIG.TXT ajunsese îndeajuns de încărcat în această zonă încât pasul din putere de 10 în putere de 10 să fie singurul, şi acela cu încărcătură destulă, dar la noile texte numerice, cu paleta abundenţială mai mare decât atunci, încărcarea este şi mai mare. Trebuia găsită o soluţie de progres.
Acum în ACTUAL.h există funcţia MODUL1 care actualizează GIG-ul corespunzător putere de 10 cu putere de 10, iar MODUL2 împarte numerele cu un acelaşi număr de cifre în mai mulţi paşi (întâi am pus patru, acum sunt totuşi trei, dar trebuia făcută această divizare). De asemenea, dispariţia situaţiei cu GIG.TXT unic, pe lângă uşurarea actualizărilor, a cauzat alte schimbări în apelarea în linie de comandă a programelor şi în antetele metodelor lor: acum NUMSIMPL, MODSPRIM, MODPRIM, MODMIN, MODIFSUM, CARONTE, VECUNG, VECUNGUL (la care ajung mai încolo), SUMRED, SUMM şi nu numai ele primesc argc şi argv în apelul de C al metodei main(), ca atunci când sunt apelate să lucreze explicit cu un GIG anume, acum când ele s-au înmulţit. De exemplu ./numsimpl /media/root/3TB/GIG420.TXT.
Cum au crescut noile fişiere numerice, au ajuns la urmă pe hard diskul de 3 TB de Toshiba. La 3 octombrie 2015 am cumpărat acel Western Digital, iar el împreună cu Hitachi de 1 TB din iulie 2011 şi cu Samsungul de 320 GB din 2009 (golit de vechiul Ubuntu şi pus la dispoziţie numerică) sunt pentru fişierele de acumulare. Am înţeles cu dezamăgire că trebuie să fiu rezervat în a folosi şi SSD-ul pentru scriere de fişiere numerice de mulţi GB, frecvent, care să fie şi şterse şi înlocuite cu altele, din cauză că aşa SSD-ul s-ar apropia repede de ieşirea din uz, şi hard diskurile sunt potrivite pentru munca aceea. Cred totuşi să mai pot scrie bine câte ceva de acumulare şi pe el, are cam 200 de miliarde de octeţi liberi acum.
Deja mă pune pe gânduri că are partiţie swap, pentru memorie, 16 GB binari din care de multe ori o parte consistentă se foloseşte, căci numerele tot folosesc multă memorie chiar dacă am mai avut stare pentru nişte reforme. Aş putea pune fişiere de căutare şi pe cât e liber acum din hard diskul de 3 TB, el încă are peste 1 TB liber; totuşi, l-am dedicat depozitelor numerice, care au crescut mult, depăşind jumătate din capacitatea lui şi valoarea însumată a vechilor GIG.TXT şi GIGNOU.TXT (şi NOU.TXT). Cele trei fişiere făceau înpreună 1754 sau 1755 de miliarde de octeţi, iar NOU.TXT avea şi fişiere cu numitori abundenţiali prea mari, iar acum depozitul numeric a urcat spre 1.9 TB. Să mai urce, să nu se mai ardă nimic. Şi mai sunt hard diskuri. Loc şi echilibru să fie.
Deocamdată am făcut şapte fişiere GIG până la 16 noiembrie 2015, rămâne GIG1910.TXT de făcut (cu cele mai mari numere).
Va trebui să mă adaptez la numerele foarte mari, căutarea şi actualizarea să nu mai urmărească neapărat un pas fix (putere de 10 cu putere de 10), ci să fie mai multe numere de cifre pe pas, fiind goluri în acest sens între numerele cele mai mari din fondul 1, pentru care, cu care şi din care se face toată acumularea, şi golurile vor afecta lucrul la fondul 2. Numerele mai mari sunt mai puţine, cele mai mari chiar mult mai puţine, aşa încât deşi ele sunt lungi, pot fi prinse într-un acelaşi pas de actualizare de depozit numeric numere de 1400 şi de 1900 de cifre, fără să depăşească memoria calculatorului. Este adevărat că de la alte numere mari, nu atât de mari, se adună mulţi GB.
(va urma)
*
La 27 septembrie 2015 am pornit procesul de regenerare numerică pentru fondul 2 alături de fondul 1, ca la vechiul GIG.TXT, devenit acum Vechea Glorie. După ora 12 pe 27 septembrie. Am început tot cu un fişier numit GIG.TXT, punând întâi în el, dacă ţin minte bine, numere de 100-120 de cifre, şi numere de pe la 60-80 de cifre (din zona lui "3.1"). Acum GIG.TXT stătea, într-adevăr, pe noul SSD, unde în noaptea distrugerii pusesem Ubuntu 15.04 după ce nu construisem corect pe stick o versiune beta de kit de Ubuntu 15.10, care era deja. Acum pe hard diskul Samsung era vechiul Ubuntu; GIG.TXT trebuia să meargă spre Noua Glorie.
Până în noaptea care a urmat, am reuşit să pun în el cam 40 de GB de numere, cu NUMSIMPL ca program de acumulare de numere. Am intuit că voi avea cu mare probabilitate nevoie de timp mai mult, peste o lună zi şi noapte, ca să ajung la dimensiunea pierdută (GIG + GIGNOU).
Dar am vrut mai multe numere decât cele pierdute. Astfel, am părăsit sub forţă situaţia de capitol 3 extins, cu fondul cu numitori peste 500000 şi până la un milion. 1048577 a devenit noua limită de neatins a numitorilor abundenţiali pentru viitorul fond 2, fără limită inferioară. Ca să urce numitorii până la 1048576 (2 la puterea 20), mai sus de un milion cum ar fi fost dacă nu murea hard diskul Seagate. Am ales totuşi astfel de limite măsurate, ştiind că mulţimea numerelor naturale şi cea a fracţionărilor abundenţiale sunt infinite şi estimând că paleta <=1048576 este rezonabil de compatibilă cu 2 sau 3 TB de spaţiu, chiar cu pierduţii teraocteţi înapoi.
În noua situaţie, voind multe numere repede, ca acest chin nedorit al regenerării să nu fie foarte lung, am văzut, în toamna 2015, ocazia altor reforme în proiectul cel numeric. Deşi am început pe 27 septembrie tot cu un singur GIG.TXT, am ştiut că este mai eficient ca de acum să fiu cu mai multe fişiere GIG, pe game de mărime numerică, după modelul de distribuire a vectorilor de factori primi pentru numere în funcţie de zonele de putere de 10: de exemplu, GIG52.TXT să aibă numerele mai mici de 10^52, apoi GIG80 pe cele de la 10^52 la 10^80 şi tot aşa după împărţirea vectorilor primi. Acum TRAT la NUMSIMPL a recăpătat o singură verificare dacă numitorul ireductibil înmulţit cu pragul abundenţial îl depăşeşte pe cel iniţial, şi cu un singur prag, cel de sus şi neatins 1048577, în loc de 1000001 cu 500000 la GIGNOU.TXT, sau în loc de 500001 la vechiul GIG.TXT.
Am revenit la statul târziu la calculator, chiar şi până la ziua următoare, şi la folosirea calculatorului în stil carenti termino*.
*Fără pauză, în limba latină.
Pornind noul fond 2 de la zero + fondul 1, cu NUMSIMPL (şi cu MODMIN, următorul fructuos la numerele mici, mai apoi şi cu MODSPRIM şi MODPRIM), la NUMSIMPL am realizat mai bine cum trebuie să pun factorii primi de legătură (de căutare) ca să vină mai repede multe numere: la umplerea unei zone goale, de exemplu [10^110, 10^130], întâi se caută (o dată, de două ori) în sus şi-n jos cu numere prime mai mici, până la 100, poate până la câteva sute, apoi trebuie repede trecut cu curaj la numere prime mai mari, care trec de 500, chiar de 1000, ajung la nivelul miilor.
La NUMSIMPL vor fi eficiente numerele prime mai mici de 1048577, în special cele până în 10000 au fost deja folosite, dar trebuie sărit cu curaj dincolo de 100-200 şi se adună mai multe numere în gama de populat.
Am reformat aparatul de actualizare a depozitului numeric: mai întâi, în ACTUAL.h în zonele unde se pot aduna foarte multe numere (cum sunt numerele de 30 până la 70 de cifre), chiar dacă se face actualizarea mergând crescător din putere de 10 în putere de 10 (din 1 în 1), tot vin prea multe numere pentru memoria calculatorului (chiar cu swap-ul de pe SSD). De exemplu pot să fie 400 de milioane de numere cu 49 de cifre, 450 de milioane cu 51 de cifre.
Atunci şi spaţiul de numere cu acelaşi număr de cifre trebuie împărţit, în trei zone sau chiar în patru (de exemplu: prima cifră 1 şi 2; apoi prima cifră 3 şi 4; 5 şi 6; 7, 8 şi 9) şi scade numărul de numere care intră în vector la un pas de actualizare. Acum chiar nu se mai poate sări, de exemplu, de la 44 la 47, sau de la 48 la 50.
De fapt, şi vechiul GIG.TXT ajunsese îndeajuns de încărcat în această zonă încât pasul din putere de 10 în putere de 10 să fie singurul, şi acela cu încărcătură destulă, dar la noile texte numerice, cu paleta abundenţială mai mare decât atunci, încărcarea este şi mai mare. Trebuia găsită o soluţie de progres.
Acum în ACTUAL.h există funcţia MODUL1 care actualizează GIG-ul corespunzător putere de 10 cu putere de 10, iar MODUL2 împarte numerele cu un acelaşi număr de cifre în mai mulţi paşi (întâi am pus patru, acum sunt totuşi trei, dar trebuia făcută această divizare). De asemenea, dispariţia situaţiei cu GIG.TXT unic, pe lângă uşurarea actualizărilor, a cauzat alte schimbări în apelarea în linie de comandă a programelor şi în antetele metodelor lor: acum NUMSIMPL, MODSPRIM, MODPRIM, MODMIN, MODIFSUM, CARONTE, VECUNG, VECUNGUL (la care ajung mai încolo), SUMRED, SUMM şi nu numai ele primesc argc şi argv în apelul de C al metodei main(), ca atunci când sunt apelate să lucreze explicit cu un GIG anume, acum când ele s-au înmulţit. De exemplu ./numsimpl /media/root/3TB/GIG420.TXT.
Cum au crescut noile fişiere numerice, au ajuns la urmă pe hard diskul de 3 TB de Toshiba. La 3 octombrie 2015 am cumpărat acel Western Digital, iar el împreună cu Hitachi de 1 TB din iulie 2011 şi cu Samsungul de 320 GB din 2009 (golit de vechiul Ubuntu şi pus la dispoziţie numerică) sunt pentru fişierele de acumulare. Am înţeles cu dezamăgire că trebuie să fiu rezervat în a folosi şi SSD-ul pentru scriere de fişiere numerice de mulţi GB, frecvent, care să fie şi şterse şi înlocuite cu altele, din cauză că aşa SSD-ul s-ar apropia repede de ieşirea din uz, şi hard diskurile sunt potrivite pentru munca aceea. Cred totuşi să mai pot scrie bine câte ceva de acumulare şi pe el, are cam 200 de miliarde de octeţi liberi acum.
Deja mă pune pe gânduri că are partiţie swap, pentru memorie, 16 GB binari din care de multe ori o parte consistentă se foloseşte, căci numerele tot folosesc multă memorie chiar dacă am mai avut stare pentru nişte reforme. Aş putea pune fişiere de căutare şi pe cât e liber acum din hard diskul de 3 TB, el încă are peste 1 TB liber; totuşi, l-am dedicat depozitelor numerice, care au crescut mult, depăşind jumătate din capacitatea lui şi valoarea însumată a vechilor GIG.TXT şi GIGNOU.TXT (şi NOU.TXT). Cele trei fişiere făceau înpreună 1754 sau 1755 de miliarde de octeţi, iar NOU.TXT avea şi fişiere cu numitori abundenţiali prea mari, iar acum depozitul numeric a urcat spre 1.9 TB. Să mai urce, să nu se mai ardă nimic. Şi mai sunt hard diskuri. Loc şi echilibru să fie.
Deocamdată am făcut şapte fişiere GIG până la 16 noiembrie 2015, rămâne GIG1910.TXT de făcut (cu cele mai mari numere).
Va trebui să mă adaptez la numerele foarte mari, căutarea şi actualizarea să nu mai urmărească neapărat un pas fix (putere de 10 cu putere de 10), ci să fie mai multe numere de cifre pe pas, fiind goluri în acest sens între numerele cele mai mari din fondul 1, pentru care, cu care şi din care se face toată acumularea, şi golurile vor afecta lucrul la fondul 2. Numerele mai mari sunt mai puţine, cele mai mari chiar mult mai puţine, aşa încât deşi ele sunt lungi, pot fi prinse într-un acelaşi pas de actualizare de depozit numeric numere de 1400 şi de 1900 de cifre, fără să depăşească memoria calculatorului. Este adevărat că de la alte numere mari, nu atât de mari, se adună mulţi GB.
(va urma)
Comentarii
Trimiteți un comentariu