Ştiri:

Vă rugăm să citiţi Regulamentul de utilizare a forumului Scientia în secţiunea intitulată "Regulamentul de utilizare a forumului. CITEŞTE-L!".

Main Menu

Tangente despre limbajul de programare C++

Creat de b12mihai, Noiembrie 19, 2009, 07:44:49 PM

« precedentul - următorul »

0 Membri şi 1 Vizitator vizualizează acest subiect.

Dendros

 Dacă înţeleg corect ce a spus Adi, e un avantaj să începi direct, fără nici un fel de experienţă în programare, cu un limbaj care suportă POO, cum ar fi C++, fiindcă astfel nu mai ai de depăşit bariera obişnuinţei cu ceea ce ai învăţat într-o paradigmă non-POO. Aşa e?

Adi

Citat din: Dendros din Noiembrie 21, 2009, 09:14:36 PM
Dacă înţeleg corect ce a spus Adi, e un avantaj să începi direct, fără nici un fel de experienţă în programare, cu un limbaj care suportă POO, cum ar fi C++, fiindcă astfel nu mai ai de depăşit bariera obişnuinţei cu ceea ce ai învăţat într-o paradigmă non-POO. Aşa e?

Da, asta e. Si exista tutoriale in C++ care te iau pas cu pas. Ca si cartea sugerata de HarapAlb si cea sugerata de mine. Si pot ajuta si eu cu sfaturi, atat cat ma pricep, precum si forumul sugerat de Gothik si pe care mi-am facut si eu cont acum. Poti incepe prin a rezolva probleme simple, foarte simple, pas cu pas.
Pagina personala: http://adrianbuzatu.ro

Adi

Dupa cateva zile de incercari, am realizat un proiect care calculeaza din aproape in aproape traiectoria unei planete in jurul Soarelui (adica in camp gravitational variabil) sau la alegere a unui corp in campul gravitational al Pamantului considerat constant (fizica de a noua, precum aruncarea pe verticala). Programul pune intr-un fisier pozitiile x si y la momente succesive ale planetei. Apoi am folosit gnuplot in linux pentru a realiza graficul intre x si y, adica traiectoria. Iata mai jos cum arata pentru intervale de cate 1 zi (traiectoria nu se inchide) si de o ora (traiectoria se inchide perfect).

Acum as dori sa fac o aplicatia care sa poata reda traiectoria sub forma de film. Am gasit ca pentru Linux ar fi Qt pe baza de C++, dar e mult de munca cu instalarea. Ma gandesc si la un applet Java. Va voi tine la curent.

Mi se pare super tare programarea cand faci ceva ce nu e pentru scoala. Pacat ca nu a invatat bine mai de mult.
Pagina personala: http://adrianbuzatu.ro

HarapAlb

Citat din: Adi din Noiembrie 29, 2009, 08:00:42 AM
Dupa cateva zile de incercari, am realizat un proiect care calculeaza din aproape in aproape traiectoria unei planete in jurul Soarelui (adica in camp gravitational variabil) sau la alegere a unui corp in campul gravitational al Pamantului considerat constant (fizica de a noua, precum aruncarea pe verticala).
Ce ecuatii ai folosit ?

Citat
Acum as dori sa fac o aplicatia care sa poata reda traiectoria sub forma de film. Am gasit ca pentru Linux ar fi Qt pe baza de C++, dar e mult de munca cu instalarea. Ma gandesc si la un applet Java. Va voi tine la curent.
Ai putea sa desenezi direct datele in imagini, folosind de exemplu LibTIFF, pe care apoi le pui impreuna intr-un film. Cred ca exista deja biblioteci de functii pentru asta, sau poti folosi mplayer/mencoder care s-ar poate lansa dintr-o aplicatie C/C++.

Adi

