Contest benchmarking

Nu are sens să bagi o dependinţă masivă pentru o problemă relativ simplă, care în plus vine şi cu o licenţă restrictivă (LGPL/GPL v3), care nu permite linkeditarea statică. În plus, care mai e distracţia dacă iei totul mură-n-gură? :slight_smile:

Abordarea mea va fi simplă, pur şi simplu toate numerele mele vor fi de tip int64. Zecimalele (4 sau 8) vor fi reprezentate de ultimele 4/8 cifre. Operaţiile aritmetice vor fi executate ca de obicei, doar la afişare va trebui să am grijă să pun punctul zecimal la locul lui.

Singura problemă pe care o am este că va fi problematic să fac operaţii de înmulţire/împărţire cu numere mari, voi avea overflow foarte repede. Şi nu trebuie uitat că şi punctul zecimal se va deplasa la stânga sau la dreapta, dacă este înmulţire sau împărţire.

O soluţie pentru a evita problema ar fi să folosesc int128_t, doar că tipul ăsta de integer nu există pe 32 de biţi şi încă mai sunt unii care folosesc OS-uri pe 32 de biţi. Acum provocarea mea e să încerc să simulez acel int128 pe 32 de biţi.

În assembler nu pare cine ştie ce inginerie: http://x86asm.net/articles/working-with-big-numbers-using-x86-instructions/

1 Like

Imi poti spune, te rog, care au fost criteriile de alegere a C++ in contextul unor aplicatii economice?

Java/C#/Python au mult mai multe librarii, iar unit testing-ul e o placere.

Pentru aplicatii de-alea nu se folosesc asemenea tipuri. C++ Builder avea o clasa Currency cu care se putea lucra.
Intern nu e mare filozofie, e doar un int64_t, continand valoarea inmultita cu 10000, ca sa mearga cu patru zecimale. Exista biblioteci care iti ofera ce precizie vrei tu.

Nu are rost sa re-inventezi roata acolo, arunca o privire aici, vezi daca iti convine: https://www.boost.org/doc/libs/1_71_0/libs/multiprecision/doc/html/index.html

1 Like
  • For fun.
  • Sunt control-freak, îmi place posibilitatea de a controla total aplicaţia.
  • Dependenţe (aproape) zero.
  • Când există totuşi dependenţe, le includ în executabil. Astfel, aplicaţia mea este formată dintr-un singur fişier, aşa că e simplu de distribuit şi rulat. Uneori nici măcar nu mă obosesc să o livrez cu un installer, îi dau clientului .exe-ul şi gata.
  • Aplicaţiile ies foarte mici, sunt extrem de sprintene şi consumă extrem de puţin RAM. Pornesc şi rulează instantaneu orice operaţiune pe un computer oricât de vechi.
  • Şi nu în ultimul rând, C++ e un limbaj ca oricare altul. Pentru mine să programez în C/C++ sau PHP sau Perl sau Javascript este fix acelaşi lucru.
1 Like

Well, eu reinventez roţile din pură placere, ca să învăţ cum functionează lucrurile. Evident, când nu mă grăbesc.

1 Like

Cred ca este bine sa revezi un mecanism ca sa il intelegi mai pe indelete si sa il optimizezi poate.

Am inceput sa citesc putin si poate in diagonala despre sistemul de fisiere si cum functioneaza api-urile din c# si java. Ce avantaje au, dezavantaje, cum functioneaza per ansamblu etc.

O sa adaug in topic java (in lucru) si js :smiley:

Pt ca avem async stuff voi testa si acea abordare.

For fun înțeleg abordarea ta, dar având în vedere că ai o aplicație de business cu date financiare la mijloc, cel puțin eu sunt orientat către a rezolva scopul de business prima dată.
E interesant, da, să înțelegi cum poți lucra cu big numbers, dar puțin cam riscant să te joci cu ele în producție.

1 Like

Poti da mai multe detalii pe partea de testare automata (unit testing si integration testing)? Macar in linii mari: librarii care fac viata mai usoara in momentul de fata, etc.

