суб, 5. мар 2022. у 01:27 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:

Pozdrav Dusane,

Svidja mi se kako si ovo uradio, odlican posao! Vidim da f-ja radi ono sto treba (do na neke detalje, vidi nize), a pitanje optimizacije nam uopste nije relevantno --- snimanje u fajl je nesto sto se radi retko i kao one time effort, pa brzina izvrsavanja uopste nije vazna. :-) Radije bih da imamo jasan i razumljiv kod, kako je sada napisan, nego da bude "optimizovan" i kriptican.

Sto se tice memory leak-ova, to treba da pregledamo i vidimo da li rapidxml negde nesto leak-uje --- eventualno procitaj u uputstvu detalje kako se tamo alocira memorija. Mozda je to sve ipak ok, nego se samo VS IntelliSense "prevari" jer je metod za alociranje u rapidxml-u "nestandardan"... Mozda bi mogli i Nenad i Jaroslav da pogledaju to, cisto da budemo sigurni da je sve ok.

E sad, evo i spiska stvari koje bi trebalo jos da doteras u kodu:

(1) Direktorijum "rapidxml/" stavi unutar novog direktorijuma "third-party-software/". Verovatno cemo vremenom dodavati jos drugih tudjih paketa, pa da svi oni budu u tom jednom direktorijumu, da bude jasno sta se gde nalazi.

(2) F-je

SimpComp::save_complex_to_xml_file()
SimpComp::get_element_levels_as_xml_nodes()

stavi u input-and-output.cpp, i odgovarajuce deklaracije u input-and-output.hpp, tamo im je prirodnije mesto. Ostale f-je su ok tu gde su.

(3) U color.hpp, red 54, imas duplo ;;

string get_color_value_as_str() const;;

(4) U triangulator.hpp, red 13, imas duplo // u putanji:

#include "rapidxml//rapidxml_print.hpp"

(5) Na kraju algoritma, kad obrises privremene UniqueID boje, treba da resetujes next_free_uid_number na (staru) zapamcenu vrednost current_maxid:

UniqueIDColor::next_free_uid_number = current_maxid;

(6) Za ceo SimpComp, osim tabele elemenata, algoritam treba da zabelezi u fajl i njegovo ime i dimenziju:

string name;
int D;

(7) Za svaki simpleks iz klase KSimplex, osim boja i suseda, algoritam treba da zabelezi u fajl i njegov nivo i dimenziju:

int k;
int D;

(8) Nije mi jasno u cemu je razlika u nameni izmedju f-ja

Color::set_color_value_from_str()
Color::set_color_value_as_str()

Vidim da su one samo placeholder-i u klasi Color, ali zasto ima dve, i cemu tacno treba da sluze?

(9) Prilikom kompajliranja pomocu g++ mora da se doda flag -fpermissive da bi kod hteo da se kompajlira --- to mi se ne svidja, i to treba da popravimo. U prilogu ti saljem error.log koji ispisuje g++ bez -fpermissive opcije (sa tom opcijom ispisuje sve to isto samo error-ove tretira kao warning-e). Kako izgleda, gomila f-ja iz rapidxml_print.hpp se koristi pre nego sto je deklarisana, pa je verovatno dovoljno da negde dodas odgovarajuce forward-deklaracije za sve njih. Pritom bih voleo da tudji kod ne diramo, nego da forward-deklaracije dodas u neki nas lokalni fajl (recimo "rapidxml-patch.hpp"), koji cemo da include-ujemo u triangulator.hpp neposredno ispred rapidxml_print.hpp, i time eliminisemo problem sa kompajliranjem.

To je otprilike to. Hvala puno za ovo, ova f-ja je vazan doprinos, i mislim da si je veoma lepo uradio. Posto si se vec uvezbao sa rapidxml-om, ako ti nije tesko, uradi i inverznu f-ju (zadatak 8) --- kad budes imao vremena naravno, nije frka. ;-)

:-)
Marko

Dr. Marko Vojinovic
Group for Gravitation, Particles and Fields
Institute of Physics
University of Belgrade
======================
home page: www.markovojinovic.com
e-mail: vmarko@ipb.ac.rs

On Fri, 4 Mar 2022, Dusan Cvijetic wrote:

