Situația programelor și-a numerelor în sezonul vară-toamnă 2014 (Partea II)
În funcțiile IATEXT() de la actualizarea GIG.TXT se fac unele operații (stabilirea unui prag maxim de culegere de rezultate pe pas, urcarea la un prag minim de pornire în fișier cu funcția URC1()) cu fișierele SUS/JOS, discriminate în funcție de prima literă (S sau J), iar fișierele FSB sunt discriminate de SUS/JOS după (ne)prezența literei F la început.
Dacă în timpul actualizării se trece prin zone unde s-au format numere suspecte, se face validarea abundențială a întregului interval actualizat pentru GIG.TXT, pe pas, cu SM/SUM/SUMADIV, verificarea dacă suma este mai mare decât numărul și VALIDR().
SM(), SUM() și SUMADIV() sunt alese în funcție de intervalul de căutare căruia i s-au adresat numerele de bază din GIG.TXT la respectiva sesiune de căutări, pe puteri de 10 (<=52 pentru SM, <=160 pentru SUM, restul pentru SUMADIV). Se poate întâmpla să apară numere nepotrivite, posibil dacă se depășește memoria de bază a calculatorului și se ajunge la swap, poate în timpul sortării.
Se folosește acum pentru sortare funcția HS() din INTERC.h, care este o adaptare a Heap Sort-ului pentru mepezetele.
Înainte a fost folosită funcția INTERC() de la care a fost dat numele headerului, o metodă rapidă de a sorta crescător cantități numerice gigant (iar HS are rapiditate apropiată de aceasta), adică interclasare adaptată, numai că acolo se dublează memoria de vector de numere (un vector în plus cu numerele trimise la sortat), pe când Heap Sort nu are vector adițional, doar pe cel de bază, așa că îi pot fi trimise mai multe numere pe pas. Dar RAM-ul din calculator este firește limitat (16 GB instalați), plus încă vreo 16 de swap (mai lenți, problemă). De preferat încadrarea în memoria de bază. Și sistemul nici nu folosește fix 16.0 GB, ci vreo 15.5 din aceasta.
Înainte de interclasare am folosit QS(), quick sort, în două forme consecutive (am început când încă eram sub Windows), era rapidă, dar la prima formă se întâmpla să dea o eroare neexplicată, în Windows, în 2012 (VECUNG.EXE has encountered a problem and needs to close.), apoi (am și trecut la Linux) forma II nu mai termina de sortat o cantitate ceva mai mare de numere, stătea mult. Am avut și segmentation fault de la QS() în Linux. Așa că am trecut la INTERC() (care de asemenea a avut două forme în timp, prima mai îndelungată), mai rapidă, dar cu prețul vectorului în plus.
Și mai înainte, adică din vara 2010 până în prima parte din 2012 (iarna), am folosit la actualizare funcția SIB(), sortarea prin inserție binară (am mai scris despre SIB, QS și INTERC). Știam de atunci că interclasarea are memorie în plus, chiar dacă este eficientă, și am fost reticent față de ea, am avut impresia că Quick Sort-ul nu este foarte bun, și că inserția binară are rapiditate (într-adevăr, făcea repede, numai că atunci, în special în 2010, și cantitățile de numere erau cu mult sub cele de astăzi).
SIB() nu are complexitate n*n, are ceva de tipul n cu log(n), fiind cu parte binară (log(n) înseamnă logaritm în baza 2 din n, nu Euler).
Există și sortare prin inserție directă, dar mai lentă (inserția, selecția și bulele sunt metode de sortare din clasa de jos, n*n, merg bine pe numere puține, dar pe multe (și mari) ar fi lente.
Deci așa arată cronologia funcțiilor de sortare crescătoare pentru actualizarea depozitului numeric (și, până în ianuarie 2014, și pentru căutări sortam): SIB(), QS(), INTERC(), HS().
La 27 septembrie 2014 a fost desființată denumirea de GILIPOLLAN folosită pentru folder-ul de lucru numeric încă din toamna 2008/2009. Avea origine îndepărtată spaniolă, la GILIPOLLAS. A fost denumirea permanentă a dosarului cu fișiere numerice în acești ani, inclusiv din toamna anului 2012, când, trecând la Linux, am fixat punctul de pornire (rădăcină) al fișierelor în / (root), în afara lui GILIPOLLAN.
GILIPOLLAN a fost dosarul special pentru numere, în care au fost conținute fișierele de luptă numerică: făcut în octombrie (?) 2008, din noiembrie 2009 a fost casa asiduă a numerelor, sub Windows, și a rămas ca spațiu de mișcare numerică după 30 septembrie 2012, când am găsit beneficiul de viteză al GMP-ului.
În iulie 2011 când am primit noul calculator, cu procesor mai bogat, am făcut în GILIPOLLAN sub-folderele 1 (?), 2, 3 și 4 pentru ca fiecare thread să-și aibă într-un loc programul numeric care să ruleze pe el. În 1 există și T, directorul cu programul care face fișiere goale, și mi se pare că din primăvara 2011 (când am făcut prima dată acel program) până în vară T a fost singurul sub-folder în GILIPOLLAN, apoi au apărut 1 (care l-a luat pe T), 2, 3 și 4. Din toamna 2012 când am ieșit din GILIPOLLAN, s-a adăugat / ca zonă de rulare.
Așadar: /, /GILIPOLLAN, /GILIPOLLAN/1, /GILIPOLLAN/1/T, /GILIPOLLAN/2, /GILIPOLLAN/3, /GILIPOLLAN/4. De asemenea copii de GILIPOLLAN pe cele 2 hard disk-uri mai mari, tocmai pentru a fi multe locuri în care să pot face fișiere de rezultate când căutarea e mai lungă și mai mult de 7 anumite sub-căutări se termină. Fiecare fișier trebuie făcut și scris într-o singură căutare, fără refolosire înaintea actualizării GIG.TXT, apoi conținutul lor dispare.
Numele nou al folderului pentru numere este: NUMERIC.
Pentru conflictul de nume cu executabilul NUMERIC, de la NUMERIC.cc, ele au devenit NUMERICUL și NUMERICUL.cc, pe rădăcină (prezente așa și în NUMERICUL.sh din /).
Numele fișierelor de rezultate la căutările numerice sunt:
SUS.TXT, JOS.TXT, eventual SUS1/JOS1 (am mai scris despre numele lor). La FACTORSUBuri FSB.TXT, iar la RAPIDNUM RAP.TXT.
Fișierul REM.cc este programat să șteargă toate fișierele de căutare de tipul SUS, JOS, FSB, RAP de pe cele trei hard disk-uri (cele diferite de cel de sistem se numesc /media/root/1TB - 1 TB - și /media/root/2TB, celălalt).
(va urma)
Dacă în timpul actualizării se trece prin zone unde s-au format numere suspecte, se face validarea abundențială a întregului interval actualizat pentru GIG.TXT, pe pas, cu SM/SUM/SUMADIV, verificarea dacă suma este mai mare decât numărul și VALIDR().
SM(), SUM() și SUMADIV() sunt alese în funcție de intervalul de căutare căruia i s-au adresat numerele de bază din GIG.TXT la respectiva sesiune de căutări, pe puteri de 10 (<=52 pentru SM, <=160 pentru SUM, restul pentru SUMADIV). Se poate întâmpla să apară numere nepotrivite, posibil dacă se depășește memoria de bază a calculatorului și se ajunge la swap, poate în timpul sortării.
Se folosește acum pentru sortare funcția HS() din INTERC.h, care este o adaptare a Heap Sort-ului pentru mepezetele.
Înainte a fost folosită funcția INTERC() de la care a fost dat numele headerului, o metodă rapidă de a sorta crescător cantități numerice gigant (iar HS are rapiditate apropiată de aceasta), adică interclasare adaptată, numai că acolo se dublează memoria de vector de numere (un vector în plus cu numerele trimise la sortat), pe când Heap Sort nu are vector adițional, doar pe cel de bază, așa că îi pot fi trimise mai multe numere pe pas. Dar RAM-ul din calculator este firește limitat (16 GB instalați), plus încă vreo 16 de swap (mai lenți, problemă). De preferat încadrarea în memoria de bază. Și sistemul nici nu folosește fix 16.0 GB, ci vreo 15.5 din aceasta.
Înainte de interclasare am folosit QS(), quick sort, în două forme consecutive (am început când încă eram sub Windows), era rapidă, dar la prima formă se întâmpla să dea o eroare neexplicată, în Windows, în 2012 (VECUNG.EXE has encountered a problem and needs to close.), apoi (am și trecut la Linux) forma II nu mai termina de sortat o cantitate ceva mai mare de numere, stătea mult. Am avut și segmentation fault de la QS() în Linux. Așa că am trecut la INTERC() (care de asemenea a avut două forme în timp, prima mai îndelungată), mai rapidă, dar cu prețul vectorului în plus.
Și mai înainte, adică din vara 2010 până în prima parte din 2012 (iarna), am folosit la actualizare funcția SIB(), sortarea prin inserție binară (am mai scris despre SIB, QS și INTERC). Știam de atunci că interclasarea are memorie în plus, chiar dacă este eficientă, și am fost reticent față de ea, am avut impresia că Quick Sort-ul nu este foarte bun, și că inserția binară are rapiditate (într-adevăr, făcea repede, numai că atunci, în special în 2010, și cantitățile de numere erau cu mult sub cele de astăzi).
SIB() nu are complexitate n*n, are ceva de tipul n cu log(n), fiind cu parte binară (log(n) înseamnă logaritm în baza 2 din n, nu Euler).
Există și sortare prin inserție directă, dar mai lentă (inserția, selecția și bulele sunt metode de sortare din clasa de jos, n*n, merg bine pe numere puține, dar pe multe (și mari) ar fi lente.
Deci așa arată cronologia funcțiilor de sortare crescătoare pentru actualizarea depozitului numeric (și, până în ianuarie 2014, și pentru căutări sortam): SIB(), QS(), INTERC(), HS().
La 27 septembrie 2014 a fost desființată denumirea de GILIPOLLAN folosită pentru folder-ul de lucru numeric încă din toamna 2008/2009. Avea origine îndepărtată spaniolă, la GILIPOLLAS. A fost denumirea permanentă a dosarului cu fișiere numerice în acești ani, inclusiv din toamna anului 2012, când, trecând la Linux, am fixat punctul de pornire (rădăcină) al fișierelor în / (root), în afara lui GILIPOLLAN.
GILIPOLLAN a fost dosarul special pentru numere, în care au fost conținute fișierele de luptă numerică: făcut în octombrie (?) 2008, din noiembrie 2009 a fost casa asiduă a numerelor, sub Windows, și a rămas ca spațiu de mișcare numerică după 30 septembrie 2012, când am găsit beneficiul de viteză al GMP-ului.
În iulie 2011 când am primit noul calculator, cu procesor mai bogat, am făcut în GILIPOLLAN sub-folderele 1 (?), 2, 3 și 4 pentru ca fiecare thread să-și aibă într-un loc programul numeric care să ruleze pe el. În 1 există și T, directorul cu programul care face fișiere goale, și mi se pare că din primăvara 2011 (când am făcut prima dată acel program) până în vară T a fost singurul sub-folder în GILIPOLLAN, apoi au apărut 1 (care l-a luat pe T), 2, 3 și 4. Din toamna 2012 când am ieșit din GILIPOLLAN, s-a adăugat / ca zonă de rulare.
Așadar: /, /GILIPOLLAN, /GILIPOLLAN/1, /GILIPOLLAN/1/T, /GILIPOLLAN/2, /GILIPOLLAN/3, /GILIPOLLAN/4. De asemenea copii de GILIPOLLAN pe cele 2 hard disk-uri mai mari, tocmai pentru a fi multe locuri în care să pot face fișiere de rezultate când căutarea e mai lungă și mai mult de 7 anumite sub-căutări se termină. Fiecare fișier trebuie făcut și scris într-o singură căutare, fără refolosire înaintea actualizării GIG.TXT, apoi conținutul lor dispare.
Numele nou al folderului pentru numere este: NUMERIC.
Pentru conflictul de nume cu executabilul NUMERIC, de la NUMERIC.cc, ele au devenit NUMERICUL și NUMERICUL.cc, pe rădăcină (prezente așa și în NUMERICUL.sh din /).
Numele fișierelor de rezultate la căutările numerice sunt:
SUS.TXT, JOS.TXT, eventual SUS1/JOS1 (am mai scris despre numele lor). La FACTORSUBuri FSB.TXT, iar la RAPIDNUM RAP.TXT.
Fișierul REM.cc este programat să șteargă toate fișierele de căutare de tipul SUS, JOS, FSB, RAP de pe cele trei hard disk-uri (cele diferite de cel de sistem se numesc /media/root/1TB - 1 TB - și /media/root/2TB, celălalt).
(va urma)
Comentarii
Trimiteți un comentariu