[QGHG-it-dev-list] Zadatak 7 - snimanje kompleksa u fajl

Dusan Cvijetic dusancvijetic2000 at gmail.com
Mon Mar 7 02:21:51 CET 2022


Pozdrav,

(1) Urađeno.

(2) Prebacio funkcije. Pošto nisu više funkcije članice klase, već su u
zasebnom folderu, sada sam im kao argument dodao pokazivač na simpcomp koji
se štampa, pa su novi potpisi
           void save_complex_to_xml_file(SimpComp* simpComp, const string&
filename);
         vector<rapidxml::xml_node<>*>
get_element_levels_as_xml_nodes(SimpComp* simpComp,
rapidxml::memory_pool<>& mp);

(3) i (4) Uklonio duplikate.

(5) Urađeno.

(6) i (7) Dodao sam i ovaj ispis, s tim što sada ime kompleksa ispisujemo
redudantno - jednom kao ime root XML node, i drugi put kao vrednost XML
node "name".

(8) Ovo je bila greška, slučajno sam ostavio obe funkcije. Razmatrao sam
koje je ime bolje za f-ju koja čita vrednost boje iz stringa, i prvo sam
stavio verziju sa "as" (zbog copy-paste iz get funkcije), ali je bolja
verzija "from", koju sam sad ostavio kao jedinu. Funkcija treba da čita
vrednost boje iz stringa koji joj je prosleđen.

(9) Dodao sam forward deklaracije u fajl  "rapidxml-patch.hpp" za sve
funkcije koje su bacale grešku, proverite je li sad u redu.

Dodatno, ispravio sam imena promenljivih da bi pratila konvenciju koju ste
naveli u mejlu iz diskusije za zadatak 2.

Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako: imena funkcija
> su under_scored, imena klasa su CamelCase, imena promenljivih su camelCase,
> a imena konstanti su UNDER_SCORED_CAPS. Bice zabavno. ;-) Inace, sto se
> tice generalnih konvencija kucanja koda, ponekad se trazi i word-wrap na
> 79-toj koloni, ali mene to strasno nervira na velikom monitoru pa se ja
> prvi necu pridrzavati toga, niti cu vas da teram. ;-)
>

Izvinjavam se zbog tri push-a, primećivao sam da mi fale detalji dok sam
pisao mejl. Biću pažljiviji ubuduće.

Pozdravi,
Dušan

суб, 5. мар 2022. у 01:27 Marko Vojinovic <vmarko at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at ipb.ac.rs
> >       >       >       >
> >       >       >       >
> >       >       >       >       --
> >       >       >       >       QGHG-it-dev-list mailing list
> >       >       >       >       QGHG-it-dev-list at ipb.ac.rs
> >       >       >       >
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >       >       >       >
> >       >       >       >
> >       >       >       >--
> >       >       >       QGHG-it-dev-list mailing list
> >       >       >       QGHG-it-dev-list at ipb.ac.rs
> >       >       >
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >       >       >
> >       >       >
> >       >       >--
> >       >       QGHG-it-dev-list mailing list
> >       >       QGHG-it-dev-list at ipb.ac.rs
> >       >       http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >       >
> >       >
> >       >--
> >       QGHG-it-dev-list mailing list
> >       QGHG-it-dev-list at ipb.ac.rs
> >       http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list at ipb.ac.rs
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220307/abdd08b4/attachment-0001.htm>


More information about the QGHG-it-dev-list mailing list