Progresul hardware, episodul 48: Alte propuneri de „hard” și de aranjat numerele (Joi, 29 martie 2018)
Astăzi doresc să iau de la Electronic Lion un cablu DVI, poate o să pun cooler-ul Arctic Liquid Freezer la SLI PLUS tot azi. Mai pot cumpăra, până în iunie, câteva componente EKWB ca să încropesc un cooler cu trei Vardare FF3-120 de 1850 de RPM, rezervor EK-RES 150 nou, pompă Elite și waterblock de EK-X360, tubăraie este deja acasă, lichid Premix sau concentrat am și mai pot lua de la ei, apă distilată e-n casă, plus vechiul radiator triplu al Aorusului - această ecavebea pentru procesorul i9-7900X de pe placa ASUS PRIME, la a cărei carcasă pot pune celelalte trei Vardare de 1850 RPM din cele șase care sunt acum acasă.
Și, desigur, pentru fiecare montare nouă de cooler la jumătatea de jos a tetradei, Conductonaut pe procesor.
Mâine ar trebui să-mi mai vină trei Furious Vardare de 3000 de RPM pentru radiatorul EKWB triplu de la 7980XE-ul Xpower Gaming-ului, așa șase ventilatoare EKWB de 1850 de RPM și tot 120 de milimetri vor deveni rezervă pentru placa ASUS.
Așa, cele două coolere Corsair, H100i și H115i, vor fi rezervă în casă amândouă, poate de la sfârșitul lunii mai ori din iunie, căci mai vreau progres hardware și până la vară.
Îmi doresc din suflet, acum, progresul hardware expus mai sus, plus reușită în alte privințe gândite.
Următoarea mea comandă de la EKWB, așadar, ar trebui să fie:
-minim șase șuruburi de Fitting (Barb + Ring), ca toamna trecută;
-un rezervor EK-RES 150 și o pompă DC ELITE;
-o sticlă de 900 de ml de CryoFuel Premix sau măcar una mică de 100 ml concentrați, cu apă distilată deja în debara acasă;
-un tub de 2 m de grosimea potrivită e deja în casă, de rezervă, pentru siguranță mai pot lua atunci unul.
Cu plăcile video și memoria, mă mai pot descurca în formatul actual - Veritonul poate să meargă cu placa video integrată, SLI PLUS-ul cu GDDR3-ul care era la Veriton, ASUS PRIME-ul cu NVIDIA GDDR5-ul dual slot de 4 GB luat vara trecută, iar jumătatea de sus a tetradei are demult cu ce. Și cei 64 de GB de DDR4-3000 să fie împărțiți egal între SLI PLUS și ASUS PRIME. Mi-ar mai trebui măcar o tastatură, un mouse și un stick USB wireless TP-LINK Archer T4U între timp.
Prin vară, poate totuși mai iau 32 de GB de DDR4, poate chiar tot de 4000 MHz, un monitor nou cu Display Port și placa video Zotac de care mai ziceam, plus încă o tastatură, un mouse și al treilea stick wireless Archer. Cu toate aceste progrese hardware, dar fără a închide nici chiar atunci, vara, viitorul pentru alte progrese, tetrada ar fi de-a dreptul funcțională, chiar mai înainte de a se împlini un an pe calendar de la 4-5-6 august 2017.
La jumătatea de jos a tetradei, deja m-am gândit cum se pot căuta numere noi într-o manieră care să nu repete ori alungească fronturile 1 și 2 - numerele de fond 1 din N.TXT / N3.TXT pot fi luate în VECUNSUB ori mai degrabă în VECUN, cu mari vectori de coeficienți de legătură, ca în VEC.TXT sau COEFLEG.TXT, dar pentru fiecare număr găsit astfel prin înmulțire sau împărțire, să se mai parcurgă o dată lista de coeficienți, pentru alte și alte numere noi - o căutare recursivă cu liste de coeficienți de legătură (*, /) între numere.
La urma urmei, bulgării numerici din primele două fronturi tot așa s-au făcut, cu numere din numere și numere din numere din numere, dar acolo - depozitate în fișiere; noua metodă nu urmărește facerea de mari fișiere, discurile prevăzute pentru jumătatea de jos în vara anului 2018 oferind, de altfel, un spațiu atât de mic (240 GB, 500 GB), plus dorința de a nu reproduce metodele marilor fronturi; dar poate așa vor răsări niște numere noi de fond 1 pe care nu le aduc celelalte fronturi. Pentru aceasta, și coeficienții de legătură trebuiesc adunați în număr mai mare la COEFLEG, mai diversificați. VEC.TXT îi adună doar pe baza legăturilor dintre numerele de fond 1, existente și luate în calcul la o rulare de VECUN, dar la COEFLEG vin coeficienți valabili pentru numere care nu sunt numai de fond 1, cum pot să fac generare aleatorie de produse de puteri de factori primi (chiar și numere pare), cu ajutorul RandomLib-ului cu care lucrează COEFLEG și FACTORSUBM-urile.
Să zicem că luăm 500 de numere de fond 1 cu VECUN și le dăm 400 de coeficienți de legătură, între 1000 și 10000, cu înmulțire, dar pentru fiecare număr găsit așa mai dăm alți 100 sau 200 de coeficienți (pot fi și la întâmplare, precum și ficși între 10000 și 15000, cu împărțire). Sau invers, cu împărțire și apoi înmulțire cu alții, și numerele găsite la (prima și) a doua operație, dacă sunt de fond 1, să fie luate în seamă. S-ar putea recursa mai mult decât atât, dar deja se complică cumplit roata numerică. Și cu numere de fond 2 s-ar putea; acolo, și mai și.
Dar cum să fac așa, algoritmic? Este clar că o ipoteză este o variantă modificată de VECUN, cu pornire de la un eșantion numeric micșorat pentru fiecare thread implicat (mai cu seamă în jumătatea de jos, unde nu-i spațiu de mari fișiere). De pildă se încarcă întâi vectorul A (de coeficienți) cu 300 de factori de legătură între 5000 și 50000, cu înmulțire, iar fiecare număr găsit (nu neapărat de fond 1 ori 2, deși se poate filtra abundențial) este împărțit pe rând la alți 300 de factori diferiți de primii 300 (că altfel ne întoarcem la numerele de plecare), din alt vector de coeficienți, să zicem A1, ca să nu se corupă A. Dacă se parcurg 1000 de numere din N3.TXT, se generează în total 300000 de numere cu treapta 1 (înmulțire), din care la rândul lor se mai scot câte alte X1, X2, X3 numere prin împărțirea din etajul 2 de căutare, nu tot câte 300, că împărțirea la ceilalți 300 de coeficienți nu garantează fix 300 de rezultate, trebuie să fie fără rest. Să presupunem o medie de 80 de împărțiri reușite, în total cu 1000*300*300 s-ar ajunge la 24 de milioane de numere prin care se trece, ele se verifică cu VALID() dacă sunt de fond 1.
Sau: 1500 de numere din N3.TXT, 400 de coeficienți (6000-30000) cu împărțire, rată medie de 70 de împărțiri exacte pe număr, apoi 500 de coeficienți (100-6000) de înmulțire, ar însemna în total 14 milioane de numere care trec prin VALID() să le verifice.
De fapt, chestia asta seamănă mult a MODIFSUM, mai cu seamă unde sunt coeficienți relativ mici de înmulțire/împărțire, de altfel să nu uităm că MODIFSUM lucrează cu factori neprimi de legătură din COEFLEG.TXT, iar VECUN reface din principiu toată suma divizorilor unui număr nou-găsit cu coeficienții de înmulțire/împărțire generați în VEC.TXT la rulare, acei coeficienți fiind mult mai mulți și mult mai mari decât ce folosește MODIFSUM din COEFLEG, așa încât nu mai este considerat eficient să se modifice pe ici-pe colo suma numărului de plecare după cum este coeficientul ce duce spre nou-găsitul număr, ci numărului aceluia să i se facă din start toată suma.
Dacă este vorba despre rânduri de câteva sute de coeficienți până-n 10000 sau câteva zeci de mii (mărimea lor), mai e cum mai e cu modificarea lui MODIFSUM, oricum un număr foarte mare de coeficienți în cele două trepte complică foarte mult lucrul (de pildă, 500 de numere din N3.TXT * 30000 de coeficienți cu înmulțire * alți 25000 cu împărțire, eventual cu mărimi până la 5000000, poate ar fi abordabile cu MODIFSUM, dar la o rată medie de 150 de împărțiri exacte am avea 500*30000*150 = 2250000000 de numere de dat la VALID(), adică două miliarde și un sfert, eventual toată povestea asta mărunțită între mai multe threaduri de procesor, dar la 7740X cu opt threaduri, tot ar avea fiecare ramură de program de luat o medie de 281250000 de numere).
Coeficienții giganți din VEC.TXT pot ajunge la 30 sau 40 de cifre, acolo ar fi tare multe modificări de făcut sumei unui număr nou față de cea a numărului de bază, în plus la MODIFSUM se știe că se lucrează cu coeficienți întregi obișnuiți, pe când dincolo s-ar ști că sunt mepezetele înșiși coeficienții, și s-ar îngreuna calculul cu ei, deși se poate încerca MODIFSUM și așa.
De asemenea, dacă se folosesc în aceste căutări recursive și numere de fond 2 din frontul 1 sau 2 numeric, nu se permit prea multe numere de plecare (de bază), știindu-se că acolo în depozite se numără cu miliardele, și oricum dacă din depozitul numeric se aleg 10000 sau mai multe numere de parcurs, pentru un timp rezonabil de calcul recursiv cu coeficienți pe mai multe fire de procesor numerele de coeficienți alese pe trepte trebuie ajustat (micșorat) după merit, precum 12500 de numere de bază * 250 de coeficienți de treapta 1 (înmulțire, să zicem, și mai mici decât 5000) * alți 400 de coeficienți de împărțire cu o medie de 50 de împărțiri reușite, ei între 5000 și 25000, toți tratabili cu MODIFSUM; ar fi 12500*250*50, adică 156250000 de numere la VALID().
Sau 50000 de numere de bază * 200 de coeficienți de împărțire (intervalul 500-5000) cu media de 30 de reușite * 250 de înmulțire cu intervalul 5000-25000, total 50000*30*250 = 375 de milioane de numere la VALID(), eventual muncă împărțită pe mai multe threaduri. Aici se poate face MODIFSUM.
Oricum, pentru fronturile 1 și 2, mă gândesc ca la o suficientă (?) acumulare de numere de fond 2 să caut, cu NUMSIMPL, MODPRIM, MODIFSUM sau chiar cu SUMRED / NUMERICUL, exclusiv numere de fond 1 folosind un număr mic, nedeterminat, de numere de plecare din depozitele numerice și fiecăruia să-i dau un singur etaj de coeficienți de legătură (nu recursivitate de trepte) de înmulțire sau împărțire, adică sus/jos, dar coeficienții din COEFLEG, eventual din vreun fișier VEC, să fie foarte mulți, mii și mii, eventual 50000 sau suta de mii și să se parcurgă abia niște mii de numere din depozitul numeric, când în depozitele acelea, cum am mai zis, se numără chiar cu miliardele, îndeosebi pe frontul 1 numeric.
În practica de acum, NUMERICUL poate fi pregătit pentru un vector de coeficienți atât de mare, sau să pun un VECUN să-i folosească pe un depozit mare în loc de N3.TXT, dar la NUMSIMPL, MODPRIM și MODIFSUM vectorii dați de mine sunt mai mici, în plus la primele două programe sunt exclusiv primi (în VEC și mai ales COEFLEG sunt neprimi), la MODIFSUM pot să măresc paleta de coeficienți luabili din COEFLEG, dar între timp trebuie să mai îmbogățesc COEFLEG-ul. NUMERICUL s-ar baza și el pe COEFLEG. Dar pot să le dau și din VEC, desigur, cu măsură a numărului și mărimii, mai ales la MODIFSUM ca să nu ia coeficienți prea mari. NUMERICUL face sumele noilor numere în întregime, nu prin modificări asupra vreunei sume de plecare (stilul MODIFSUM), ca și SUMRED de altfel, și lor le pot da coeficienți mai mari de legătură, înmulțire/împărțire într-o treaptă.
Dar pentru două sau chiar mai multe trepte de coeficienți pentru obținerea de numere noi de fond 1 (nu se scriu mari depozite numerice), este clar că trebuie să mai fac și niște variante modificate pentru VECUN și MODIFSUM. Poate că pot și pentru SUMRED, NUMSIMPL și MODPRIM, dar ultimele două se bazează exclusiv pe numere prime, adică mai puține decât cele neprime (avantaj că pot să treacă prin mai multe mii de numere de bază, chiar și de prima treaptă, coeficienții de legătură fiindu-le mai puțini).
Unde sunt mai multe șarje de coeficienți de legătură la recursivitate, numerele de bază și de treaptă trebuiesc date potrivit de multe sau puține, ca produsul lor total de lucru să nu însemne miliarde de numere de verificat care să ceară foarte mult timp pe sesiunea de lucru, deși se poate și așa cu scrierea continuată a rezultatelor de fond 1 într-un fișier, cărui fișier să-i dau periodic vecung2 ca să văd dacă-i rost de noutăți la fondul 1. Tot așa (vecung2) aș putea face și la căutările unitreaptă de numere de fond 1 pe fronturile 1 și 2, căutări făcute pe baza marilor depozite. Dar la toate aceste noutăți de căutare numerică, pe oricare front numeric, ar fi bine chiar să vină numere noi, spre deosebire de situația de la VECUNSUB, care este o variantă de FACTORSUBM pe N3.TXT, însă care nu mi-a adus mai mult de câteva numere noi de fond 1 numărabile pe degete, iar asta hăt în 2014, adică pe vremea altei situări numerice, chit că și 2014 a fost un an de progres algoritmic și numeric (chiar și hardware, cu primul hard disk de 2 TB).
Și, desigur, pentru fiecare montare nouă de cooler la jumătatea de jos a tetradei, Conductonaut pe procesor.
Mâine ar trebui să-mi mai vină trei Furious Vardare de 3000 de RPM pentru radiatorul EKWB triplu de la 7980XE-ul Xpower Gaming-ului, așa șase ventilatoare EKWB de 1850 de RPM și tot 120 de milimetri vor deveni rezervă pentru placa ASUS.
Așa, cele două coolere Corsair, H100i și H115i, vor fi rezervă în casă amândouă, poate de la sfârșitul lunii mai ori din iunie, căci mai vreau progres hardware și până la vară.
Îmi doresc din suflet, acum, progresul hardware expus mai sus, plus reușită în alte privințe gândite.
Următoarea mea comandă de la EKWB, așadar, ar trebui să fie:
-minim șase șuruburi de Fitting (Barb + Ring), ca toamna trecută;
-un rezervor EK-RES 150 și o pompă DC ELITE;
-o sticlă de 900 de ml de CryoFuel Premix sau măcar una mică de 100 ml concentrați, cu apă distilată deja în debara acasă;
-un tub de 2 m de grosimea potrivită e deja în casă, de rezervă, pentru siguranță mai pot lua atunci unul.
Cu plăcile video și memoria, mă mai pot descurca în formatul actual - Veritonul poate să meargă cu placa video integrată, SLI PLUS-ul cu GDDR3-ul care era la Veriton, ASUS PRIME-ul cu NVIDIA GDDR5-ul dual slot de 4 GB luat vara trecută, iar jumătatea de sus a tetradei are demult cu ce. Și cei 64 de GB de DDR4-3000 să fie împărțiți egal între SLI PLUS și ASUS PRIME. Mi-ar mai trebui măcar o tastatură, un mouse și un stick USB wireless TP-LINK Archer T4U între timp.
Prin vară, poate totuși mai iau 32 de GB de DDR4, poate chiar tot de 4000 MHz, un monitor nou cu Display Port și placa video Zotac de care mai ziceam, plus încă o tastatură, un mouse și al treilea stick wireless Archer. Cu toate aceste progrese hardware, dar fără a închide nici chiar atunci, vara, viitorul pentru alte progrese, tetrada ar fi de-a dreptul funcțională, chiar mai înainte de a se împlini un an pe calendar de la 4-5-6 august 2017.
La jumătatea de jos a tetradei, deja m-am gândit cum se pot căuta numere noi într-o manieră care să nu repete ori alungească fronturile 1 și 2 - numerele de fond 1 din N.TXT / N3.TXT pot fi luate în VECUNSUB ori mai degrabă în VECUN, cu mari vectori de coeficienți de legătură, ca în VEC.TXT sau COEFLEG.TXT, dar pentru fiecare număr găsit astfel prin înmulțire sau împărțire, să se mai parcurgă o dată lista de coeficienți, pentru alte și alte numere noi - o căutare recursivă cu liste de coeficienți de legătură (*, /) între numere.
La urma urmei, bulgării numerici din primele două fronturi tot așa s-au făcut, cu numere din numere și numere din numere din numere, dar acolo - depozitate în fișiere; noua metodă nu urmărește facerea de mari fișiere, discurile prevăzute pentru jumătatea de jos în vara anului 2018 oferind, de altfel, un spațiu atât de mic (240 GB, 500 GB), plus dorința de a nu reproduce metodele marilor fronturi; dar poate așa vor răsări niște numere noi de fond 1 pe care nu le aduc celelalte fronturi. Pentru aceasta, și coeficienții de legătură trebuiesc adunați în număr mai mare la COEFLEG, mai diversificați. VEC.TXT îi adună doar pe baza legăturilor dintre numerele de fond 1, existente și luate în calcul la o rulare de VECUN, dar la COEFLEG vin coeficienți valabili pentru numere care nu sunt numai de fond 1, cum pot să fac generare aleatorie de produse de puteri de factori primi (chiar și numere pare), cu ajutorul RandomLib-ului cu care lucrează COEFLEG și FACTORSUBM-urile.
Să zicem că luăm 500 de numere de fond 1 cu VECUN și le dăm 400 de coeficienți de legătură, între 1000 și 10000, cu înmulțire, dar pentru fiecare număr găsit așa mai dăm alți 100 sau 200 de coeficienți (pot fi și la întâmplare, precum și ficși între 10000 și 15000, cu împărțire). Sau invers, cu împărțire și apoi înmulțire cu alții, și numerele găsite la (prima și) a doua operație, dacă sunt de fond 1, să fie luate în seamă. S-ar putea recursa mai mult decât atât, dar deja se complică cumplit roata numerică. Și cu numere de fond 2 s-ar putea; acolo, și mai și.
Dar cum să fac așa, algoritmic? Este clar că o ipoteză este o variantă modificată de VECUN, cu pornire de la un eșantion numeric micșorat pentru fiecare thread implicat (mai cu seamă în jumătatea de jos, unde nu-i spațiu de mari fișiere). De pildă se încarcă întâi vectorul A (de coeficienți) cu 300 de factori de legătură între 5000 și 50000, cu înmulțire, iar fiecare număr găsit (nu neapărat de fond 1 ori 2, deși se poate filtra abundențial) este împărțit pe rând la alți 300 de factori diferiți de primii 300 (că altfel ne întoarcem la numerele de plecare), din alt vector de coeficienți, să zicem A1, ca să nu se corupă A. Dacă se parcurg 1000 de numere din N3.TXT, se generează în total 300000 de numere cu treapta 1 (înmulțire), din care la rândul lor se mai scot câte alte X1, X2, X3 numere prin împărțirea din etajul 2 de căutare, nu tot câte 300, că împărțirea la ceilalți 300 de coeficienți nu garantează fix 300 de rezultate, trebuie să fie fără rest. Să presupunem o medie de 80 de împărțiri reușite, în total cu 1000*300*300 s-ar ajunge la 24 de milioane de numere prin care se trece, ele se verifică cu VALID() dacă sunt de fond 1.
Sau: 1500 de numere din N3.TXT, 400 de coeficienți (6000-30000) cu împărțire, rată medie de 70 de împărțiri exacte pe număr, apoi 500 de coeficienți (100-6000) de înmulțire, ar însemna în total 14 milioane de numere care trec prin VALID() să le verifice.
De fapt, chestia asta seamănă mult a MODIFSUM, mai cu seamă unde sunt coeficienți relativ mici de înmulțire/împărțire, de altfel să nu uităm că MODIFSUM lucrează cu factori neprimi de legătură din COEFLEG.TXT, iar VECUN reface din principiu toată suma divizorilor unui număr nou-găsit cu coeficienții de înmulțire/împărțire generați în VEC.TXT la rulare, acei coeficienți fiind mult mai mulți și mult mai mari decât ce folosește MODIFSUM din COEFLEG, așa încât nu mai este considerat eficient să se modifice pe ici-pe colo suma numărului de plecare după cum este coeficientul ce duce spre nou-găsitul număr, ci numărului aceluia să i se facă din start toată suma.
Dacă este vorba despre rânduri de câteva sute de coeficienți până-n 10000 sau câteva zeci de mii (mărimea lor), mai e cum mai e cu modificarea lui MODIFSUM, oricum un număr foarte mare de coeficienți în cele două trepte complică foarte mult lucrul (de pildă, 500 de numere din N3.TXT * 30000 de coeficienți cu înmulțire * alți 25000 cu împărțire, eventual cu mărimi până la 5000000, poate ar fi abordabile cu MODIFSUM, dar la o rată medie de 150 de împărțiri exacte am avea 500*30000*150 = 2250000000 de numere de dat la VALID(), adică două miliarde și un sfert, eventual toată povestea asta mărunțită între mai multe threaduri de procesor, dar la 7740X cu opt threaduri, tot ar avea fiecare ramură de program de luat o medie de 281250000 de numere).
Coeficienții giganți din VEC.TXT pot ajunge la 30 sau 40 de cifre, acolo ar fi tare multe modificări de făcut sumei unui număr nou față de cea a numărului de bază, în plus la MODIFSUM se știe că se lucrează cu coeficienți întregi obișnuiți, pe când dincolo s-ar ști că sunt mepezetele înșiși coeficienții, și s-ar îngreuna calculul cu ei, deși se poate încerca MODIFSUM și așa.
De asemenea, dacă se folosesc în aceste căutări recursive și numere de fond 2 din frontul 1 sau 2 numeric, nu se permit prea multe numere de plecare (de bază), știindu-se că acolo în depozite se numără cu miliardele, și oricum dacă din depozitul numeric se aleg 10000 sau mai multe numere de parcurs, pentru un timp rezonabil de calcul recursiv cu coeficienți pe mai multe fire de procesor numerele de coeficienți alese pe trepte trebuie ajustat (micșorat) după merit, precum 12500 de numere de bază * 250 de coeficienți de treapta 1 (înmulțire, să zicem, și mai mici decât 5000) * alți 400 de coeficienți de împărțire cu o medie de 50 de împărțiri reușite, ei între 5000 și 25000, toți tratabili cu MODIFSUM; ar fi 12500*250*50, adică 156250000 de numere la VALID().
Sau 50000 de numere de bază * 200 de coeficienți de împărțire (intervalul 500-5000) cu media de 30 de reușite * 250 de înmulțire cu intervalul 5000-25000, total 50000*30*250 = 375 de milioane de numere la VALID(), eventual muncă împărțită pe mai multe threaduri. Aici se poate face MODIFSUM.
Oricum, pentru fronturile 1 și 2, mă gândesc ca la o suficientă (?) acumulare de numere de fond 2 să caut, cu NUMSIMPL, MODPRIM, MODIFSUM sau chiar cu SUMRED / NUMERICUL, exclusiv numere de fond 1 folosind un număr mic, nedeterminat, de numere de plecare din depozitele numerice și fiecăruia să-i dau un singur etaj de coeficienți de legătură (nu recursivitate de trepte) de înmulțire sau împărțire, adică sus/jos, dar coeficienții din COEFLEG, eventual din vreun fișier VEC, să fie foarte mulți, mii și mii, eventual 50000 sau suta de mii și să se parcurgă abia niște mii de numere din depozitul numeric, când în depozitele acelea, cum am mai zis, se numără chiar cu miliardele, îndeosebi pe frontul 1 numeric.
În practica de acum, NUMERICUL poate fi pregătit pentru un vector de coeficienți atât de mare, sau să pun un VECUN să-i folosească pe un depozit mare în loc de N3.TXT, dar la NUMSIMPL, MODPRIM și MODIFSUM vectorii dați de mine sunt mai mici, în plus la primele două programe sunt exclusiv primi (în VEC și mai ales COEFLEG sunt neprimi), la MODIFSUM pot să măresc paleta de coeficienți luabili din COEFLEG, dar între timp trebuie să mai îmbogățesc COEFLEG-ul. NUMERICUL s-ar baza și el pe COEFLEG. Dar pot să le dau și din VEC, desigur, cu măsură a numărului și mărimii, mai ales la MODIFSUM ca să nu ia coeficienți prea mari. NUMERICUL face sumele noilor numere în întregime, nu prin modificări asupra vreunei sume de plecare (stilul MODIFSUM), ca și SUMRED de altfel, și lor le pot da coeficienți mai mari de legătură, înmulțire/împărțire într-o treaptă.
Dar pentru două sau chiar mai multe trepte de coeficienți pentru obținerea de numere noi de fond 1 (nu se scriu mari depozite numerice), este clar că trebuie să mai fac și niște variante modificate pentru VECUN și MODIFSUM. Poate că pot și pentru SUMRED, NUMSIMPL și MODPRIM, dar ultimele două se bazează exclusiv pe numere prime, adică mai puține decât cele neprime (avantaj că pot să treacă prin mai multe mii de numere de bază, chiar și de prima treaptă, coeficienții de legătură fiindu-le mai puțini).
Unde sunt mai multe șarje de coeficienți de legătură la recursivitate, numerele de bază și de treaptă trebuiesc date potrivit de multe sau puține, ca produsul lor total de lucru să nu însemne miliarde de numere de verificat care să ceară foarte mult timp pe sesiunea de lucru, deși se poate și așa cu scrierea continuată a rezultatelor de fond 1 într-un fișier, cărui fișier să-i dau periodic vecung2 ca să văd dacă-i rost de noutăți la fondul 1. Tot așa (vecung2) aș putea face și la căutările unitreaptă de numere de fond 1 pe fronturile 1 și 2, căutări făcute pe baza marilor depozite. Dar la toate aceste noutăți de căutare numerică, pe oricare front numeric, ar fi bine chiar să vină numere noi, spre deosebire de situația de la VECUNSUB, care este o variantă de FACTORSUBM pe N3.TXT, însă care nu mi-a adus mai mult de câteva numere noi de fond 1 numărabile pe degete, iar asta hăt în 2014, adică pe vremea altei situări numerice, chit că și 2014 a fost un an de progres algoritmic și numeric (chiar și hardware, cu primul hard disk de 2 TB).
Comentarii
Trimiteți un comentariu