Am folosit F=ma si F=kMm/r^2. In rest a fost modelizare numerica, pas cu pas. Adica presupui ca pe durata unui interval de timp acceleratia este constanta si calculezi pozitia si viteza la sfarsitul acestui interval dupa x=x0+v0*t+1/2*a*t^2 si v=v0+a*t. Apoi x si v devin x0 si v0 pentru urmatorul interval, iar la noua pozitie se calculeaza noul a pentru urmatorul interval. a este calculat pentru o singura planeta ce se invarte in jurul unei stele fixe. Urmatorul pas este sa consier ca si steaua este tot o planeta si doar din calcul sa rezulte ca sta pe loc. Apoi sa pun un numar nelimitat de planete, pentru a forma un sistem solar.

Mersi si de a doua sugestie, o sa ma uit.
Pagina personala: http://adrianbuzatu.ro

radhoo

Citat
Citat
Acum as dori sa fac o aplicatia care sa poata reda traiectoria sub forma de film. Am gasit ca pentru Linux ar fi Qt pe baza de C++, dar e mult de munca cu instalarea. Ma gandesc si la un applet Java. Va voi tine la curent.
Ai putea sa desenezi direct datele in imagini, folosind de exemplu LibTIFF, pe care apoi le pui impreuna intr-un film. Cred ca exista deja biblioteci de functii pentru asta, sau poti folosi mplayer/mencoder care s-ar poate lansa dintr-o aplicatie C/C++.

Intr-adevar, rolul actual al masinii e acela de a automatiza, daca ai folosit masina pentru a calcula coordonatele, trebuie sa elimini partea manuala in care trimiti coordonatele spre procesare ulterioara, cu alte cuvinte sa faci un singur program care se ocupa de intregul proces: - tu introduci parametrii , el iti furnizeaza filmul dorit.
Sugestia de mai sus e bine aleasa, LibTiff, impreuna cu alte librarii pentru formate grafice libpng sau libjpg iti vor permite sa renunti la GnuPlot: programul tau va calcula coordonatele si va produce imagini statice pentru fiecare set de coordonate.
Fara a folosi librarii, unde un minim de experienta in programare e de dorit, poti reprezenta coordonatele grafic si produce imagini BMP, care au o alcatuire asa de simpla, incat nu ai nevoie de librarii externe.
Idea ar fi urmatoarea:
- iti propui o rezolutie maxima de lucru, sa spunem 800x600, pentru a nu ingreuna procesorul
- vizualizezi aceasta suprafata ca un sistem cartezian
- desenezi punctele corespunzatoare traiectoriei planetei
- desenezi alte informatii , cum ar fi: pozitie, timp, parametrii folositi, intr-un colt al suprafetei
- salvezi suprafata intr-un format grafic
BMP, nu este altceva decat un header (BM...) + o colectie de puncte reprezentate prin culoare. Pentru a reprezenta punctul, intram in mai multe detalii, si anume adancimea de culoare:
Formatul cel mai des utilizat e RGB24, in care se folosesc 8 biti pentru rosu, 8 pentru verde si 8 pentru albastru. Astfel avem 2^8 nuante de rosu, 2^8 nuante de verde si 2^8 nunte de albastru.
00000000 va fi cel mai inchis rosu, in timp ce 11111111 va fi cel mai puternic/viu/colorat rosu. Pentru un punct reprezentat in RGB24 vom avea asadar 2^24 culori posibile.
000000000000000000000000 reprezinta negru
111111111111111111111111 reprezinta alb
Revenind la BMP, dupa headerul initial, BMP-ul contine multimea de 800x600 puncte, un total de informatie de 800x600x24biti. Daca imaginea ta este complet neagra, fisierul BMP va contine dupa haeder doar zero-uri.
Din total commander se poate verifica acest lucru deschizand cu F3 imagini BMP, eventual negre :)
Adancinmea de culaore poate fi si de 16 biti, de 8 biti, sigur calitatea culorii este redusa, 8 biti insemnand un numar de 256 de culori posibile.


