Progresul hardware, episodul 25: Despre numere, între 2005 și 2010
În aprilie 2010 am avut de parcurs așa divizorii câtorva numere de 20 și ceva de cifre, obținând sau nu din ei numere noi, și când era ceva nou trebuia să localizez poziția din BAZNUM.TXT unde să îl pun (abundența și să fie sortate crescător numerele pe abundențe, și abundențele la fel, crescător). Numai că punerea și sortările acestea le-am făcut mult timp manual, fără programare, și dura și aici.
În luna mai, deja nu mai aveam încotro - descoperiri fuseseră destule făcute, la long double, și limita celui mai mare divizor impar devenea sufocantă, așa că după o încercare fără succes de a folosi un long double pe 128 de biți găsit pe undeva pe Internet (plus, în total până atunci în 2010, alte încercări de a construi lib-uri pentru alte biblioteci de precizie extinsă de pe Internet, care însă mai aveau și stricăciuni în surse), a trebuit, după 14 mai, să pun iar MIRACL în calculator, în martie fusese singura bibliotecă a cărei ordine în sursele compilate mă impresionase plăcut, în pofida vitezei ei joase față de long double. Nu mai aveam ce face, dacă mai voiam numere. Însă câteva zile am mai fost tributar parcurgerii divizorilor pentru sumă, și cum numerele mari erau prea mari pentru o eficientă parcurgere integrală a intervalului divizorilor (cu tot cu noua metodă a separării divizorului impar), la 18 mai, de exemplu, calculam doar parțial sumele de divizori ale divizorilor găsiți și afișam pe ecran abundența cu zecimale, să văd spre ce tinde.
Eram la un curs de la facultate și acasă calculatorul mergea cu aceste calcule parțiale, marți în 18 mai 2010. De aceea, în noaptea de miercuri spre joi, descoperirea cu calculul sumei din factorii primi a fost un progres. Am găsit repede modul de a aranja apoi divizorii primi în vector, fiind ei într-o gamă limitată, altfel și mulțimea numerelor prime este nesfârșită și nu se calculează eficient așa suma divizorilor pentru orice număr. Nu știu câte numere erau în total la 20 mai 2010, poate 500-600 în BAZNUM și câteva, nu știu dacă mai mult de 10-20, abordate cu MIRACL, cu divizorul impar peste 2^64, dar sigur nu ajungeau nici la 50 de cifre, cred că la maximum 37, și divizorii lor primi cred că erau toți până la 2147483647, și mai puțini de o sută (poate vreo 60, astăzi la numerele cu divizorul sub 2^64 sunt 53, în vechile fișiere, cel mai mare prim fiind 2305843009213693951, care sigur că nu ar fi putut fi reprezentat așa în fișier în mai 2010.
Parcurgerea a 50-60 de factori primi întregi într-un vector ușura foarte mult calculul sumei divizorilor, dintr-o dată modul de calculare fiind ca din altă galaxie numerică. Nu stabileam să se oprească parcurgerea în clipa în care suma ar fi fost deja făcută, neavând atunci înțeles și dezvoltat criteriul prin care să îmi dau seama că s-a ajuns deja la ea (abia la valul de dezvoltare algoritmică din 2014 am stabilit semnul care să arate că s-a ajuns deja la sumă, și să se înceteze parcurgerea vectorială), dar la sfârșitul trecerii prin toți primii verificam suma.
Încă nu se terminase iarna 2009-2010 (februarie, cred), când a fost prima dată când am luat un număr, de 24 de cifre, din seria semiperfectelor și multiperfectelor de pe Internet, al cărui cel mai mare divizor impar era prea mare; atunci am văzut că este greșit redată abundența lui și am realizat, într-adevăr, că în ciuda lărgimii teoretice a tipului long double, există o limită mult mai joasă de lucru cu numerele lui. Însă încă mai aveam destule numere de explorat și de obținut în spațiul lui, și nu aveam o mare deschidere către nou în tehnicile de implementare, încât nu am migrat imediat la MIRACL. Am exploatat zona de long double (aproape) cât am putut de mult.
În februarie 2010, în jurul datei de 20, am instalat pentru scurt timp o variantă de GNU C/C++ sub Windows, neavând până atunci vreun contact cu mediul Linux, și așa cum rula în Command Prompt, era mai lentă decât Borlandul 5.5.1, și așa mi-am făcut atunci o imagine proastă, greșită, despre GNU C. De bună seamă că în încercările de a găsi un tip de date mai larg decât long double, atunci, în 2010, am citit ceva și despre GMP, dar când am dat cu ochii de lipsa executabilelor de Windows cu care eram obișnuit și de fișierele printre care era Makefile, cu care nu știam să umblu, am considerat că nu se face și m-am dat bătut. Nu aveam deschidere către mediul Linux și învățarea lucrului cu configure / make, nu știam nici de mediul Cygwin de emulare a Linuxului sub Windows (care oricum nu este prea optim, din ce am văzut în 2013) și nu văzusem niciodată un Linux pe dinăuntru. Am preferat tot ceva executabil sub Windows și așa am stat departe de GMP până în noaptea de 29 spre 30 septembrie 2012.
În ianuarie 2010, calculatorul mergea la greu zi și noapte verificând divizorii câte unui număr mare, și apoi abundențele lor (la începuturi nici nu știam că raportul sumă/număr se numește așa).
Deschiderea către cercetarea numerică asiduă fusese făcută în sfârșitul de săptămână de la mijlocul lunii noiembrie 2009, cel cu duminica de 15, când am intrat pe pagina numericana.com cu semiperfecte și, pe baza câtorva numere de acolo și a algoritmilor pe care îi aveam de la preocupările numerice mult mai sporadice din anii dinainte (începute din 2005), am găsit câteva numere, dintre care două aveau abundența 3.25 dacă nu punem numărul ca divizor în propria sumă, adică 4.25, dar eu mult timp am judecat suma divizorilor ca fiind a tuturor divizorilor naturali ai unui număr natural fără el însuși, adică suma divizorilor proprii + 1, pentru care abundența (sau raportul dintre suma divizorilor numărului și numărul însuși, cum îi spuneam eu) era cu 1 sub cea totală. Adică la primul număr perfect 6 ziceam 1+2+3=6, în loc de 1+2+3+6=12, și raportul era 1 în loc de 2.
Pentru că înainte de anul 2009 am mai făcut cercetări numerice și am mai fost interesat, iar BAZNUM.TXT exista încă din anul 2006. Doar în luna decembrie 2007 și în cea din 2005 mai ținusem calculatorul corespunzător de atunci să meargă mai multe zile încontinuu, în rest, întotdeauna sau aproape întotdeauna mai puțin de 24 de ore deodată pentru numere. Și în vacanța din 2007, între 22 și 28 decembrie, fuseseră găsite câteva zeci de numere, în cinci zile și jumătate, și puse în BAZNUM.TXT. Pe atunci lucram în Borland Pascal 7 pentru DOS, cu ecran de culoare albastră în mediul de lucru. Pe la 18 octombrie 2008 am încercat să fac ceva legat de numere într-un program de Borland C++ 3.1 pentru DOS, care folosea și long double (în toamna anului 2005 mai făcusem câteva zeci de programe în C, cu numerele, șterse stupid în seara de 3 ianuarie 2006, și tot în 2005 avusesem peste 150 de programe în Pascal, tot concentrate pe numere, șterse și ele din răzbunare pentru stupiditatea din 3 ianuarie 2006).
Numai că în 2008 încercam un alt fel de abordare numerică - știam ceva despre printf și scanf, ce în 2005 nu era cazul, și încercam să mă folosesc de long double, ceea ce nu putusem în 2005 din cauză că nu știusem cum să scriu altfel numerele decât cu cin și cout, ceva ce la numerele de la 16777216 în sus ducea la afișarea cu exponent zecimal pe ecran, în locul valorii exacte, atunci, în 2005. Dar nici în 2008 nu am reușit să folosesc un număr long double, pentru că nu îl inițializasem și dădea eroare, și nici nu mi-am dat seama atunci - am crezut că nu merge cu long double și până în noiembrie din anul următor, în 2009, nu am mai încercat.
În luna mai, deja nu mai aveam încotro - descoperiri fuseseră destule făcute, la long double, și limita celui mai mare divizor impar devenea sufocantă, așa că după o încercare fără succes de a folosi un long double pe 128 de biți găsit pe undeva pe Internet (plus, în total până atunci în 2010, alte încercări de a construi lib-uri pentru alte biblioteci de precizie extinsă de pe Internet, care însă mai aveau și stricăciuni în surse), a trebuit, după 14 mai, să pun iar MIRACL în calculator, în martie fusese singura bibliotecă a cărei ordine în sursele compilate mă impresionase plăcut, în pofida vitezei ei joase față de long double. Nu mai aveam ce face, dacă mai voiam numere. Însă câteva zile am mai fost tributar parcurgerii divizorilor pentru sumă, și cum numerele mari erau prea mari pentru o eficientă parcurgere integrală a intervalului divizorilor (cu tot cu noua metodă a separării divizorului impar), la 18 mai, de exemplu, calculam doar parțial sumele de divizori ale divizorilor găsiți și afișam pe ecran abundența cu zecimale, să văd spre ce tinde.
Eram la un curs de la facultate și acasă calculatorul mergea cu aceste calcule parțiale, marți în 18 mai 2010. De aceea, în noaptea de miercuri spre joi, descoperirea cu calculul sumei din factorii primi a fost un progres. Am găsit repede modul de a aranja apoi divizorii primi în vector, fiind ei într-o gamă limitată, altfel și mulțimea numerelor prime este nesfârșită și nu se calculează eficient așa suma divizorilor pentru orice număr. Nu știu câte numere erau în total la 20 mai 2010, poate 500-600 în BAZNUM și câteva, nu știu dacă mai mult de 10-20, abordate cu MIRACL, cu divizorul impar peste 2^64, dar sigur nu ajungeau nici la 50 de cifre, cred că la maximum 37, și divizorii lor primi cred că erau toți până la 2147483647, și mai puțini de o sută (poate vreo 60, astăzi la numerele cu divizorul sub 2^64 sunt 53, în vechile fișiere, cel mai mare prim fiind 2305843009213693951, care sigur că nu ar fi putut fi reprezentat așa în fișier în mai 2010.
Parcurgerea a 50-60 de factori primi întregi într-un vector ușura foarte mult calculul sumei divizorilor, dintr-o dată modul de calculare fiind ca din altă galaxie numerică. Nu stabileam să se oprească parcurgerea în clipa în care suma ar fi fost deja făcută, neavând atunci înțeles și dezvoltat criteriul prin care să îmi dau seama că s-a ajuns deja la ea (abia la valul de dezvoltare algoritmică din 2014 am stabilit semnul care să arate că s-a ajuns deja la sumă, și să se înceteze parcurgerea vectorială), dar la sfârșitul trecerii prin toți primii verificam suma.
Încă nu se terminase iarna 2009-2010 (februarie, cred), când a fost prima dată când am luat un număr, de 24 de cifre, din seria semiperfectelor și multiperfectelor de pe Internet, al cărui cel mai mare divizor impar era prea mare; atunci am văzut că este greșit redată abundența lui și am realizat, într-adevăr, că în ciuda lărgimii teoretice a tipului long double, există o limită mult mai joasă de lucru cu numerele lui. Însă încă mai aveam destule numere de explorat și de obținut în spațiul lui, și nu aveam o mare deschidere către nou în tehnicile de implementare, încât nu am migrat imediat la MIRACL. Am exploatat zona de long double (aproape) cât am putut de mult.
În februarie 2010, în jurul datei de 20, am instalat pentru scurt timp o variantă de GNU C/C++ sub Windows, neavând până atunci vreun contact cu mediul Linux, și așa cum rula în Command Prompt, era mai lentă decât Borlandul 5.5.1, și așa mi-am făcut atunci o imagine proastă, greșită, despre GNU C. De bună seamă că în încercările de a găsi un tip de date mai larg decât long double, atunci, în 2010, am citit ceva și despre GMP, dar când am dat cu ochii de lipsa executabilelor de Windows cu care eram obișnuit și de fișierele printre care era Makefile, cu care nu știam să umblu, am considerat că nu se face și m-am dat bătut. Nu aveam deschidere către mediul Linux și învățarea lucrului cu configure / make, nu știam nici de mediul Cygwin de emulare a Linuxului sub Windows (care oricum nu este prea optim, din ce am văzut în 2013) și nu văzusem niciodată un Linux pe dinăuntru. Am preferat tot ceva executabil sub Windows și așa am stat departe de GMP până în noaptea de 29 spre 30 septembrie 2012.
În ianuarie 2010, calculatorul mergea la greu zi și noapte verificând divizorii câte unui număr mare, și apoi abundențele lor (la începuturi nici nu știam că raportul sumă/număr se numește așa).
Deschiderea către cercetarea numerică asiduă fusese făcută în sfârșitul de săptămână de la mijlocul lunii noiembrie 2009, cel cu duminica de 15, când am intrat pe pagina numericana.com cu semiperfecte și, pe baza câtorva numere de acolo și a algoritmilor pe care îi aveam de la preocupările numerice mult mai sporadice din anii dinainte (începute din 2005), am găsit câteva numere, dintre care două aveau abundența 3.25 dacă nu punem numărul ca divizor în propria sumă, adică 4.25, dar eu mult timp am judecat suma divizorilor ca fiind a tuturor divizorilor naturali ai unui număr natural fără el însuși, adică suma divizorilor proprii + 1, pentru care abundența (sau raportul dintre suma divizorilor numărului și numărul însuși, cum îi spuneam eu) era cu 1 sub cea totală. Adică la primul număr perfect 6 ziceam 1+2+3=6, în loc de 1+2+3+6=12, și raportul era 1 în loc de 2.
Pentru că înainte de anul 2009 am mai făcut cercetări numerice și am mai fost interesat, iar BAZNUM.TXT exista încă din anul 2006. Doar în luna decembrie 2007 și în cea din 2005 mai ținusem calculatorul corespunzător de atunci să meargă mai multe zile încontinuu, în rest, întotdeauna sau aproape întotdeauna mai puțin de 24 de ore deodată pentru numere. Și în vacanța din 2007, între 22 și 28 decembrie, fuseseră găsite câteva zeci de numere, în cinci zile și jumătate, și puse în BAZNUM.TXT. Pe atunci lucram în Borland Pascal 7 pentru DOS, cu ecran de culoare albastră în mediul de lucru. Pe la 18 octombrie 2008 am încercat să fac ceva legat de numere într-un program de Borland C++ 3.1 pentru DOS, care folosea și long double (în toamna anului 2005 mai făcusem câteva zeci de programe în C, cu numerele, șterse stupid în seara de 3 ianuarie 2006, și tot în 2005 avusesem peste 150 de programe în Pascal, tot concentrate pe numere, șterse și ele din răzbunare pentru stupiditatea din 3 ianuarie 2006).
Numai că în 2008 încercam un alt fel de abordare numerică - știam ceva despre printf și scanf, ce în 2005 nu era cazul, și încercam să mă folosesc de long double, ceea ce nu putusem în 2005 din cauză că nu știusem cum să scriu altfel numerele decât cu cin și cout, ceva ce la numerele de la 16777216 în sus ducea la afișarea cu exponent zecimal pe ecran, în locul valorii exacte, atunci, în 2005. Dar nici în 2008 nu am reușit să folosesc un număr long double, pentru că nu îl inițializasem și dădea eroare, și nici nu mi-am dat seama atunci - am crezut că nu merge cu long double și până în noiembrie din anul următor, în 2009, nu am mai încercat.
Comentarii
Trimiteți un comentariu