In particular, legat de C++, am cativa colegi care prefera sa ocoleasca testarea automata, cateva sugestii utile i-ar putea aduce pe calea cea buna.

Nu folosesc aşa ceva. Ce aş putea testa automat? Şi cum?

1 Like

Cauta ceva gen cpp unit

Testezi faptul ca ceea ce scrii este cirect
Ai o functie/metoda care face calcule. Si tu stii cat ar trebui sa fir rezultatul. Framework-ul de testare iti pune la dispozitie metode de assert, ca de exemplu assertTrue, assertEquals care te ajuta.

Ai avantajul ca poti face si refactoring la cod si sa stii ca esti pe calea buna :slight_smile:

1 Like

Eu cred că folosesc un soi de metodă de programare care am aflat că se cheamă Test Driven Development, rareori am nevoie să am făcute module de testare. Uneori când am nevoie să creez pentru aplicaţie un modul ceva mai mare, creez un proiect separat şi dezvolt indepedent acel modul, după care îl integrez în aplicaţia principală.

:smiley:

Mult succes.

Well, de 25 de ani programez în stilul ăsta şi chiar de curând mi-a zis un client “cum naiba faci, folosesc programul tău de zece ani şi n-a crăpat niciodată” :slight_smile:

Well, it’s something! :grin:

Impresionant :smiley:

Nu am incercat sa insinuez ca ai avea probleme cu codul.

Eu am ajuns sa “simt” la un moment dat nevoia unor teste automate care sa imi ofere un pic de incredere in cazul modificarilor unor cerinte mai complexe (chiar daca nu e nimic critic, de multe ori parsare de informatii din loguri).

Din pacate, solicitarile fiind “agile”, nu am timpul necesar sa practic TDD asa cum trebuie:

  • test care sa pice
  • cod scris cat sa treaca testul
  • refactor (la un moment dat)

si sa repet procesul pana acopar toate cerintele. De asta am zambit, fara sa scrii testele mai intai (sau cel putin marea lor majoritate) nu prea poti spune ca practici TDD.

Depinde şi de environmentul în care lucrezi. Dacă aş lucra în echipă, e clar că aş pretinde unit-test-uri de la colegii mei. Şi aş pune la dispoziţia lor teste foarte minuţioase. Dar când lucrezi singur, nu prea are sens pierderea de timp, pentru că oricum fac miliarde de teste în timpul development-ului, cu input-uri de tot felul, în special voit eronate, ca să prind toate cazurile care cred eu că le-ar putea băga utilizatorii.

În afară de asta, nu poţi să testezi tot. Cum decizi ce este relevant de testat şi ce nu? Eu sunt genul de persoană foarte pedantă, păi dacă mă pui să-ţi fac un test, o să-ţi verific şi poziţia biţilor în memorie, n-aş şti unde să mă opresc cu testarea. Ar dura mai mult scrierea testelor decât a codului în sine. Aşa că prefer să mă abţin :slight_smile:

1 Like

E simplu: minim un test pentru fiecare cerinta.

Cum vine clientul cu “ah, eu credeam ca ar trebui sa se intample asa: …”, cum faci o lista de cerinte (cu cat mai explicite, cu atat mai bine).

Nu sunt foarte sigur că poţi să testezi orice. De exemplu în aplicaţiile economice de tip desktop ai multe chestii care nu se pot testa automat. Cum testezi dacă factura tipărită pe hârtie are toate datele pe ea şi să fie şi corecte acele date?

1 Like

In cazul acela faci testare manuala. Oricum acel lucru nu intra la un unit test. As spune ca ar fi un semi integration test :smiley:

Cel putin asa cred.
La vechiul loc de munca trebuia sa mai fac si acel lucru :))

1 Like

limbaj: Q/KDB+ v3.3 32bit windows 14132ms
cod:

h:hopen `:output.txt
\t .Q.fs[{line:`r`a`b!("FFF";"\t")0:x;neg[h]string line[`b]=line[`r]%line[`a]}]`:random_numbers.txt
hclose h
2 Likes