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

Dusan Cvijetic dusancvijetic2000 at gmail.com
Fri Mar 4 21:34:18 CET 2022


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
<http://rapidxml.sourceforge.net/manual.html#classrapidxml_1_1memory__pool>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220304/7ab06ef6/attachment-0001.htm>


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