Daca aceste informatii sunt necesare pentru scriereaa unui BMP, celelalte formate sunt mai complicate. Sa privim putin formatul JPG . A fost introdus pentru a oferi o mai buna compresie a informatiei reprezentate. Problema se pune in felul urmator: daca Adi reprezinta un sistem solar intr-o imagine de 800x600, dar nu deseneaza nici o planeta sau soare, va avea o imagine neagra, care va necesita spatiu de stocare in format BMP:   header (neglijabil) + 800x600x3Bytes, si tot ce vom stoca vor fi zero-uri. E o risipa.
Nu ar fi mai eficient sa stocam informatia in felul urmator:
dreptunghi de la 0,0 la 800,600 , de culoare negra?

Cam asa functionaza JPG, aproximeaza zone de nuante apropiate la o singura culoare, si nu mai retine o multime de puncte ci o definitie a unei zone. Ca un exercitiu salvati o imagine cu detalii (o poza din vacanta) in format JPG la calitate minima (0) . Veti vedea ca zonele patratoase sunt evidente: practic calitatea JPG se refera la pragrul de aproximare al nuantelor apropiate: calitate mica inseamna ca tot mai multe nunte sunt sudate intr-o singura culoare.

Pentru reprezentari video, lucrurile devin si mai complicate. Un fisier Video are ca si fisierele imagine o anumita structura, si un fel de a reprezenta informatia. Facem abstractie de sunet, in cazul de fata, si ne usuram situatia.
Un film pentru a da impresia de naturalete animatiei trebuie sa ruleze 25 de cadre pe secunda. Daca cadrele noastre sunt sistemul planetar al lui Adi, ar inseamna 25 de cadre la rezolutie de 800x600. Daca informatia nu este comprimata in nici un fel inseamna ca fiecare secunda necesita un spatiu de 25x800x600x3 bytes = 36MB . O ora de film ar ocupa 129600MB, adica 129GB . Si asta fara sunet. Cat are hardul vostru? :)

Si aici se folosesc tehnici de compresie asemanatoare celei descrisa pt JPG. Cel mai bun lucru, Adi, ar fi sa creezi un format [GIF animat], care nu e altceva decat un format grafic cu un header in care se defineste rezolutia si un numar de cadre, si un delay dupa fiecare cadru, dupa care imaginile sunt concatenate intr-un singur fisier. Nu foloseste sunet nenecesar pentru scopul tau , si e abordabil din punct de vedere al programarii.

Adi

Multumesc foarte mult pentru raspunsul amplu. Sunt de acord ca asa e ideal. Sa bag parametrii initiali si sa imi furnizeze direct filmul final. Cand voi avea timp, voi analiza posibilitatea asta mai in detaliu. O alta posibilitate este sa fac in Java un JavaApplet, caci acolo poti face animatii direct in programul care le calculeaza. Cand o sa fac asa ceva, o sa dau aici de veste. Mersi mult.
Pagina personala: http://adrianbuzatu.ro

florin_try

#22
alta varianta pentru animatie e pov-ray.

Nu cred ca ai energia conservata in programul tau.

Adi

Citat din: florin_try din Februarie 07, 2010, 02:00:15 AM
alta varianta pentru animatie e pov-ray.

Mersi mult de sugestie. Am cautat pe google si am gasit http://www.povray.org/download/ si am inteles ca poti face simulari 3D in ea. Deocamdata in cazul problemei mele consideram doar miscari 2D, intr-un plan, dar e bine de stiut de poy-ray.

Citat din: florin_try din Februarie 07, 2010, 02:00:15 AM
Nu cred ca ai energia conservata in programul tau.

La ce te referi mai precis? In programul meu nu exista notiunea de energie, ci este o modelizare numerica din aproape in aproape a mersului planetelor. Adica la un anumit moment t ai pozitiile si vitezele plantelor. Calculezi atunci forta totala asupra unei plante, deci acceleratia totala si evoluezi acea planeta pe un timp scurt cu acceleratie constanta. Noua pozitie si noua viteza sunt valori de intrare pentru pasul urmator cand noile pozitii duc la noile forte si noile acceleratii si tot asa. E exact cum face Natura, caci ea nu stie de energie, ci doar de forta din aproape in aproape ...

