Numerele și spațiul lor în 2016 (Partea I)
Am făcut și VECSUB.cc, o variantă cu abundență-numărător + numitor pentru VECUNSUB.
De asemenea am îmbogățit secțiunea de FACTORSUB-uri cu FACTMSUB.cc, FACTSUB.CC, FACTSUBM (fiecare folosește două mepezetele, ab și sm, în locul sumei inițiale de divizori), unde numitorul abundențial ab trebuie să fie mai mic decât 1048577 (limita de neatins a fondului 2). Primul e pentru numerele până la 52 de cifre, celălalt pentru de la 53 la 161 de cifre, iar ultimul pentru cele mai mari, 162 - 1910 cifre. Spre deosebire, FACTORSUB-urile modifică direct copia sumei numărului inițial, pe când aici se modifică pe drum abundențele.
La urmă, am desființat acele fișiere minimaliste care foloseau doar partea de SM(), ca MODMIN, MODIFMSUM sau HMODIFMSUM, SM() - urile fiind aduse înapoi lângă funcțiile din fișierele principale. Cu excepția tandemului SUMRED - SUMM. Am scăzut numărul surselor. Au rămas, în schimb, fișierele de tip 357, unde factorii primi de legătură 3, 5 și 7 sunt tratați special. Ei nu sunt defel folosiți în principale, adică la MODPRIM, MODSPRIM, NUMSIMPL, și am păstrat eliminarea lor cu SCOTFACT și tratarea lor în funcții speciale de sumare.
Am mai schimbat, crezând în rapidizare, ceva în funcțiile majore de sumare: SUMADIV, SUM, NUMSUM, SM, NUMSUM1: ca să se facă mai scurt și la obiect operațiile în zona primilor K (unde este cazul) sau H factori. Am construit, în decembrie 2015, și o funcție SMOD(), care vrea să calculeze direct fracția abundențială a numărului, fără suma divizorilor, dar este cu dus și întors, fiind mai potrivită pentru numerele mai mici decât al zecelea număr perfect (care are 54 de cifre) și pentru căutarea în jos.
Am făcut, tot în acea lună, reforme la fișierele legate strict de long double și unsigned long long, precum CDIV.cc, SUSNUM.CC (cu variantele CDIV2, SUSNUM2), inclusiv cu un echivalent al lui SMOD(). Dar în situațiile cu numere mai mari SMOD-ul ar fi mai costisitor, prin folosirea intensivă a mepezetelelor, CMMDC-urilor cu împărțiri de mepezetele (mpz_gcd, mpz_divexact, poate mpz_tdiv), așa că doar limitat la numere mai mici. Am implementat și în zona ”long double” calculul cu CMMDC al termenilor ireductibilei abundențiale, separând chiar suma divizorilor în două: suma puterii de 2 din numărul de bază și suma celui mai mare divizor impar, ca să fie naturale pe 64 de biți și nu long double. Acest nou calcul scoate din schemă folosirea acelei funcții de validare long double a numitorilor de abundență (până în 11), făcându-se în schimb o comparare cu 11.
La 22 ianuarie 2016 sunt 22806 numere în fondul 1, dar cele 29 de noutăți sunt peste 100 de cifre, nimic din zona lui ”3.1”. Am mai acumulat multe numere, noul fond glorios are peste 4 TB acum, și m-am gândit să iau în 2016 un hard disk de 4 TB care să-l înlocuiască pe cel de 320GB (nemaifiind loc în spațiul de hard diskuri din carcasa unității). De asemenea nu am adus nimic nou cu FACT(OR)SUB, și am constatat că acolo căutarea în jos (împărțire) aduce rezultatele multe, fără amestecare cu înmulțirea. Totuși, până acum tot acumularea de masă numerică de manevră a adus noutăți multe de fond 1. Căutările prin substituție aleatorie de puteri de factori primi nu au adus nimic, sau câteva numere noi prin 2014, nu acum, în 2016.
Am priceput mai bine cum să se aducă numere multe la căutare, iar arderea din 26 septembrie 2015 a fost piedică, dar a și prilejuit și mai mare acumulare de numere, însă o singură dată ajunge, și această singură dată este mult. Iar reformele de cod de până în iarna 2015-2016 poate că s-ar fi făcut și fără ardere. Ele au fost prinse cu gândul.
Imperiul numeric trebuie apărat.
În paralel cu valul mare de distrugeri din anul 2016, în care am nimicit pentru totdeauna sau cu perspectivă de încercări de refacere și rememorare mai multe obiecte ale trecutului, inclusiv acel Seagate Barracuda cu proiecte și cu vechile numere de fond 2, povestea cu numerele a continuat să crească pe modelul Noua Glorie. Au fost mărite, actualizate pe rând fiecare dintre cele opt fișiere mari numerice.
Am reumblat la funcțiile de calcul pentru MODPRIM, MODSPAR, MODPRIMSUM, MODIFSUM. Din martie 2016, a fost pus la punct un nou modul de numărare numerică, NUMNUM.cc, care să numere elementele din fiecare fișier numeric, când acesta este dat ca parametru; poate să curseze prin lista fișierelor și să numere, pe rând, mai multe fișiere la o execuție. Rezultatul, cu numele filei, numărul de numere, data și ora trebuiesc scrise pe ecran și în fișierul NUMNUM.TXT.
Dar NUMNUM.TXT nu a mai fost actualizat după 11 aprilie 2016. Erau atunci mai multe zeci de miliarde de numere în fișiere.
În prima jumătate de februarie 2016, când am pornit pe drumul distrugerilor, am și cumpărat un nou hard disc de 4 TB, tot Toshiba, cum e cel de 3 TB. S-a vrut a fi progres și campionul dimensional al echipamentului meu de calcul de acasă. De pe la 4 februarie sigur este.
Tot în acea săptămână, am scos din calculator Samsungul HD322HJ de 320 de gigaocteți zecimali, pentru ca să intre cu bine noul tetrateradisc. Dar s-a stricat și el fără să pornească electric, la fel ca Barracuda, deși nu l-am premeditat pentru aceasta. În seara de 3 februarie 2016 l-am scos, iar la 6 februarie am constatat că a murit și el. În săptămâna următoare pe la 10 februarie, am cumpărat încă un hard disc Toshiba, de 500 de GB, cu buffer de 32 MB în loc de 16 cât avea Samsungul, și l-am montat la adaptorul SATA-IDE, la o mufă de SATA a adaptorului, pe care adaptor l-am avut la 17 noiembrie 2015. În locașurile clasice de hard discuri nu mai era loc, iar SSD-ul stă în altă cavitate.
Astfel, sunt trei Toshibe. 4TB, 3TB și 500G.
Noua poveste cu numerele a mers mai departe, am lăsat-o și am crescut-o. Am făcut ștergeri și din fișierele-sursă vechi, rămase după dezastrul din 2015 definitivat în 2016, când de pildă am pierdut ce mai era din vechile fișiere MIRACL, pe care deja le alterasem cu cod de GMP până în 2013. Și din noile fișiere pure cu GMP/MPIR, de exemplu SONDABUND și ALTVALID, plus GUNOI.TXT nu mai există. Cea mai veche dată dintre fișierele de C pentru numere este 16 octombrie 2012, după ce scrisesem primele programe pentru GMP. În 2016 am văzut, în perioada de sezon cald, că nu am regenerat și construit corect fișierele GIG420.TXT și GIG1910.TXT, care conțineau multă masă numerică invalidă.
M-am mirat cum de au ajuns acele sute de gigaocteți de numere nepotrivite, poate pentru că partea de căutare în jos de la MODPRIM o scrisesem greșit în toamna anului 2015 (am reparat-o în 2016, dar mi s-a părut puțin pentru ca să fi cauzat atâtea numere greșite). Ca să repar fișierele, le-am reparcurs (total pe 420, parțial până la 684 pe 1910) în vara anului 2016, folosind FILTRARE.cc, și noile segmente filtrate le-am îmbogățit ca să mai crească la loc, fără însă să ajung iar la mărimile acelea până la 16 noiembrie 2016.
FILTRARE.cc e împărțit în trei zone: până la 10^52 (cu funcția SM(), pentru zona numerică unde nu sunt factori primi mai mari de 64 de biți), apoi până la 10^160, unde puterile factorilor primi de 64 de biți se păstrează și ele în 64 de biți, unde se folosește funcția NUMSUM() (poate să fie și SUM()), și respectiv zona mare până la 10^1910, unde deja și puterile unor numere prime mai mici sunt îndeajuns de mari să treacă de 2^64, și aici sumele de divizori se calculează cu SUMADIV().
În iulie 2016 m-am oprit la 10^584 cu filtrarea de la GIG1910.TXT, deja nu mai apăreau zone cu masă numerică invalidă. Poate că nu mai sunt, dar și durează mult o refiltrare în zona mai înaltă. Am avut în 2016 probleme la GIG1910.TXT și pentru numere peste 1000 de cifre, și s-au mai întâmplat scrieri proaste în fișiere unde, poate de la supraîncărcarea memoriei când se trece și în cea virtuală, sortarea nu se face crescător, ci amestecat, sau două numere consecutive se scriu lipite în loc de punere pe rânduri diferite, și aici rezultă un număr mai mare și în mod sigur necorespunzător, de unde să fie împărțire la 0.
Masa numerică invalidă cuprindea multe numere care aveau factorii primi din plaja stabilită, dar nu aveau numitorul abundenței mai mic de 1048577, și nu am înțeles foarte bine cum s-au calculat așa. Josul prost de la MODPRIM mi s-a părut insuficient să cauzeze atât, însă cred că mai puținele aduse de el puteau fi înmulțite serios prin căutările succesive făcute cu NUMSIMPL, unde deja intrau și numerele nevalide care să ducă mai departe la alte numere invalide. NUMSIMPL a fost cel mai bogat aducător de numere, l-am folosit mult, iar secundul său era MODPRIM.
Dar după ce a început luna septembrie 2016 am descoperit că pot avea încredere și în MODIFSUM ca îmbogățitor, destul de puțin pentru GIG1910 sau chiar GIG420, dar la fișierele tot mai mici el aduce mai mult. Chiar peste MODPRIM. NUMSIMPL încă este campionul volumic la aducere de numere, dar MODIFSUM m-a surprins plăcut, foarte multă vreme l-am desconsiderat pentru greutatea și puținătatea cu care aducea numere și-l vedeam. Însă acum s-a mai schimbat din impresie. În anii trecuți (2010-2013) nici nu distribuiam bine factorii de legătură (primi cu zero, una sau mai multe puteri în numărul de bază, la înmulțire/împărțire / neprimi impari / neprimi pari + numărul 2). Nu îi separam pe programe precise, ci stăteau la grămadă în vectorul de factori de legătură între numere (înmulțire / împărțire) atunci când făceam căutări, de pildă în 2011-2012 cu CARONTE2.cc (nu mai există).
(va urma)
De asemenea am îmbogățit secțiunea de FACTORSUB-uri cu FACTMSUB.cc, FACTSUB.CC, FACTSUBM (fiecare folosește două mepezetele, ab și sm, în locul sumei inițiale de divizori), unde numitorul abundențial ab trebuie să fie mai mic decât 1048577 (limita de neatins a fondului 2). Primul e pentru numerele până la 52 de cifre, celălalt pentru de la 53 la 161 de cifre, iar ultimul pentru cele mai mari, 162 - 1910 cifre. Spre deosebire, FACTORSUB-urile modifică direct copia sumei numărului inițial, pe când aici se modifică pe drum abundențele.
La urmă, am desființat acele fișiere minimaliste care foloseau doar partea de SM(), ca MODMIN, MODIFMSUM sau HMODIFMSUM, SM() - urile fiind aduse înapoi lângă funcțiile din fișierele principale. Cu excepția tandemului SUMRED - SUMM. Am scăzut numărul surselor. Au rămas, în schimb, fișierele de tip 357, unde factorii primi de legătură 3, 5 și 7 sunt tratați special. Ei nu sunt defel folosiți în principale, adică la MODPRIM, MODSPRIM, NUMSIMPL, și am păstrat eliminarea lor cu SCOTFACT și tratarea lor în funcții speciale de sumare.
Am mai schimbat, crezând în rapidizare, ceva în funcțiile majore de sumare: SUMADIV, SUM, NUMSUM, SM, NUMSUM1: ca să se facă mai scurt și la obiect operațiile în zona primilor K (unde este cazul) sau H factori. Am construit, în decembrie 2015, și o funcție SMOD(), care vrea să calculeze direct fracția abundențială a numărului, fără suma divizorilor, dar este cu dus și întors, fiind mai potrivită pentru numerele mai mici decât al zecelea număr perfect (care are 54 de cifre) și pentru căutarea în jos.
Am făcut, tot în acea lună, reforme la fișierele legate strict de long double și unsigned long long, precum CDIV.cc, SUSNUM.CC (cu variantele CDIV2, SUSNUM2), inclusiv cu un echivalent al lui SMOD(). Dar în situațiile cu numere mai mari SMOD-ul ar fi mai costisitor, prin folosirea intensivă a mepezetelelor, CMMDC-urilor cu împărțiri de mepezetele (mpz_gcd, mpz_divexact, poate mpz_tdiv), așa că doar limitat la numere mai mici. Am implementat și în zona ”long double” calculul cu CMMDC al termenilor ireductibilei abundențiale, separând chiar suma divizorilor în două: suma puterii de 2 din numărul de bază și suma celui mai mare divizor impar, ca să fie naturale pe 64 de biți și nu long double. Acest nou calcul scoate din schemă folosirea acelei funcții de validare long double a numitorilor de abundență (până în 11), făcându-se în schimb o comparare cu 11.
La 22 ianuarie 2016 sunt 22806 numere în fondul 1, dar cele 29 de noutăți sunt peste 100 de cifre, nimic din zona lui ”3.1”. Am mai acumulat multe numere, noul fond glorios are peste 4 TB acum, și m-am gândit să iau în 2016 un hard disk de 4 TB care să-l înlocuiască pe cel de 320GB (nemaifiind loc în spațiul de hard diskuri din carcasa unității). De asemenea nu am adus nimic nou cu FACT(OR)SUB, și am constatat că acolo căutarea în jos (împărțire) aduce rezultatele multe, fără amestecare cu înmulțirea. Totuși, până acum tot acumularea de masă numerică de manevră a adus noutăți multe de fond 1. Căutările prin substituție aleatorie de puteri de factori primi nu au adus nimic, sau câteva numere noi prin 2014, nu acum, în 2016.
Am priceput mai bine cum să se aducă numere multe la căutare, iar arderea din 26 septembrie 2015 a fost piedică, dar a și prilejuit și mai mare acumulare de numere, însă o singură dată ajunge, și această singură dată este mult. Iar reformele de cod de până în iarna 2015-2016 poate că s-ar fi făcut și fără ardere. Ele au fost prinse cu gândul.
Imperiul numeric trebuie apărat.
În paralel cu valul mare de distrugeri din anul 2016, în care am nimicit pentru totdeauna sau cu perspectivă de încercări de refacere și rememorare mai multe obiecte ale trecutului, inclusiv acel Seagate Barracuda cu proiecte și cu vechile numere de fond 2, povestea cu numerele a continuat să crească pe modelul Noua Glorie. Au fost mărite, actualizate pe rând fiecare dintre cele opt fișiere mari numerice.
Am reumblat la funcțiile de calcul pentru MODPRIM, MODSPAR, MODPRIMSUM, MODIFSUM. Din martie 2016, a fost pus la punct un nou modul de numărare numerică, NUMNUM.cc, care să numere elementele din fiecare fișier numeric, când acesta este dat ca parametru; poate să curseze prin lista fișierelor și să numere, pe rând, mai multe fișiere la o execuție. Rezultatul, cu numele filei, numărul de numere, data și ora trebuiesc scrise pe ecran și în fișierul NUMNUM.TXT.
Dar NUMNUM.TXT nu a mai fost actualizat după 11 aprilie 2016. Erau atunci mai multe zeci de miliarde de numere în fișiere.
În prima jumătate de februarie 2016, când am pornit pe drumul distrugerilor, am și cumpărat un nou hard disc de 4 TB, tot Toshiba, cum e cel de 3 TB. S-a vrut a fi progres și campionul dimensional al echipamentului meu de calcul de acasă. De pe la 4 februarie sigur este.
Tot în acea săptămână, am scos din calculator Samsungul HD322HJ de 320 de gigaocteți zecimali, pentru ca să intre cu bine noul tetrateradisc. Dar s-a stricat și el fără să pornească electric, la fel ca Barracuda, deși nu l-am premeditat pentru aceasta. În seara de 3 februarie 2016 l-am scos, iar la 6 februarie am constatat că a murit și el. În săptămâna următoare pe la 10 februarie, am cumpărat încă un hard disc Toshiba, de 500 de GB, cu buffer de 32 MB în loc de 16 cât avea Samsungul, și l-am montat la adaptorul SATA-IDE, la o mufă de SATA a adaptorului, pe care adaptor l-am avut la 17 noiembrie 2015. În locașurile clasice de hard discuri nu mai era loc, iar SSD-ul stă în altă cavitate.
Astfel, sunt trei Toshibe. 4TB, 3TB și 500G.
Noua poveste cu numerele a mers mai departe, am lăsat-o și am crescut-o. Am făcut ștergeri și din fișierele-sursă vechi, rămase după dezastrul din 2015 definitivat în 2016, când de pildă am pierdut ce mai era din vechile fișiere MIRACL, pe care deja le alterasem cu cod de GMP până în 2013. Și din noile fișiere pure cu GMP/MPIR, de exemplu SONDABUND și ALTVALID, plus GUNOI.TXT nu mai există. Cea mai veche dată dintre fișierele de C pentru numere este 16 octombrie 2012, după ce scrisesem primele programe pentru GMP. În 2016 am văzut, în perioada de sezon cald, că nu am regenerat și construit corect fișierele GIG420.TXT și GIG1910.TXT, care conțineau multă masă numerică invalidă.
M-am mirat cum de au ajuns acele sute de gigaocteți de numere nepotrivite, poate pentru că partea de căutare în jos de la MODPRIM o scrisesem greșit în toamna anului 2015 (am reparat-o în 2016, dar mi s-a părut puțin pentru ca să fi cauzat atâtea numere greșite). Ca să repar fișierele, le-am reparcurs (total pe 420, parțial până la 684 pe 1910) în vara anului 2016, folosind FILTRARE.cc, și noile segmente filtrate le-am îmbogățit ca să mai crească la loc, fără însă să ajung iar la mărimile acelea până la 16 noiembrie 2016.
FILTRARE.cc e împărțit în trei zone: până la 10^52 (cu funcția SM(), pentru zona numerică unde nu sunt factori primi mai mari de 64 de biți), apoi până la 10^160, unde puterile factorilor primi de 64 de biți se păstrează și ele în 64 de biți, unde se folosește funcția NUMSUM() (poate să fie și SUM()), și respectiv zona mare până la 10^1910, unde deja și puterile unor numere prime mai mici sunt îndeajuns de mari să treacă de 2^64, și aici sumele de divizori se calculează cu SUMADIV().
În iulie 2016 m-am oprit la 10^584 cu filtrarea de la GIG1910.TXT, deja nu mai apăreau zone cu masă numerică invalidă. Poate că nu mai sunt, dar și durează mult o refiltrare în zona mai înaltă. Am avut în 2016 probleme la GIG1910.TXT și pentru numere peste 1000 de cifre, și s-au mai întâmplat scrieri proaste în fișiere unde, poate de la supraîncărcarea memoriei când se trece și în cea virtuală, sortarea nu se face crescător, ci amestecat, sau două numere consecutive se scriu lipite în loc de punere pe rânduri diferite, și aici rezultă un număr mai mare și în mod sigur necorespunzător, de unde să fie împărțire la 0.
Masa numerică invalidă cuprindea multe numere care aveau factorii primi din plaja stabilită, dar nu aveau numitorul abundenței mai mic de 1048577, și nu am înțeles foarte bine cum s-au calculat așa. Josul prost de la MODPRIM mi s-a părut insuficient să cauzeze atât, însă cred că mai puținele aduse de el puteau fi înmulțite serios prin căutările succesive făcute cu NUMSIMPL, unde deja intrau și numerele nevalide care să ducă mai departe la alte numere invalide. NUMSIMPL a fost cel mai bogat aducător de numere, l-am folosit mult, iar secundul său era MODPRIM.
Dar după ce a început luna septembrie 2016 am descoperit că pot avea încredere și în MODIFSUM ca îmbogățitor, destul de puțin pentru GIG1910 sau chiar GIG420, dar la fișierele tot mai mici el aduce mai mult. Chiar peste MODPRIM. NUMSIMPL încă este campionul volumic la aducere de numere, dar MODIFSUM m-a surprins plăcut, foarte multă vreme l-am desconsiderat pentru greutatea și puținătatea cu care aducea numere și-l vedeam. Însă acum s-a mai schimbat din impresie. În anii trecuți (2010-2013) nici nu distribuiam bine factorii de legătură (primi cu zero, una sau mai multe puteri în numărul de bază, la înmulțire/împărțire / neprimi impari / neprimi pari + numărul 2). Nu îi separam pe programe precise, ci stăteau la grămadă în vectorul de factori de legătură între numere (înmulțire / împărțire) atunci când făceam căutări, de pildă în 2011-2012 cu CARONTE2.cc (nu mai există).
(va urma)
Comentarii
Trimiteți un comentariu