Necazuri cu scrierea numerelor
Am remarcat de ceva vreme, în mod sigur acum, în 2019, că la unele fișiere .NUM, atunci când se face actualizarea depozitelor numerice (LIT, GIG) cu ERMETE/vecungul sau ERMETE2/vecung, numerele de cifre NU sunt așa cum ar trebui.
De exemplu, dacă un .NUM trebuia să aibă numere între 191 și 204 cifre, poate să apară la maxim ceva cu 407/408 sau eventual vreo 611, ori chiar mai mult - fenomenul numerelor lipite.
Nu am înțeles când se întâmplă asta, am presupus că la sortare (chiar și la noile sortări, pare-mi-se!) ori la scrierea în fișier după sortare, deși instrucțiunile sunt clare - numerele să fie separate prin indicatorul de linie nouă, '\n'.
Că doar n-or veni așa numerele la căutare, în NUM2, înainte de eventuala segmentare și de sigura sortare.
Și trebuiesc despărțite, pe cât de corect posibil, dacă sunt lipite, ca să nu se piardă rezultate. Pentru aceasta, dar cu un grad imperfect de siguranță în rezultate, omenește vorbind, ce-i drept, am făcut în primăvara asta un program nou: rep de la reparare.
Mai demult făcusem un program de scriere dintr-un fișier în alt fișier, cu suprascriere sau atașare (w sau a), care se cheamă scr, apoi, tot pentru probleme cu dimensiunile acceptabile ale numerelor în fișiere, o variantă modificată numită scr2, unde numerele, privite ca stringuri terminate cu caracterul despărțitor linie nouă, să aibă un număr minim și unul maxim de caractere ca să fie scrise în noul fișier.
Pentru cazul mai nou de tratat, cu sindromul numerelor lipite, am remodificat - adică l-am modificat pe scr2, care la rândul lui era varianta schimbată a lui scr, pentru despărțirea numerelor lipite într-un fișier dat; dar, cum scr și scr2 tratează cazuri individuale și eu aveam de-acum cazuri multiple, era nevoie de încă un alt program care să identifice toate cazurile și, pe rând, să le ia la scr-doi-păzește.
Și așa a apărut rep, cu REP.cc și headerul REP.h, în .cc fiind funcția main() și în header făcându-se identificarea acelor fișiere unde diferența dintre minimul și maximul de număr de cifre depășește un anumit prag (un criteriu uneori nesigur, doar spuneam mai sus ceva despre imperfecțiune, plus că și ce am făcut în scr2 poate câteodată să nu despartă corect numerele).
Dar în primele rânduri, verificarea cu acest prag-limită și apelul scr2-ului tot rezolvă fișiere - se fac NUM1-uri noi a căror parte de nume de dinaintea extensiei coincide cu sursa și, cum după prelucrare se așteaptă să iasă nesortate crescător (la alipire am văzut numere care difereau cu 1 în numărul de cifre, unul fiind potrivit cu vecinii, iar celălalt mai mic), ele trebuie să fie NUM1 și să se re-sorteze crescător.
Altfel, omiterea numerelor lipite înseamnă că nu vor fi folosite deloc, și neînmagazinate după merit dacă sunt numere noi.
De exemplu, dacă un .NUM trebuia să aibă numere între 191 și 204 cifre, poate să apară la maxim ceva cu 407/408 sau eventual vreo 611, ori chiar mai mult - fenomenul numerelor lipite.
Nu am înțeles când se întâmplă asta, am presupus că la sortare (chiar și la noile sortări, pare-mi-se!) ori la scrierea în fișier după sortare, deși instrucțiunile sunt clare - numerele să fie separate prin indicatorul de linie nouă, '\n'.
Că doar n-or veni așa numerele la căutare, în NUM2, înainte de eventuala segmentare și de sigura sortare.
Și trebuiesc despărțite, pe cât de corect posibil, dacă sunt lipite, ca să nu se piardă rezultate. Pentru aceasta, dar cu un grad imperfect de siguranță în rezultate, omenește vorbind, ce-i drept, am făcut în primăvara asta un program nou: rep de la reparare.
Mai demult făcusem un program de scriere dintr-un fișier în alt fișier, cu suprascriere sau atașare (w sau a), care se cheamă scr, apoi, tot pentru probleme cu dimensiunile acceptabile ale numerelor în fișiere, o variantă modificată numită scr2, unde numerele, privite ca stringuri terminate cu caracterul despărțitor linie nouă, să aibă un număr minim și unul maxim de caractere ca să fie scrise în noul fișier.
Pentru cazul mai nou de tratat, cu sindromul numerelor lipite, am remodificat - adică l-am modificat pe scr2, care la rândul lui era varianta schimbată a lui scr, pentru despărțirea numerelor lipite într-un fișier dat; dar, cum scr și scr2 tratează cazuri individuale și eu aveam de-acum cazuri multiple, era nevoie de încă un alt program care să identifice toate cazurile și, pe rând, să le ia la scr-doi-păzește.
Și așa a apărut rep, cu REP.cc și headerul REP.h, în .cc fiind funcția main() și în header făcându-se identificarea acelor fișiere unde diferența dintre minimul și maximul de număr de cifre depășește un anumit prag (un criteriu uneori nesigur, doar spuneam mai sus ceva despre imperfecțiune, plus că și ce am făcut în scr2 poate câteodată să nu despartă corect numerele).
Dar în primele rânduri, verificarea cu acest prag-limită și apelul scr2-ului tot rezolvă fișiere - se fac NUM1-uri noi a căror parte de nume de dinaintea extensiei coincide cu sursa și, cum după prelucrare se așteaptă să iasă nesortate crescător (la alipire am văzut numere care difereau cu 1 în numărul de cifre, unul fiind potrivit cu vecinii, iar celălalt mai mic), ele trebuie să fie NUM1 și să se re-sorteze crescător.
Altfel, omiterea numerelor lipite înseamnă că nu vor fi folosite deloc, și neînmagazinate după merit dacă sunt numere noi.
Comentarii
Trimiteți un comentariu