Diverse însemnări despre numere, valabile pe la 2015-2017
*** PARTEA I ***
Comentarii pentru ACTUAL2.h, headerul de lucru de la VECUNGUL.cc:
//La folosirea directă a vectorului de stringuri în locul GMP-ului: se poate face filtrare abundenţială.
//Se iau numerele din texte, se fac sortarea şi căutarea binară fără nicio conversie la GMP de la char *, se scriu în textele sursă.
//Dacă se face alocare dinamică de char *a[N], memoria este dublă spre triplă, cu malloc şi free. Consum mare.
//Dacă se păstrează declararea statică a vectorului, trebuie mai multă atenţie acum, şi nu se foloseşte aceeaşi sortare, ci deocamdată Quick Sort.
//De verificat aplicabilitatea căutării binare strcmp la vectorul static.
//Şi, fireşte, vitezele de sortare şi căutare, care trebuie să fie competitive şi de preferinţă mai mari decât în situaţia cu GMP.
//Vectorii char* alocaţi static au un consum rezonabil de memorie, vecin cu cel al GMP-ului. La dinamici se iroseşte memorie.
//Există mai mulţi algoritmi de sortare a vectorilor de stringuri (în C simplu, char ** sau char[][Dimensiune2], primul caz fiind cu pointeri).
//Aici se merge pe faptul că lungimile stringurilor vor fi mereu egale: de exemplu fiecare număr ca string are 19 cifre, se termină cu \n şi apoi stringul se termină şi el cu '\0'.
//Total 20 de caractere dimensiunea 2, cea a fiecărui element vectorial din şirul de stringuri.
//Sortarea de stringuri e mai simplă când dimensiunile sunt bine precizate, şi caracterele conţinute, de asemenea bine precizate: cifre şi terminatorul de linie nouă.
//Dimensiunea de reglat.
//La ADUNTEXT0 și la ADUNTEXT1 se poate scăpa de parametri: c la prima și c, p1 cu z la a doua.
//a1 = 92, b1 = 94, a1+1 vine 93 aici, iar b1 + 2 vine 96.
//Au voie numere de 93 sau 94 de cifre, de la 10^92 sub 10^94.
//z - 1 e numărul adevărat de cifre al numărului, fără indicatorul de linie nouă.
//93-94, versus 93 cu 96.
//max sub 93 = prea jos, min+2 peste 96 = prea sus.
//Mai poate să fie fișier în modificare, unde se scrie încă, și merită cercetate aici cele care nu sunt prea sus, nici prea jos,
//iar dacă apucă să se observe schimbarea dimensiunii, atunci nu trebuiesc lucrate nici ele.
//Dar se poate ca scrierea să fie lentă, de pildă numsimpli cu factori primi foarte puțini și foarte mari, sau FACTORSUBM-uri peste 1000 de cifre.
//Și atunci, cea mai bună soluție este ca fișierele încă în scriere nici să nu fie băgate în seamă aici,
//ca să nu se scrie degeaba în ele numărul 10^1917 + 1.
//Poate că ar fi bine ca fesebelele să nu fie supuse verificării prea sus / prea jos, din cauza nemonotoniei mărimilor numerelor lor generate cu RandomLib.
//Dar unele fesebele ajung la GB, și pot fi astfel luate în calcul chiar când intervalul de căutare chiar nu le privește.
//Măcar la MODIFSUM, NUMSIMPL, MODPRIM: se respectă o păstrare a unei variații de zero ori o cifră între lungimile a două numere vecine găsite,
//că factorii primi de legătură folosiți la căutarea lor, pornitori de la numere ordonate strict crescător,
//variază maxim între ei cu mai puțin de un ordin de mărime zecimal (de exemplu între 130 și 1300),
//iar numerele de bază consecutive au lungimi de regulă egale, maxim o cifră deosebire și la ei când vecinii sunt, de pildă,
//cel mai mare număr de 93 de cifre din GIG100.TXT plus cel mai mic de 94 de cifre.
//Oricum pare că în aceste fișiere de căutare rezultate din numere ordonate cu înmulțiri și împărțiri prin factori ordonați, ordonare ca mărime,
//două numere alăturate vor avea lungimi egale sau diferite cu 1, fără ca la actualizarea vecungulară să răzbată asupra limitelor a1-b1, unde de regulă treapta de căutare presupune o singură unitate zecimală între a1 și b1,
//adică a1 + 1 să fie b1.
//Dar la fesebele pot fi deosebiri marcante între două numere alăturate, și căutările inițiale de număr maxim ori minim de cifre în fișier să nu prindă chiar numerele extreme cuvenite, ca să le raporteze lungimile la a1 și la b1,
//în același timp, din cauza eventualității unor GB în dimensiunile fesebelelor, fiind o chestiune delicată permiterea de căutare în ÎNTREAGA fesebea după maxim și minim.
//Că se parcurg primii și ultimii c octeți din fișier, dar nu tot fișierul, și suma c+c este mult sub GB. S-ar cere timp, special pentru parcurgerea exhaustivă a fesebelei.
//Deja pentru fesebele nu se face parcurgerea prin URC(), care să scutească fișierul de trecerea prin anumite zone numerice considerate tratate.
//La celelalte fișiere cu rezultate de căutare, se fac și parcurgeri prin URC(), ca să se treacă direct peste zone numerice deja abordate. Acolo se consideră o oarecare ordonare în mod crescător, a numerelor.
//Fără această parcurgere, special pentru fesebele am mărit artificial deschiderea capetelor de minim + maxim, 5 în jos și 5 în sus.
//9999*100 versus 10000*999? Același număr de cifre + 1.
*** PARTEA II ***
/*
La 26 martie 2017 mi-a trecut prin cap că pot face căutare mai rapidă, optimă, bazată strict pe numerele noi depozitate în fișierele de tip LITUAN, mai degrabă decât să reparcurg în fișierele mari multe numere deja prezente și folosite, răs-folosite în căutări pentru numere noi.
Fișierele LITUAN sunt mai mici decât marile depozite numerice.
Mai pe urmă, în jurul lui 1 aprilie 2017, am început să ordonez crescător chiar conținutul acumulat al fișierelor cu rezultate de căutare, adică să le aduc conținutul în câte un singur fișier (BAHNERBALD.TXT) pe care apoi să îl parcurg succesiv, eșalonat pe intervale dispuse crescător, ca să pun numerele din ele, fără duplicate, în TTEXT.TXT, sortate strict crescător și unice, așadar. Au apărut mai multe TTEXT.TXT, unele chiar peste 150 de miliarde de octeți sau gigabaiți zecimali, cu multă muncă de construire, din care să caut mai departe cu alte fișiere de rezultate, și tot așa, renunțând temporar la a căuta direct din depozitele mari (numai că și TTEXT-urile pot fi mari), pe principiul că în cele mari sunt deja multe numere răs-folosite la căutare, pe când din mai micile fișiere LITUAN și TTEXT (nu îndeajuns de mici pentru puținătate de rezultate, dar nici la fel de mari ca fișierele GIG), poate cu multe numere noi și nefolosite în GIG-uri, pot fi obținute alte numere noi, mai rapid decât la exhaustiva parcurgere a întregimii mai multor GIG-uri.
La actualizarea celor mari, fișiere de rezultate strict crescător ordonate pot să însemne avantaje la folosirea funcției URC() prin ele și la optimizarea parcurgerii intervalului de mărime numerică în care se caută (dar dacă fișierul este mare cu zeci de GB aglomerare într-o singură unitate de putere zecimală, tot greu este), plus optimizarea condițiilor de stabilire a lungimii potrivite a șirului de caractere reprezentant al numărului, la ADUNTEXT.
Dar mă și gândesc că deja în 2017 echipamentul de acasă este mediocru sau chiar rămânător în urmă, cu dotarea RAM + procesorul + video + chiar cantitatea de TB din stocare. Din păcate SSD-urile rămân scumpe, cele plusterabaitice chiar scumpe tare, dar nici hard diskurile peste 4 TB nu sunt îndeajuns de ieftine. Mă gândeam la temerarul gest de-a-mi lua SSD de 1 TB + un HDD de 6 TB (vreo 2000 de lei ar costa cuplul?), și atunci SSD-ul l-aș pune pe locul celui de 240 GB de acum, HDD-ul de 500 GB l-aș scoate de la adaptorul IDE ca să-l pun pe cel de 1 TB (Hitachi din 2011) să stea acolo, iar pe locul HDD-ului de 1 TB l-aș monta chiar pe cel de 6 TB, câștigând astfel 5.5 TB zecimali de HDD + 0.76 TB zecimali de SSD. Iar HDD-ul de 1 TB și SSD-ul de 240 de GB ar deveni ori piese de rezervă, ori poate cadouri pentru colegul meu Silviu.
*/
Tot cu ocazia venirii lunii aprilie 2017 am schimbat purtarea funcției IATEXT() din ACTUAL.h (VECUNG.cc) și ACTUAL2.h (VECUNGUL.cc), ca să spună pe un singur rând câte cifre au limitele intervalului de căutare, minimul și maximul de cifre din fișier și dacă este prea sus, prea jos sau în mișcare fișierul. Că prea erau multe rânduri, și, apropo de contragerea de tip TTEXT, prea multe fișiere folosite la actualizare.
Și expresiile ternare cu semn de întrebare au fost folosite în chestiune.
Interzis la MODPRIM:
-să folosesc partea de MODPINT dacă puterile de 10 la care se caută trec de 135.
23562723457267347065789548996709904988477547858392600710143027597506337283178622239730365539602600561360255566462503270175052892578043215543382498428777152427010394496918664028644534128033831439790236838624033171435922356643219703101720713163527487298747400647801939587165936401087419375649057918549492160555646976
Al treisprezecelea număr perfect. O fi putând fi folosit în rangul numerelor de până la 1910 cifre?
Comentarii pentru ACTUAL2.h, headerul de lucru de la VECUNGUL.cc:
//La folosirea directă a vectorului de stringuri în locul GMP-ului: se poate face filtrare abundenţială.
//Se iau numerele din texte, se fac sortarea şi căutarea binară fără nicio conversie la GMP de la char *, se scriu în textele sursă.
//Dacă se face alocare dinamică de char *a[N], memoria este dublă spre triplă, cu malloc şi free. Consum mare.
//Dacă se păstrează declararea statică a vectorului, trebuie mai multă atenţie acum, şi nu se foloseşte aceeaşi sortare, ci deocamdată Quick Sort.
//De verificat aplicabilitatea căutării binare strcmp la vectorul static.
//Şi, fireşte, vitezele de sortare şi căutare, care trebuie să fie competitive şi de preferinţă mai mari decât în situaţia cu GMP.
//Vectorii char* alocaţi static au un consum rezonabil de memorie, vecin cu cel al GMP-ului. La dinamici se iroseşte memorie.
//Există mai mulţi algoritmi de sortare a vectorilor de stringuri (în C simplu, char ** sau char[][Dimensiune2], primul caz fiind cu pointeri).
//Aici se merge pe faptul că lungimile stringurilor vor fi mereu egale: de exemplu fiecare număr ca string are 19 cifre, se termină cu \n şi apoi stringul se termină şi el cu '\0'.
//Total 20 de caractere dimensiunea 2, cea a fiecărui element vectorial din şirul de stringuri.
//Sortarea de stringuri e mai simplă când dimensiunile sunt bine precizate, şi caracterele conţinute, de asemenea bine precizate: cifre şi terminatorul de linie nouă.
//Dimensiunea de reglat.
//La ADUNTEXT0 și la ADUNTEXT1 se poate scăpa de parametri: c la prima și c, p1 cu z la a doua.
//a1 = 92, b1 = 94, a1+1 vine 93 aici, iar b1 + 2 vine 96.
//Au voie numere de 93 sau 94 de cifre, de la 10^92 sub 10^94.
//z - 1 e numărul adevărat de cifre al numărului, fără indicatorul de linie nouă.
//93-94, versus 93 cu 96.
//max sub 93 = prea jos, min+2 peste 96 = prea sus.
//Mai poate să fie fișier în modificare, unde se scrie încă, și merită cercetate aici cele care nu sunt prea sus, nici prea jos,
//iar dacă apucă să se observe schimbarea dimensiunii, atunci nu trebuiesc lucrate nici ele.
//Dar se poate ca scrierea să fie lentă, de pildă numsimpli cu factori primi foarte puțini și foarte mari, sau FACTORSUBM-uri peste 1000 de cifre.
//Și atunci, cea mai bună soluție este ca fișierele încă în scriere nici să nu fie băgate în seamă aici,
//ca să nu se scrie degeaba în ele numărul 10^1917 + 1.
//Poate că ar fi bine ca fesebelele să nu fie supuse verificării prea sus / prea jos, din cauza nemonotoniei mărimilor numerelor lor generate cu RandomLib.
//Dar unele fesebele ajung la GB, și pot fi astfel luate în calcul chiar când intervalul de căutare chiar nu le privește.
//Măcar la MODIFSUM, NUMSIMPL, MODPRIM: se respectă o păstrare a unei variații de zero ori o cifră între lungimile a două numere vecine găsite,
//că factorii primi de legătură folosiți la căutarea lor, pornitori de la numere ordonate strict crescător,
//variază maxim între ei cu mai puțin de un ordin de mărime zecimal (de exemplu între 130 și 1300),
//iar numerele de bază consecutive au lungimi de regulă egale, maxim o cifră deosebire și la ei când vecinii sunt, de pildă,
//cel mai mare număr de 93 de cifre din GIG100.TXT plus cel mai mic de 94 de cifre.
//Oricum pare că în aceste fișiere de căutare rezultate din numere ordonate cu înmulțiri și împărțiri prin factori ordonați, ordonare ca mărime,
//două numere alăturate vor avea lungimi egale sau diferite cu 1, fără ca la actualizarea vecungulară să răzbată asupra limitelor a1-b1, unde de regulă treapta de căutare presupune o singură unitate zecimală între a1 și b1,
//adică a1 + 1 să fie b1.
//Dar la fesebele pot fi deosebiri marcante între două numere alăturate, și căutările inițiale de număr maxim ori minim de cifre în fișier să nu prindă chiar numerele extreme cuvenite, ca să le raporteze lungimile la a1 și la b1,
//în același timp, din cauza eventualității unor GB în dimensiunile fesebelelor, fiind o chestiune delicată permiterea de căutare în ÎNTREAGA fesebea după maxim și minim.
//Că se parcurg primii și ultimii c octeți din fișier, dar nu tot fișierul, și suma c+c este mult sub GB. S-ar cere timp, special pentru parcurgerea exhaustivă a fesebelei.
//Deja pentru fesebele nu se face parcurgerea prin URC(), care să scutească fișierul de trecerea prin anumite zone numerice considerate tratate.
//La celelalte fișiere cu rezultate de căutare, se fac și parcurgeri prin URC(), ca să se treacă direct peste zone numerice deja abordate. Acolo se consideră o oarecare ordonare în mod crescător, a numerelor.
//Fără această parcurgere, special pentru fesebele am mărit artificial deschiderea capetelor de minim + maxim, 5 în jos și 5 în sus.
//9999*100 versus 10000*999? Același număr de cifre + 1.
*** PARTEA II ***
/*
La 26 martie 2017 mi-a trecut prin cap că pot face căutare mai rapidă, optimă, bazată strict pe numerele noi depozitate în fișierele de tip LITUAN, mai degrabă decât să reparcurg în fișierele mari multe numere deja prezente și folosite, răs-folosite în căutări pentru numere noi.
Fișierele LITUAN sunt mai mici decât marile depozite numerice.
Mai pe urmă, în jurul lui 1 aprilie 2017, am început să ordonez crescător chiar conținutul acumulat al fișierelor cu rezultate de căutare, adică să le aduc conținutul în câte un singur fișier (BAHNERBALD.TXT) pe care apoi să îl parcurg succesiv, eșalonat pe intervale dispuse crescător, ca să pun numerele din ele, fără duplicate, în TTEXT.TXT, sortate strict crescător și unice, așadar. Au apărut mai multe TTEXT.TXT, unele chiar peste 150 de miliarde de octeți sau gigabaiți zecimali, cu multă muncă de construire, din care să caut mai departe cu alte fișiere de rezultate, și tot așa, renunțând temporar la a căuta direct din depozitele mari (numai că și TTEXT-urile pot fi mari), pe principiul că în cele mari sunt deja multe numere răs-folosite la căutare, pe când din mai micile fișiere LITUAN și TTEXT (nu îndeajuns de mici pentru puținătate de rezultate, dar nici la fel de mari ca fișierele GIG), poate cu multe numere noi și nefolosite în GIG-uri, pot fi obținute alte numere noi, mai rapid decât la exhaustiva parcurgere a întregimii mai multor GIG-uri.
La actualizarea celor mari, fișiere de rezultate strict crescător ordonate pot să însemne avantaje la folosirea funcției URC() prin ele și la optimizarea parcurgerii intervalului de mărime numerică în care se caută (dar dacă fișierul este mare cu zeci de GB aglomerare într-o singură unitate de putere zecimală, tot greu este), plus optimizarea condițiilor de stabilire a lungimii potrivite a șirului de caractere reprezentant al numărului, la ADUNTEXT.
Dar mă și gândesc că deja în 2017 echipamentul de acasă este mediocru sau chiar rămânător în urmă, cu dotarea RAM + procesorul + video + chiar cantitatea de TB din stocare. Din păcate SSD-urile rămân scumpe, cele plusterabaitice chiar scumpe tare, dar nici hard diskurile peste 4 TB nu sunt îndeajuns de ieftine. Mă gândeam la temerarul gest de-a-mi lua SSD de 1 TB + un HDD de 6 TB (vreo 2000 de lei ar costa cuplul?), și atunci SSD-ul l-aș pune pe locul celui de 240 GB de acum, HDD-ul de 500 GB l-aș scoate de la adaptorul IDE ca să-l pun pe cel de 1 TB (Hitachi din 2011) să stea acolo, iar pe locul HDD-ului de 1 TB l-aș monta chiar pe cel de 6 TB, câștigând astfel 5.5 TB zecimali de HDD + 0.76 TB zecimali de SSD. Iar HDD-ul de 1 TB și SSD-ul de 240 de GB ar deveni ori piese de rezervă, ori poate cadouri pentru colegul meu Silviu.
*/
Tot cu ocazia venirii lunii aprilie 2017 am schimbat purtarea funcției IATEXT() din ACTUAL.h (VECUNG.cc) și ACTUAL2.h (VECUNGUL.cc), ca să spună pe un singur rând câte cifre au limitele intervalului de căutare, minimul și maximul de cifre din fișier și dacă este prea sus, prea jos sau în mișcare fișierul. Că prea erau multe rânduri, și, apropo de contragerea de tip TTEXT, prea multe fișiere folosite la actualizare.
Și expresiile ternare cu semn de întrebare au fost folosite în chestiune.
Interzis la MODPRIM:
-să folosesc partea de MODPINT dacă puterile de 10 la care se caută trec de 135.
23562723457267347065789548996709904988477547858392600710143027597506337283178622239730365539602600561360255566462503270175052892578043215543382498428777152427010394496918664028644534128033831439790236838624033171435922356643219703101720713163527487298747400647801939587165936401087419375649057918549492160555646976
Al treisprezecelea număr perfect. O fi putând fi folosit în rangul numerelor de până la 1910 cifre?
Comentarii
Trimiteți un comentariu