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

Marko Vojinovic vmarko at ipb.ac.rs
Thu Mar 3 02:40:19 CET 2022


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
> 
> 
>


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