> Pozdrav,
>
> Ovo je bilo teže nego što sam se nadao.
>
> Dodao sam funkciju string get_color_value_as_str() i implementirao je za već postojeće boje. Dodaću i inverznu funkciju (verovatno tek tokom sledeće nedelje).
>
> Implementirao sam i pisanje kompleksa u .xml fajl. Za to sam koristio biblioteku RapidXML, jer je obećavala najbrže izvršavanje. Međutim, ova biblioteka koristi neka čudna alociranja
> memorije sa kojima se ranije nisam susreo, pa se bojim da negde ne dođe do curenja. Štaviše, VS IntelliSense mi izbacuje upozorenja (dostavljam ih ispod teksta poruke) koja ne razumem,
> a tiču se memorije. Najbolje bi bilo da ovo pregleda neko sa malo više iskustva i znjanja, jer mi miriše na problem.
>
> Testirao sam kod na trouglu i tetraedru koji su pravljeni u glavnoj funkciji, i na ovim primerima radi. Nije ni blizu optimalan, ali vratiću se ponovo ovom problemu kasnije. Hteo sam da
> okačim i ovu verziju da biste mogli da pratite napredovanje, i na vreme iskritikujete sve što ne valja.
>
> Pozdravi,
> Dušan
>
>
> Severity Code Description Project File Line Suppression State
> Warning C26495 Variable 'KSimplex::D' is uninitialized. Always initialize a member variable (type.6). triangulator C:\Users\Duca\OneDrive - student.etf.bg.ac.rs\PRAKSA
> VOJINOVIC\triangulator\classes.cpp 7
> Warning C6262 Function uses '65996' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. triangulator C:\Users\Duca\OneDrive -
> student.etf.bg.ac.rs\PRAKSA VOJINOVIC\triangulator\classes.cpp 288
>
> чет, 3. мар 2022. у 02:40 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
>
> Sto se mene tice slazem se, takva f-ja zvuci pametno. Takodje, to bi omogucilo korisnicima da sami zadaju takve f-je za svoje custom boje koje budu kreirali. Npr, ako neko
> hoce da napravi klasu boja 3x3 kompleksnih matrica, moci ce da implementira i takvu f-ju za svoju klasu, koja ce na odgovarajuci nacin da pretvori te podatke u stringove
> koji mogu da se zapisu u fajl.
>
> Sto se tice dosadasnjih print f-ja, njih je napisao Nenad --- moj utisak je da je koristio static cast samo zato sto je to dovoljno za te elementarne print f-je. Ali ako ima
> neki ozbiljniji razlog zasto bi static cast bio bolji od ove f-je koju ti predlazes, javice nam. :-)
>
> U medjuvremenu, slobodno implementiraj get_color_value_as_str() i koristi je za pisanje u fajl. Razmisli eventualno i o "inverznoj" f-ji koju bismo koristili za citanje
> stringa iz fajla i prevodjenje u native vrednost za datu boju.
>
> :-)
> Marko
>
>
> Dr. Marko Vojinovic
> Group for Gravitation, Particles and Fields
> Institute of Physics
> University of Belgrade
> ======================
> home page: www.markovojinovic.com
> e-mail: vmarko@ipb.ac.rs
>
>
>
> On Thu, 3 Mar 2022, Dusan Cvijetic wrote:
>
> > Pozdrav,
> >
> > Stigao sam do ispisa redosledno boja za svaki k-simpleks, i video sam da je za ispis (u print funkcijama) ranije korišćen static cast. Imam predlog da ovo elegantnije
> rešimo tako što
> > ćemo dodati virtuelnu funkciju string get_color_value_as_str()koja bi vraćala odgovarajući zapis vrednosti boje kao string, a omogućila bi nam da, kada god želimo da
> dobijemo vrednost
> > određene boje za štampanje, samo polimorfno pozovemo tu funkciju. Ovo drastično pojednostavljuje sva štampanja, i mnogo lakše se skalira za veliki broj boja.
> >
> > Kako zvuči ova ideja?
> >
> > Pozdravi,
> > Dušan
> >
> > сре, 2. мар 2022. у 17:28 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> >
> > Pozdrav Dusane,
> >
> > Generalna ideja je da ne izmisljamo toplu vodu --- ako postoji gotov softver za neku funkcionalnost, svakako to treba da koristimo, ako je moguce i ako nam je
> zgodno.
> >
> > U ovom konkretnom slucaju ti treba da procenis da li ti je lakse da koristis postojece parsere ili ti je lakse da napises svoj. Obicno je bolja ideja da koristis
> postojeci.
> > MIT licenca je verovatno ok, to ne bi trebalo da bude problem.
> >
> > Pritom, za sve "tudje" fajlove, koji nisu nas kod, napravi zasebnu strukturu pod-direktorijuma u kojoj cemo da ih drzimo, da se ne mesaju sa nasim kodom. Znaci npr.
> ovako:
> >
> >    mkdir ~/third-party-software/RapidXml/
> >    mkdir ~/third-party-software/jsoncpp/
> >
> > pa onda u te direktorijume stavljaj njihov source i/ili include fajlove ili stagod, sve sto ti je potrebno za rad naseg softvera. Include-uj odnosno link-uj sve
> takve
> > fajlove sa tom relativnom putanjom itd. Ovo je vazno da se odvoji jer se od nas zahteva da merimo "napredovanje u razvoju" naseg softvera ukupnim brojem linija koda,
> u koji
> > normalno ne treba da racunamo tudj kod. ;-)
> >
> > :-)
> > Marko
> >
> >
> > Dr. Marko Vojinovic
> > Group for Gravitation, Particles and Fields
> > Institute of Physics
> > University of Belgrade
> > ======================
> > home page: www.markovojinovic.com
> > e-mail: vmarko@ipb.ac.rs
> >
> >
> >
> > On Wed, 2 Mar 2022, Dusan Cvijetic wrote:
> >
> > > Pozdrav,
> > >
> > > Da li treba da pišem parser od nule, ili mogu da koristim neku gotovu biblioteku? Video sam da za .xml fajlove postoji, recimo, RapidXml, a za .json fajlove
> jsoncpp. Oba
> > imaju MIT
> > > licencu, koja nam, koliko sam razumeo, dozvoljava da sa njima radimo šta želimo, dok god uz izvorni kod uključimo i fajl sa samom licencom.
> > >
> > > Ako biste radije da pišem parser od nule, onda bismo možda mogli da ga realizujemo kao zasebnu klasu (sa decom-klasama za svaku vrstu fajla), pa da SimpComp sadrži
> kao
> > svoje polje jedan
> > > pokazivač na njen objekat, i funkcije za pisanje/čitanje koje polimorfno pozivaju odgovarajući parser, u zavisnosti od vrste fajla koji koristimo.
> > >
> > > Pozdravi,
> > > Dušan
> > >
> > > пон, 28. феб 2022. у 15:36 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> > >
> > > Svakako, samo napred --- jedino uzmi u obzir da sam ja pisao onu .xml notaciju napamet, nisam siguran kako tacno treba da glasi. Pogledaj negde na netu kakva
> je
> > pravilna
> > > sintaksa i specifikacija za .xml, nemoj da se oslanjas mnogo doslovno na moje primere u formulaciji zadatka.
> > >
> > > :-)
> > > Marko
> > >
> > >
> > > Dr. Marko Vojinovic
> > > Group for Gravitation, Particles and Fields
> > > Institute of Physics
> > > University of Belgrade
> > > ======================
> > > home page: www.markovojinovic.com
> > > e-mail: vmarko@ipb.ac.rs
> > >
> > >
> > >
> > > On Sun, 27 Feb 2022, Dusan Cvijetic wrote:
> > >
> > > > Pozdrav,
> > > >
> > > > Uzeo bih ovaj zadatak da radim, ako je to u redu.
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > > пет, 11. феб 2022. у 23:14 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> > > >
> > > > Implementirati metod u klasi SimpComp koji ce da snimi dati simplicijalni kompleks u fajl:
> > > >
> > > >    file* SimpComp::save_complex_to_file( string filename );
> > > >
> > > >    Input: ime fajla u koji ce se snimiti kompleks.
> > > >    Output: pointer na fajl u koji je snimljen kompleks.
> > > >
> > > > Prvi korak u implementaciji ovoga je odabir tipa fajla koji ce da sadrzi podatke, i njegove strukture. Fajl mora da bude istovremeno i
> machine-readable i
> > > human-readable, i
> > > > dva moguca predloga su .xml i .json tipovi, mada slobodno predlozite i neki treci ako mislite da je bolji od ova dva. Algoritam za snimanje bi
> trebalo da ide
> > ovako:
> > > >
> > > > (1) Zapamtiti trenutnu vrednost globalne varijable next_free_uid_number iz klase UniqueIDColor (na primer, neka ta vrednost bude 12). Kompleks mozda
> vec
> > sadrzi neke
> > > boje iz
> > > > ove klase, i sve instance za koje je id manji od ove zapamcene trenutne vrednosti treba preskakati i ignorisati u nastavku algoritma, tj. tretirati
> ih kao i
> > boje
> > > svih
> > > > ostalih tipova.
> > > >
> > > > (2) Obojiti ceo kompleks bojom UniqueID (pozvati f-ju UniqueIDColor::colorize_entire_complex() iz zadatka 2). Ove nove id-ove cemo da koristimo za
> imenovanje
> > > pojedinacnih
> > > > simpleksa u fajlu.
> > > >
> > > > (3) Zapisati u fajl strukturu vektora elements naseg kompleksa --- deklarisati level 0 i u njemu pobrojati nove id boje svih 0-simpleksa, zatim
> deklarisati
> > level 1 i
> > > > pobrojati sve 1-simplekse, itd zakljucno sa nivoom D. U .xml formatu bi to moglo da izgleda npr ovako (ne znam tacno kako ide .xml sintaksa, pisem po
> > secanju):
> > > >
> > > > <level 0>12,13,14,15,16,17,18</level 0> // id brojevi nivoa 0 u kompleksu
> > > > <level 1>19,20,21,22</level1> // id brojevi nivua 1 u kompleksu
> > > > ... // nastavljamo ovako zakljucno sa nivoom D
> > > >
> > > > Obratite paznju da su svi id brojevi >= 12.
> > > >
> > > > (4) Zapisati u fajl strukturu svakog k-simpleksa --- deklarisati simpleks njegovim id brojem, i zatim ispisati sve tipove i vrednosti boja, kao i id
> brojeve
> > svih
> > > njegovih
> > > > suseda, poredjanih kao u koraku (3). Na primer, .xml sintaksa bi izgledala recimo ovako:
> > > >
> > > > <ksimplex 12>
> > > > <color-type>0</color-type> // ova nula je TYPE_BOUNDARY
> > > > <color-value>true</color-value> // ovo je vrednost boundary boje
> > > > <color-type>129</color-type> // ovo je TYPE_UNIQUE_ID
> > > > <color-value>11</color-value> // ovo je id vrednost UniqueID boje, koja je *manja* od 12
> > > > ... // pisemo type-value kombinacije za sve boje, *osim* za (poslednju) UniqueID boju koja je veca od 12
> > > > <level 0></level0> // ovaj simpleks npr nema susede nivoa nula
> > > > <level 1>19,22,41,356</level1> // id boje suseda nivoa 1 (svi su *veci* od 12...)
> > > > ... // pisemo strukturu za svih D nivoa suseda
> > > > </ksimplex 12>
> > > > <ksimplex 13> // ponavljamo gornju strukturu za naredni k-simpleks
> > > > ...
> > > > </ksimplex 13>
> > > > ... // dok ne uradimo sve k-simplekse u kompleksu.
> > > >
> > > > Kad se ovo zavrsi, fajl je snimljen, zatvoriti ga. Ukoliko postoje neke vec gotove biblioteke C++ rutina koje konstruisu .xml i .json sintaksu na
> osnovu
> > nekih
> > > ulaznih
> > > > podataka, verovatno je dobra ideja da ih iskoristimo, umesto da sami pisemo svaki simbol tih fajlova (smanjicemo mogucnost sintaksnih gresaka i
> povecacemo
> > > kompatibilnost).
> > > >
> > > > (5) Deinstancirati sve UniqueID boje iz kompleksa koje smo dodali u koraku (2), uz paznju da ne diramo eventualne UniqueID boje koje su vec postojale
> (koje
> > imaju id
> > > vrednost
> > > > < 12 iz primera), cime vracamo kompleks u njegovo pocetno stanje. Takodje, setovati globalnu varijablu next_free_uid_number natrag na vrednost 12,
> zapamcenu
> > u koraku
> > > (1).
> > > >
> > > > Takodje, mozda bi imalo smisla napraviti dve f-je za snimanje fajla (umesto one jedne deklarisane gore),
> > > >
> > > >    SimpComp::save_complex_to_xml_file()
> > > >    SimpComp::save_complex_to_json_file()
> > > >
> > > > koje bi implementirale sve ovo odozgo, ali sa sintaksom odgovarajucom za dati format. Ubuduce cemo mozda da smislimo i neki treci format za snimanje,
> na
> > primer .tex
> > > (za
> > > > crtanje TikZ paketom u LaTeX-u), ili .nb (za Mathematicu), ili sl.
> > > >
> > > >
> > > > :-)
> > > > Marko
> > > >
> > > >
> > > > Dr. Marko Vojinovic
> > > > Group for Gravitation, Particles and Fields
> > > > Institute of Physics
> > > > University of Belgrade
> > > > ======================
> > > > home page: www.markovojinovic.com
> > > > e-mail: vmarko@ipb.ac.rs
> > > >
> > > >
> > > > --
> > > > QGHG-it-dev-list mailing list
> > > > QGHG-it-dev-list@ipb.ac.rs
> > > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > >
> > > >
> > > >--
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list@ipb.ac.rs
> > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > >
> > >--
> > QGHG-it-dev-list mailing list
> > QGHG-it-dev-list@ipb.ac.rs
> > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list@ipb.ac.rs
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>
>
>--
QGHG-it-dev-list mailing list
QGHG-it-dev-list@ipb.ac.rs
http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list