Alte povești cu numerele din toamna lui 2014
La 29 septembrie 2014 dimensiunea lui GIG.TXT a trecut de 1 TB, după o extindere a plajei de coeficienți de fracționare abundențială, de la maxim 200000 la maxim 500000, în urma unui incident numeric de pe 27 septembrie, când am introdus greșit niște rezultate în GIG.TXT și am pierdut altele.
Am schimbat pe 28 septembrie zona de actualizare a GIG.TXT: a rămas numai funcția ACTUAL(), fără ACTUALM(), în care acum sunt 3 variante de abordare la actualizare:
-MIC(), când trebuie făcut în totalitate un nou GIG.TXT pornind de jos, corespunzând cu vechea variantă ACTUAL();
-MIC2(), situație adaptată la nevoia curentă, unde GIG.TXT poate fi cuprins numai pe hard disk-ul de 2 TB, până voi cumpăra încă unul, poate chiar peste 2 TB (+ un adaptor PCI de SATA-3): pe discul de 2 TB se face partea de jos a noului GIG.TXT, de pildă până la 10^100, iar partea de deasupra (neactualizată) a vechiului GIG.TXT trebuie scrisă pe cel de 1 TB, să fie loc. Apoi vechiul GIG.TXT de pe cel de 2 TB trebuie șters, iar părții de jos actualizate i se adaugă, pe discul de 2 TB, partea de sus de pe celălalt hard disk, astfel rezultând noul GIG.TXT pe cuprinzătorul disc de 2 TB. Partea de pe cel de 1 TB trebuie și aceasta ștearsă;
-MARE(), care corespunde cu vechiul ACTUALM(), actualizarea unui segment mai de sus din GIG.TXT, eventual cuprinzând și sfârșitul fișierului.
Partea de umplere propriu-zisă a zonei de actualizare, care deosebește noul GIG.TXT de ce era cel vechi, a fost de asemenea cuprinsă într-o unică funcție pentru toate cele 3 cazuri de mai sus, cărora le rămân segmente mai mici de cod, specifice: UMPLERE().
Am scos din zona de umplere cazul separat pentru un singur pas de actualizare, valabil pentru vremea veche când depozitul numeric putea fi actualizat dintr-o singură etapă. La actualizarea pe mai mulți pași poate fi pus și unul singur, iar în vectorul VEC, unde sunt puse puterile de 10 ce reprezintă pașii, pot fi astfel trecute doar valoarea mai de jos (a1) și cea mai de sus (b1). În practică însă, aproape mereu este nevoie de mai mulți.
Din INTERC.h am scos, tot atunci, funcțiile de sortare prin interclasare, și a rămas cea de Heap Sort (HS).
Astfel, însuși numele headerului și-a pierdut sensul de început (i l-am dat când am pus interclasarea ca funcție de header pentru sortarea numerelor în depozit). INTERC.h a devenit ACTUAL.h.
Segmentele vechi de cod din fostul INTERC au ajuns în GUNOI.TXT.
De asemenea am scos din circuit (ștergere cu sau fără depozitare în folderul VECHI) fișiere devenite inutile precum SONDABUND.cc, VECUNG3.cc (legate de sistemul cu fracționări de abundențe în vector, de până la descoperirea din 22 mai 2014) - au fost depozitate în acel folder - și cele câteva fișiere de tip VT.TXT (VTM, VTR, VT) unde erau trecute fracționările, ele șterse de tot. Desuetudine de tehnică.
În plus, am șters fișierul TOL.c (o variantă veche de TOL pe MPIR, fără 64 de biți, când se căutau numere unele din altele prin înmulțire cu coeficienți mulți de legătură, puși odată în vector).
Mai demult, până în 2013, aveam fișiere mari (unul în special, care a avut chiar peste 11 miliarde de octeți, semnificativ mai mult decât RZ.TXT de la acea vreme) unde erau milioane de coeficienți de legătură de foarte diverse mărimi, mulți nefolosiți de fapt în practică. VCL.TXT (?) era cel gigantic, cu coeficienți peste 32 (chiar 64) de biți, iar VECL.TXT cel cu coeficienți mai mici, și mult mai mic în mărime. Au fost șterși până acum.
Erau obținuți prin funcții de tip VC(), care treceau prin numerele din RZ.TXT puse în vector, împărțindu-le pe cele mai mari la cele mai mici și câturile deveneau coeficienți de legătură. Trebuia răbdare, fiecare coeficient trebuia pus o singură dată (verificare secvențială a deja-prezenței), trebuiau sortați crescător în fișierul de depozit (VECL sau VCL). Unii au ajuns pe la 300 de cifre. Erau și mulți coeficienți pari. Cei mai mici erau, firește, 2 și 3.
Astăzi știu că aceia primi impari și mici (de pildă sub 500) sunt cei mai productivi coeficienți de legătură, iar cei compuși, tot impari și de exemplu sub 100 sau 1000 (MODIFSUM-urile) aduc mai puține rezultate, cei pari și mici (mai ales 2 și puterile lui) neaducând chiar nimic, decât în cazul eventual și orientativ al numerelor mici, ca de <=20 de cifre (în practică aproape deloc folosite la căutare), dar chiar și la ele tot imparii primi aduc mai mult, și chiar mai mult de atât, coeficienții mici primi impari aduc (în general pentru numere) cele mai multe rezultate când numerele de bază nu sunt deja divizibile cu ei (noutăți de divizori primi), dacă e căutare cu înmulțire, sau dacă se împart o singură dată cu ei, la împărțire (NUMSIMPL).
Apoi MODSPRIM folosește primii impari când numărul de bază este deja divizibil cel puțin o dată (la înmulțire) sau cel puțin cu pătratul (la împărțire), dar se vede că vin mai puține numere.
Și oricum numerele prime mai mari (ca 2801 sau altele de ordinul sutelor mai multe, miilor sau mai mult) aduc mai puțin decât numerele prime mici. Și la înmulțire, și la împărțire rezultatele pot fi foarte bogate când NUMSIMPL lucrează cu numere prime mici (totuși în rangul orientativ 20-100 în special la înmulțire, fiind puține numerele care să nu se împartă deloc, sau doar o dată, cu primele sub 20, care sunt foarte folosite).
În oricare situație, NUMSIMPL este susceptibil de a fi mai productiv decât MODSPRIM și celelalte în acea situație. Iar coeficienții pari (sau chiar 2 și puterile lui nenule) sunt cei mai neindicați. 1 este elementul neutru și din oficiu nu se ia în seamă (nici nu-i prim ori compus).
Mai există sistemul de căutare de tip FACTORSUB/VECUNSUB + JEDENASCIE, care lucrează direct cu substituții în lanțurile de numere prime la puteri, care compun numerele. Mi se pare că așa au lucrat cei care au găsit multiperfectele și semiperfectele, puncte de bază de plecare pentru mine în cercetarea numerică.
Pe pagina lui Achim Flammenkamp de la universitatea germană Bielefeld se vede o referință la „sigma-chain database”, la lucrul cu numere prime folosite în căutarea de multiperfecte: versiunea 4.1d, dar nu am studiat mper-4.1.d îndeajuns de profund, încă.
Și, cu înmulțire/împărțire precum celelalte, RAPIDNUM, care aduce direct numerele fără filtrarea abundențelor, dar acolo trebuie să fiu atent să nu aducă rezultate prea multe și noi care cer foarte mult timp la actualizare.
Fondul I are oficial tot 22758 de numere, de luni în șir, dar poate GIG.TXT (va) mai conține astfel de numere pe care nu le-am demonstrat încă.
Acum GIG.TXT nu poate sta în alt disc decât cel de 2 TB. Am trecut la Ubuntu 14.10, care vine la pachet cu GCC 4.9.1. În vizor: 4.9.2 și 5.
La 26 octombrie 2014 a fost completată o nouă reformă a zonei de actualizare a puterilor coeficienților primi din factorizările numerelor (adică TOLIL + MAXPUT + TOL1 + TOL2 + TOL3), însă fără eliminarea urmelor vechii variante, pentru o mai rapidă culegere a puterilor maxime noi, și cu posibilitatea folosirii simplificate a tranșelor succesive de numere, după numărul de cifre, cu intervale micșorate de puteri de 10, din marele fond numeric aflat în fișierul GIG.TXT (de exemplu numerele de la 1500 la 1910 cifre, apoi de la 1100 la 1500, de la 1000 la 1100 și tot așa), fără nevoia de dinainte de a renumi repetat fișierele generate (CF, PUTERI, VC).
La 1 decembrie 2014 fondul I numeric avea 22777 de numere, iar fondul II trecea de 16825000000 de numere. GIG.TXT are peste 1611000000000 de octeți, iar de la 2 noiembrie 2014 povestea cu numerele se află, de regulă, într-o nouă întrerupere.
Poate la sesiunea a treia de lucru nu voi mai folosi fondul II, ci generarea directă a numerelor de fond I pe baza puterilor aleatorii ale numerelor prime (sigma-chain), cum a făcut Achim Flammenkamp, dar trebuie să vreau să studiez.
Am schimbat pe 28 septembrie zona de actualizare a GIG.TXT: a rămas numai funcția ACTUAL(), fără ACTUALM(), în care acum sunt 3 variante de abordare la actualizare:
-MIC(), când trebuie făcut în totalitate un nou GIG.TXT pornind de jos, corespunzând cu vechea variantă ACTUAL();
-MIC2(), situație adaptată la nevoia curentă, unde GIG.TXT poate fi cuprins numai pe hard disk-ul de 2 TB, până voi cumpăra încă unul, poate chiar peste 2 TB (+ un adaptor PCI de SATA-3): pe discul de 2 TB se face partea de jos a noului GIG.TXT, de pildă până la 10^100, iar partea de deasupra (neactualizată) a vechiului GIG.TXT trebuie scrisă pe cel de 1 TB, să fie loc. Apoi vechiul GIG.TXT de pe cel de 2 TB trebuie șters, iar părții de jos actualizate i se adaugă, pe discul de 2 TB, partea de sus de pe celălalt hard disk, astfel rezultând noul GIG.TXT pe cuprinzătorul disc de 2 TB. Partea de pe cel de 1 TB trebuie și aceasta ștearsă;
-MARE(), care corespunde cu vechiul ACTUALM(), actualizarea unui segment mai de sus din GIG.TXT, eventual cuprinzând și sfârșitul fișierului.
Partea de umplere propriu-zisă a zonei de actualizare, care deosebește noul GIG.TXT de ce era cel vechi, a fost de asemenea cuprinsă într-o unică funcție pentru toate cele 3 cazuri de mai sus, cărora le rămân segmente mai mici de cod, specifice: UMPLERE().
Am scos din zona de umplere cazul separat pentru un singur pas de actualizare, valabil pentru vremea veche când depozitul numeric putea fi actualizat dintr-o singură etapă. La actualizarea pe mai mulți pași poate fi pus și unul singur, iar în vectorul VEC, unde sunt puse puterile de 10 ce reprezintă pașii, pot fi astfel trecute doar valoarea mai de jos (a1) și cea mai de sus (b1). În practică însă, aproape mereu este nevoie de mai mulți.
Din INTERC.h am scos, tot atunci, funcțiile de sortare prin interclasare, și a rămas cea de Heap Sort (HS).
Astfel, însuși numele headerului și-a pierdut sensul de început (i l-am dat când am pus interclasarea ca funcție de header pentru sortarea numerelor în depozit). INTERC.h a devenit ACTUAL.h.
Segmentele vechi de cod din fostul INTERC au ajuns în GUNOI.TXT.
De asemenea am scos din circuit (ștergere cu sau fără depozitare în folderul VECHI) fișiere devenite inutile precum SONDABUND.cc, VECUNG3.cc (legate de sistemul cu fracționări de abundențe în vector, de până la descoperirea din 22 mai 2014) - au fost depozitate în acel folder - și cele câteva fișiere de tip VT.TXT (VTM, VTR, VT) unde erau trecute fracționările, ele șterse de tot. Desuetudine de tehnică.
În plus, am șters fișierul TOL.c (o variantă veche de TOL pe MPIR, fără 64 de biți, când se căutau numere unele din altele prin înmulțire cu coeficienți mulți de legătură, puși odată în vector).
Mai demult, până în 2013, aveam fișiere mari (unul în special, care a avut chiar peste 11 miliarde de octeți, semnificativ mai mult decât RZ.TXT de la acea vreme) unde erau milioane de coeficienți de legătură de foarte diverse mărimi, mulți nefolosiți de fapt în practică. VCL.TXT (?) era cel gigantic, cu coeficienți peste 32 (chiar 64) de biți, iar VECL.TXT cel cu coeficienți mai mici, și mult mai mic în mărime. Au fost șterși până acum.
Erau obținuți prin funcții de tip VC(), care treceau prin numerele din RZ.TXT puse în vector, împărțindu-le pe cele mai mari la cele mai mici și câturile deveneau coeficienți de legătură. Trebuia răbdare, fiecare coeficient trebuia pus o singură dată (verificare secvențială a deja-prezenței), trebuiau sortați crescător în fișierul de depozit (VECL sau VCL). Unii au ajuns pe la 300 de cifre. Erau și mulți coeficienți pari. Cei mai mici erau, firește, 2 și 3.
Astăzi știu că aceia primi impari și mici (de pildă sub 500) sunt cei mai productivi coeficienți de legătură, iar cei compuși, tot impari și de exemplu sub 100 sau 1000 (MODIFSUM-urile) aduc mai puține rezultate, cei pari și mici (mai ales 2 și puterile lui) neaducând chiar nimic, decât în cazul eventual și orientativ al numerelor mici, ca de <=20 de cifre (în practică aproape deloc folosite la căutare), dar chiar și la ele tot imparii primi aduc mai mult, și chiar mai mult de atât, coeficienții mici primi impari aduc (în general pentru numere) cele mai multe rezultate când numerele de bază nu sunt deja divizibile cu ei (noutăți de divizori primi), dacă e căutare cu înmulțire, sau dacă se împart o singură dată cu ei, la împărțire (NUMSIMPL).
Apoi MODSPRIM folosește primii impari când numărul de bază este deja divizibil cel puțin o dată (la înmulțire) sau cel puțin cu pătratul (la împărțire), dar se vede că vin mai puține numere.
Și oricum numerele prime mai mari (ca 2801 sau altele de ordinul sutelor mai multe, miilor sau mai mult) aduc mai puțin decât numerele prime mici. Și la înmulțire, și la împărțire rezultatele pot fi foarte bogate când NUMSIMPL lucrează cu numere prime mici (totuși în rangul orientativ 20-100 în special la înmulțire, fiind puține numerele care să nu se împartă deloc, sau doar o dată, cu primele sub 20, care sunt foarte folosite).
În oricare situație, NUMSIMPL este susceptibil de a fi mai productiv decât MODSPRIM și celelalte în acea situație. Iar coeficienții pari (sau chiar 2 și puterile lui nenule) sunt cei mai neindicați. 1 este elementul neutru și din oficiu nu se ia în seamă (nici nu-i prim ori compus).
Mai există sistemul de căutare de tip FACTORSUB/VECUNSUB + JEDENASCIE, care lucrează direct cu substituții în lanțurile de numere prime la puteri, care compun numerele. Mi se pare că așa au lucrat cei care au găsit multiperfectele și semiperfectele, puncte de bază de plecare pentru mine în cercetarea numerică.
Pe pagina lui Achim Flammenkamp de la universitatea germană Bielefeld se vede o referință la „sigma-chain database”, la lucrul cu numere prime folosite în căutarea de multiperfecte: versiunea 4.1d, dar nu am studiat mper-4.1.d îndeajuns de profund, încă.
Și, cu înmulțire/împărțire precum celelalte, RAPIDNUM, care aduce direct numerele fără filtrarea abundențelor, dar acolo trebuie să fiu atent să nu aducă rezultate prea multe și noi care cer foarte mult timp la actualizare.
Fondul I are oficial tot 22758 de numere, de luni în șir, dar poate GIG.TXT (va) mai conține astfel de numere pe care nu le-am demonstrat încă.
Acum GIG.TXT nu poate sta în alt disc decât cel de 2 TB. Am trecut la Ubuntu 14.10, care vine la pachet cu GCC 4.9.1. În vizor: 4.9.2 și 5.
La 26 octombrie 2014 a fost completată o nouă reformă a zonei de actualizare a puterilor coeficienților primi din factorizările numerelor (adică TOLIL + MAXPUT + TOL1 + TOL2 + TOL3), însă fără eliminarea urmelor vechii variante, pentru o mai rapidă culegere a puterilor maxime noi, și cu posibilitatea folosirii simplificate a tranșelor succesive de numere, după numărul de cifre, cu intervale micșorate de puteri de 10, din marele fond numeric aflat în fișierul GIG.TXT (de exemplu numerele de la 1500 la 1910 cifre, apoi de la 1100 la 1500, de la 1000 la 1100 și tot așa), fără nevoia de dinainte de a renumi repetat fișierele generate (CF, PUTERI, VC).
La 1 decembrie 2014 fondul I numeric avea 22777 de numere, iar fondul II trecea de 16825000000 de numere. GIG.TXT are peste 1611000000000 de octeți, iar de la 2 noiembrie 2014 povestea cu numerele se află, de regulă, într-o nouă întrerupere.
Poate la sesiunea a treia de lucru nu voi mai folosi fondul II, ci generarea directă a numerelor de fond I pe baza puterilor aleatorii ale numerelor prime (sigma-chain), cum a făcut Achim Flammenkamp, dar trebuie să vreau să studiez.
Comentarii
Trimiteți un comentariu