Pe viitor voi dori sa demonstrez si matematic ca traiectoria unei plante in jurul Soarelui e o elipsa plecand de la o forta ce variaza cu inversul patratului distantei. Nu e greu, dar inca nu am facut asta. Aici insa am facut numeric pentru un sistem de un numar oarecare de planete.
Pagina personala: http://adrianbuzatu.ro

florin_try

#24
Dar Hamiltonianul sistemului nu trebuie sa se conserve? Asta e primul lucru care sa il verifici: cit de bine ti se conserva energia totala a sistemului. Functie de asta hotarasti cit de mic iei pasul de integrare numerica.

Am impresia ca tu folosesti un algoritm de integrare f.f. rudimentar. Nu pare ca e reversibil in timp (alegere f. nefericita).
Porneste de la starea finala, schimba semnul timpului si vezi daca ajungi la conditia initiala.

Vezi si linkurile:
http://en.wikipedia.org/wiki/Verlet_integration
http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods

Daca arati codul ar fi mai simplu.

Citat
povray....

In povray poti face tot ce vrei, inclusiv arta 3D. Sunt pe internet o multime de "pov-ray artists".





Adi

Citat din: florin_try din Februarie 07, 2010, 09:43:06 AM
Dar Hamiltonianul sistemului nu trebuie sa se conserve? Asta e primul lucru care sa il verifici: cit de bine ti se conserva energia totala a sistemului. Functie de asta hotarasti cit de mic iei pasul de integrare numerica.

Interesant, nu stiam. Eu am ales pasul dupa ochi, pana am vazut ca traiectoria se inchide. In special am ales o zi pasul de integrare.

Citat din: florin_try din Februarie 07, 2010, 09:43:06 AM
Am impresia ca tu folosesti un algoritm de integrare f.f. rudimentar. Nu pare ca e reversibil in timp (alegere f. nefericita).
Porneste de la starea finala, schimba semnul timpului si vezi daca ajungi la conditia initiala.

Interesant si asta. Intr-adevar, am folosit algoritmul de baza al Naturii cu un  pas de 1 zi. Nu stiam ca exista aceste metode. Mersi.

Citat din: florin_try din Februarie 07, 2010, 09:43:06 AM
Vezi si linkurile:
http://en.wikipedia.org/wiki/Verlet_integration
http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods
Daca arati codul ar fi mai simplu.

Ar fi mai simplu sa ce?
Pagina personala: http://adrianbuzatu.ro

florin_try

OK, ruleaza codul pentru 100ani, 1000ani, pina la 100,000 ani (sau 1 milion ani daca).
Obtii traiectorii stabile (circulare/elispoidale) sau spirale?

Adi

Citat din: florin_try din Februarie 07, 2010, 06:38:29 PM
OK, ruleaza codul pentru 100ani, 1000ani, pina la 100,000 ani (sau 1 milion ani daca).
Obtii traiectorii stabile (circulare/elispoidale) sau spirale?

Inteleg ideea ta. Numai ca ar trebui sa stiu foarte precis parametrii planetelor pentru a putea macar incerca o simulare pe o durata foarte lunga. De exemplu eu am luat la momentul zero toate planetele ca fiind pe axa mare si plecand in sus. Ca sa fie usor de pus datele de intrare. Si am pus raza si viteza medie a lor in jurul Soarelui. Cu astfel de date, oricat de precis ar fi calculul, tot ar devia de la stabilitate intr-un interval scurt de timp, cred. Caci si planetele se influenteaza intre ele. Dar ce as putea incerca este cu o singura planeta  in jurul Soarelui si sa vedem dupa cat timp nu e stabila.

Acum sunt foarte ocupat, dar la vara sper sa studiez asta mai in detaliu si sa fac un Java Applet sa se vada si grafic.
Pagina personala: http://adrianbuzatu.ro