[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla

Nenad Korolija nenadko at gmail.com
Mon Nov 28 23:57:12 CET 2022


Cak i za find_neighbor, mozemo da definisemo kompleks i znamo sta mozemo, a
sta ne da nadjemo.
Za add_neighbor mozemo da testiramo na nekoliko slucajeva da li radi to sto
treba da radi - da li ih je povezala u oba smera.
Za golden complex, collect_vertices treba za pojedine cvorove da vrati
pojedine skupove.
print i print_compact se testiraju poredjenjem output-a sa zakucanim. :)
get_uniqueID trazenjem da li samo za one za koje treba vraca da su uniqueID
obojeni.
delete_my_neighbor proverom brisanja susedstva, itd.
To su zapravo standardni nacini testiranja koji imaju cilj da uhvate
trenutak kad neko nenamerno menjanjem necega izazove bag na skroz drugom
mestu - bolje je odmah na tih 10-ak novih linija koda videti sta se desilo,
nego naici slucajno na gresku nakon 1000 promenjenih linija...

Vidimo se,
Nenad

On Mon, Nov 28, 2022 at 5:01 PM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:

>
> Ok, slazem se, to je dobra ideja, i to mozemo uvek (ili zamalo uvek).
>
> Znaci, za svaku funkciju koja radi na kompleksu neku dobro definisanu
> operaciju --- osmislimo prototip primer za testiranje, seed-ujemo neki
> odgovarajuci pocetni kompleks, uradimo print_detailed() da dobijemo
> strukturu "pre", izvrsimo funkciju koju treba testirati, uradimo opet
> print_detailed() da dobijemo strukturu "posle", i onda to sve uporedimo sa
> predefinisanim zlatnim primerima za "pre" i "posle". Ako se poklapa, f-ja
> radi svoj posao. :-)
>
> Takve testove mozemo da uradimo za pristojno veliki broj stvari:
>   - seed f-je,
>   - Pachner-ove poteze i ostale manipulacije nad kompleksom,
>   - I/O f-je,
>   - dodavanje i brisanje boja.
>
> Jedino f-je u osnovnim klasama (SimpComp i KSimplex) su mozda suvise
> "elementarne" da bi imale output koji moze da se ispise na ekran itd. Ali
> takvih valjda nemamo puno, njih mozemo da tretiramo kao izuzetke i da
> smislimo za njih neke specijalnije testove.
>
> :-)
> 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 Mon, 28 Nov 2022, Nenad Korolija wrote:
>
> > U potpunosti se slazem.
> >
> > Sto se tice testiranja, ne moramo da izmisljamo toplu vodu. Ljudi se
> bave debagovanjem debagera, i ako oni testiraju tako sto imaju pozive neke
> funkcije sa vise input-a i proveru da li
> > su rezultati isti kao sto su ranije bili... :)
> > Dakle, jednom provereno crtanjem na papiru/ekranu postaje zlatni
> primerak, print detailed snimamo u txt i svaki put ocekujemo taj izlaz. Ako
> neko promeni redosled sa dovoljnim razlogom,
> > napravi se novi zlatni izlaz za svaku od funkcija koje pogadja. :)
> >
> > Pozdrav,
> > Nenad
> >
> > On Mon, Nov 28, 2022 at 1:11 PM Marko Vojinovic <vmarko at ipb.ac.rs>
> wrote:
> >
> >       Imalo bi smisla da implementiramo raznorazne f-je unutar test.cpp,
> koje bi testirale raznorazne funkcionalnosti (na neki nacin koji
> definisemo). I onda mozemo da pozovemo
> >       neku od tih test-funkcija bilo iz main(), bilo da napravimo neku
> malu standalone tester-aplikaciju koja ce da prodje kroz sve f-je i kaze
> nam da li je sve ok ili nije.
> >
> >       Takodje, uskoro cemo povezati biblioteku sa gui-jem, i onda ce se
> iz gui-ja neke greske relativno ocigledno videti ako se pojave. Jedna od
> poenti gui-ja je da "upotrebljava"
> >       sve funkcionalnosti biblioteke, pa bi dobar broj gresaka trebalo
> da se uoci i na taj nacin.
> >
> >       I trece, pri kraju smo sa ovim osnovnim funkcijama za kreiranje i
> low-level manipulaciju kompleksima. Kad zavrsimo ove zadatke koji su zadati
> dosad, trudicemo se da vise ne
> >       cackamo postojeci (testirani) kod, nego da nadalje pravimo samo
> high-level funkcije koje ce da se oslanjaju na ove low-level f-je, ali nece
> da zahtevaju njihovu modifikaciju
> >       ili sl.
> >
> >       Ono sto je glavni problem u celoj prici sa testiranjem je sto u
> velikom broju slucajeva ne postoje dobro-definisani testovi koje treba
> izvesti. Test snimaj-citaj-snimaj za
> >       I/O je jedan od retkih primera gde moze eksplicitno da se proveri
> da li sve radi kako treba. Za veliku vecinu stvari uopste ne umem da
> osmislim kako da formulisemo test,
> >       osim ovako kako smo dosad radili --- da za svaku f-ju ponaosob
> napravimo neki mini-primer upotrebe u main()-u, ispisemo output na stdout,
> i onda pogledamo da li taj output
> >       ima smisla.
> >
> >       Na primer, nacin na sam ja testirao f-je za seed-ovanje je sledeci:
> >
> >         (1) seed-ujes npr. sferu za D=3,
> >         (2) pozoves print_detailed() da ti ispise celu strukturu na
> ekran,
> >         (3) uzmes papir i olovku i nacrtas sve nodove, linije, trouglove
> i ostalo, pa proveris da li taj crtez odgovara matematickoj definiciji
> 3-sfere.
> >
> >       Jasno, za korak (3) ne postoji algoritam. Gui ce u nekom trenutku
> umeti da mi nacrta to, pa mi nece trebati papir i olovka, ali automatski
> test (koji bi dao output "radi/ne
> >       radi") ne vidim bas kako da napravimo. :-)
> >
> >       Sve u svemu, za sada "testiram" celu stvar tako sto eksplicitno
> citam kod, gledam da li algoritam radi ono sto ocekujem da radi, i da li
> ima nekih corner-case-ova na koje
> >       treba obratiti paznju. Ako imate bilo kakvu ideju za bilo sta
> inteligentnije, slobodno javljajte! ;-)
> >
> >       :-)
> >       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 Sat, 26 Nov 2022, Nenad Korolija wrote:
> >
> >       > Sve vise mislim da nam trebaju testovi, tako da se lako primeti
> ako neko polomi staru funkcionalnost (najcesce covek polomi svoju:)...
> >       >
> >       > On Sat, Nov 26, 2022 at 10:32 AM Marko Vojinovic <
> vmarko at ipb.ac.rs> wrote:
> >       >
> >       >       Hmm, mozda sam ovo kazao malo preuranjeno:
> >       >
> >       >       > Inace, koliko mogu da vidim i koliko smo Nenad i ja
> testirali kod, f-ja
> >       >       > add_neighbor() radi tacno ono sto bi trebalo da radi ---
> dodeljuje jedan
> >       >       > simpleks kao sused drugom, i obratno (jer je susedstvo
> simetricna relacija).
> >       >
> >       >       Tacno je da add_neighbor() radi upravo to, ali osim toga
> je i rekurzivno dodavala podsimplekse, a za to nisam bas skroz siguran da
> je radilo kako treba. Pa sam zato
> >       >       prepravio celu f-ju, izbacio rekurziju, i malo
> eksplicitnije organizovao algoritam za dodavanje podsuseda, tako da sada
> vise ne bi smelo da bude nikakvog
> >       nepredvidjenog
> >       >       ponasanja te f-je. Takodje sam dodao i proveru slucajeva
> kada su simpleksi jednaki i kada su istog nivoa, i f-ja sada prijavljuje
> eksplicitne greske u tim
> >       slucajevima.
> >       >
> >       >       Probaj dakle sada da reprodukujes taj famozni bag, da li
> se i dalje pojavljuje --- gledaj u output od print_detailed(), uporedjuj to
> sa snimljenim .xml fajlom iz
> >       koga citas
> >       >       kompleks, pa ako se i dalje nesto ne slaze, posalji mi oba
> fajla (i output od print_detailed() i .xml fajl) da pogledam u cemu je
> problem.
> >       >
> >       >       :-)
> >       >       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 Sat, 26 Nov 2022, Marko Vojinovic wrote:
> >       >
> >       >       >
> >       >       > Pozdrav Dusane,
> >       >       >
> >       >       > Hvala za popravke. :-)
> >       >       >
> >       >       > Za curenje memorije nemoj da brines za sada --- kad
> budemo zavrsili sa
> >       >       > konstrukcijom svih "elementarnih" funkcija (onih koje
> eksplicitno pozivaju
> >       >       > "new" ili "delete"), onda cemo Nenad i ja da uradimo
> jednu temeljnu proveru
> >       >       > svih curenja memorije i da sve zapusimo. Kad se to
> zavrsi, plan je da sve
> >       >       > naredne funkcije koje cemo pisati budu "izvedene" iz
> ovih elementarnih, i u
> >       >       > njima se nikad nista ne alocira "rucno", pa curenja
> memorije vise nece
> >       >       > biti...
> >       >       >
> >       >       > Za delimiter kapiram sta je i cemu ti sluzi, nego sam
> propustio da vidim
> >       >       > definiciju u .hpp fajlu. :-) Ali sam se vise zbunio oko
> toga kako kompajler
> >       >       > hoce da prihvati pozivanje f-je sa samo tri argumenta,
> ako je ona deklarisana
> >       >       > i definisana da ih bude cetiri... Ali ok, izgleda je C++
> tu fleksibilan,
> >       >       > dokle god je cetvrti parametar eksplicitno definisan u
> .hpp fajlu. To nisam
> >       >       > znao da moze.
> >       >       >
> >       >       > Switch/case struktura u colorize_node_from_string() se
> ni meni ne svidja, ali
> >       >       > neka je tako za sada --- radi nam posao, a momentalno
> imamo vaznije stvari da
> >       >       > resavamo, na to mozemo da se vratimo kasnije.
> >       >       >
> >       >       > Sto se tice baga sa UniqueID bojom, nemam nista protiv
> da to popravis
> >       >       > kasnije, samo nemoj da zaboravis --- naznaci u kodu u
> komentaru da to treba
> >       >       > da se popravi, i kako (stavi zakomentarenu ispravnu
> verziju koda, da posle ne
> >       >       > razmisljamo sta i kako treba da se uradi na tom mestu).
> >       >       >
> >       >       > A sto se tice ovog baga sa susedima i add_neighbor() na
> koji se zalis ---
> >       >       > onaj fajl output.txt koji si mi poslao je previse
> nepregledan, nista nisam
> >       >       > uspeo da vidim odatle. Pa sam zato sad implementirao f-ju
> >       >       >
> >       >       >   SimpComp::print_detailed()
> >       >       >
> >       >       > koja na lep i pregledan nacin ispisuje ceo simplicijalni
> kompleks, sa svim
> >       >       > detaljima, bojama i susedima svih simpleksa, tako da
> moze cela struktura lepo
> >       >       > da se vidi, procita i prekontrolise. Pa bi bilo dobro da
> git merge-ujes
> >       >       > najnoviji main branch u svoj 8_XML_reading branch, i
> onda mi posalji output
> >       >       > od print_detailed() kad reprodukujes bag, da mozemo lepo
> da vidimo sta se tu
> >       >       > tacno dogadja sa susedima.
> >       >       >
> >       >       > Inace, koliko mogu da vidim i koliko smo Nenad i ja
> testirali kod, f-ja
> >       >       > add_neighbor() radi tacno ono sto bi trebalo da radi ---
> dodeljuje jedan
> >       >       > simpleks kao sused drugom, i obratno (jer je susedstvo
> simetricna relacija).
> >       >       > E sad, ako joj trazis da stavi simpleks kao sused samom
> sebi, to je tvoj
> >       >       > problem, tj. add_neighbor() nije kriva za to. Mozda
> bismo mogli da unapredimo
> >       >       > add_neighbor() da proverava i prijavljuje gresku ako
> korisnik pokusava da
> >       >       > poveze simpleks sa samim sobom (ili sa drugim
> simpleksima istog nivoa), ali
> >       >       > to ce samo da maskira pravi problem koji se nalazi negde
> drugo --- ti
> >       >       > generalno nikad ne bi smeo da dodjes u situaciju da se
> simpleks povezuje kao
> >       >       > sused sa samim sobom, bez obzira da li ce add_neighbor()
> to pristati da ti
> >       >       > uradi ili ne.
> >       >       >
> >       >       > Ali 'ajde da vidimo tacno sta radi bag, pa cemo da
> utrejsujemo gde je zapravo
> >       >       > greska... ;-)
> >       >       >
> >       >       > I za kraj --- videh da si u triangulator.hpp dodao ovo:
> >       >       >
> >       >       >  class KSimplex;     // Had to do a predeclaration
> because is used in
> >       >       > get_color_from_str
> >       >       >
> >       >       > To je visak, obrisi to odatle. Ista ta
> forward-deklaracija se vec nalazi na
> >       >       > pocetku fajla color.hpp (odmah iza #ifndef - #endif
> strukture), i sigurno ne
> >       >       > treba da stoji u triangulator.hpp fajlu --- tu treba da
> stoje samo ostale
> >       >       > #include direktive. A forward-deklaracije mozes da
> stavljas u ostale .hpp
> >       >       > fajlove gde ti je potrebno, i *ako* ti je potrebno.
> Naime, redosled #include
> >       >       > direktiva u triangulator.hpp fajlu je tako namesten da
> smo vec pokrili sve
> >       >       > neophodne forward-deklaracije, ne vidim gde jos moze da
> ti zafali neka.
> >       >       >
> >       >       > Btw, nisam nasao f-ju get_color_from_str() nigde u tvom
> kodu, jel' to typo u
> >       >       > komentaru? Odnosno jesi mislio mozda na f-ju
> get_color_value_as_str(), iz
> >       >       > klase Color?
> >       >       >
> >       >       > :-)
> >       >       > 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, 24 Nov 2022, Dušan Cvijetić wrote:
> >       >       >
> >       >       >> Pozdrav,
> >       >       >>
> >       >       >> Ubacio sam komentare i doxygen dokumentaciju u svoj
> kod. Javite da li ste
> >       >       >> zadovoljni time, ili da menjam.
> >       >       >>
> >       >       >> Proverio sam curenja memorije pomoću Valgrind-a. Bilo
> ih je nekoliko u I/O
> >       >       >> delu, to bi trebalo da je sada sređeno. Postoji još
> curenja, ali čini mi se
> >       >       >> da su ona u klasi za boje, pa bi valjalo da još neko to
> pogleda i proveri,
> >       >       >> jer nisam mnogo radio sa Valgrind-om.
> >       >       >>
> >       >       >> Sad, kod:
> >       >       >>
> >       >       >> (1) Uklonjeno, bilo je višak.
> >       >       >>
> >       >       >> (2) "Nepostojeći" argument u oba slučaja je string koji
> predstavlja
> >       >       >> delimiter između elemenata niza, a u .hpp fajlu mu je
> zadata default
> >       >       >> vrednost ",". Napravio sam tako da bi funkcija bila
> fleksibilnija pri
> >       >       >> eventualnim kasnijim dodavanjima drugih formata. Dodao
> sam objašnjenje u
> >       >       >> komentar, pa bi trebalo da bude jasnije šta se dešava.
> >       >       >>
> >       >       >> (3) Slažem se, provera je suvišna i uklonio sam je.
> >       >       >>
> >       >       >> (4) Uradio po predlogu, ali svakako mislim da treba da
> nađemo rešenje koje
> >       >       >> izbegava switch u nekom momentu.
> >       >       >>
> >       >       >> Po pitanju (5) nisam ništa uradio. Postoji nepovezana
> greška koja se
> >       >       >> provlači još od prethodne verzije. Proverio sam da li
> problem 5 utiče na
> >       >       >> ovu grešku, i nema razlike ni kada unesem ispravku iz
> prethodnog mejla, pa
> >       >       >> sam ostavio za sad da bude kao i ranije, jer je
> preglednije šta se dešava.
> >       >       >>
> >       >       >> Već par sati pokušavam da provalim gde leži bag, ali mi
> se trenutno čini da
> >       >       >> nije u I/O kodu, već u funkciji add_neighbor(). Dodao
> sam u funkciju
> >       >       >> read_ksimplex_node() deo koji štampa izgled kompleksa
> nakon svakog
> >       >       >> dodavanja komšije nekom simpleksu, i izlaz koji sam
> dobio je u fajlu
> >       >       >> output.txt u prilogu. Da li add_neighbor() radi kako
> treba? Neki simpleksi
> >       >       >> su ovde dodati da sami sebi budu komšije, iako to nigde
> nisam eksplicitno
> >       >       >> tražio. Čini mi se da ova funkcija uvodi neku
> međuzavisnost kod komšija
> >       >       >> koja mi nije očekivana ni trivijalna.
> >       >       >>
> >       >       >> Može li još neko da pogleda ovaj problem?
> >       >       >>
> >       >       >> Pozdravi,
> >       >       >> Dušan
> >       >       >>
> >       >       >>
> >       >       >> On 20/11/2022 10:57, Marko Vojinovic wrote:
> >       >       >>>
> >       >       >>> Pozdrav Dusane,
> >       >       >>>
> >       >       >>> Evo pogledao sam I/O kod --- nisam ga jos testirao,
> ali ovako iz citanja i
> >       >       >>> pregledanja mogu da ti dam par komentara i saveta.
> >       >       >>>
> >       >       >>> Prvo, kod je super! :-) To sto je dugacak nema veze, i
> to sto treba
> >       >       >>> pocistiti detalje oko error-handling i memory leaks
> nije veliki problem.
> >       >       >>> Odlicno si uradio posao, svaka cast! ;-)
> >       >       >>>
> >       >       >>> Drugo, buduci da je kod relativno dugacak, bilo bi
> pametno da ubacis
> >       >       >>> komentare --- osnovnu ideju, bazicnu strukturu .xml
> fajla koji se
> >       >       >>> snima/ucitava, kao i cemu koji deo koda sluzi i sta
> radi, u glavnim
> >       >       >>> crtama. To je potrebno za slucaj da se kasnije vratimo
> na taj kod (bilo
> >       >       >>> ti, bilo neko drugi), da bi bilo jasno sta se dogadja
> i kojim redom.
> >       >       >>> Komentare bi bilo dobro da ubacis dok ti je cela stvar
> sveza u glavi, jer
> >       >       >>> posle nece ni tebi biti jasno sta si tu sve radio...
> ;-) Inace, i ja
> >       >       >>> planiram ovih dana da ubacim gooomilu komentara u ceo
> dosad napisani kod
> >       >       >>> projekta, da sve bude bolje i jasnije objasnjeno i
> dokumentovano.
> >       >       >>>
> >       >       >>> Trece, ima par sitnih detalja koje mozes malo da
> pocistis u kodu, u f-ji
> >       >       >>> read_complex_from_xml_file( rapidxml::xml_document<>&
> doc ):
> >       >       >>>
> >       >       >>>  (1) Negde na sredini f-je stoji "bool first = true;"
> pri cemu se
> >       >       >>> varijabla first nigde kasnije ne koristi.
> Pretpostavljam da je to visak?
> >       >       >>>
> >       >       >>>  (2) Pri kraju f-je u petlji pozivas dve f-je,
> >       >       >>>
> >       >       >>>     read_level_node(current_node, sc,
> >       >       >>> stoi(current_node->first_attribute()->value()));
> >       >       >>>     read_ksimplex_node(current_node, sc);
> >       >       >>>
> >       >       >>> koje imaju redom tri odnosno dva argumenta, a nize si
> te iste dve f-je
> >       >       >>> definisao kao
> >       >       >>>
> >       >       >>>     void read_level_node(rapidxml::xml_node<>* node,
> SimpComp* sc, int
> >       >       >>> level, string delimiter)
> >       >       >>>     void read_ksimplex_node(rapidxml::xml_node<>*
> node, SimpComp* sc,
> >       >       >>> string delimiter)
> >       >       >>>
> >       >       >>> tako da imaju cetiri odnosno tri argumenta. Taj
> dodatni nepostojeci
> >       >       >>> argument (string delimiter) se onda eksplicitno
> prosledjuje f-ji
> >       >       >>> parse_level(), koja ga koristi (na netrivijalan
> nacin). Nije mi jasno kako
> >       >       >>> ovo uopste hoce da se kompajlira (broj argumenata u
> f-jama se ne slaze), i
> >       >       >>> nije mi jasno gde je "delimiter" zapravo definisan?
> Ako je on neka
> >       >       >>> globalna varijabla unutar namespace rapidxml ili nesto
> tako, zasto ga onda
> >       >       >>> prosledjujes eksplicitno kao argument u parse_level(),
> a to isto ne radis
> >       >       >>> u read_level_node() i read_ksimplex_node()? Kako to
> sve zapravo radi?
> >       >       >>>
> >       >       >>>  (3) Na samom kraju f-je, u poslednjoj petlji, brises
> privremene UniqueID
> >       >       >>> boje. Nisam siguran da li ti treba provera "if
> (!ks->colors.empty())", jer
> >       >       >>> bi svaki simpleks trebalo da ima taj privremeni ID.
> Naime, kad si snimao
> >       >       >>> fajl, f-jom save_complex_to_xml_file(), odmah na
> pocetku si uradio
> >       >       >>>
> >       >       >>>     UniqueIDColor::colorize_entire_complex(simpComp);
> >       >       >>>
> >       >       >>> sto je obojilo bukvalno sve simplekse. Kada posle radis
> >       >       >>> read_complex_from_xml_file(), ti zapravo citas bas te
> brojeve (privremene
> >       >       >>> id-jeve), i struktura snimljenog fajla bi trebalo da
> ti garantuje da svaki
> >       >       >>> simpleks u novokreiranom kompleksu sigurno ima makar
> tu boju, ako nista
> >       >       >>> drugo. Pa zato ne vidim da li postoji situacija kada
> uslov "if
> >       >       >>> (!ks->colors.empty())" nije zadovoljen?
> >       >       >>>
> >       >       >>> Cetvrta tema --- pitanje sta uciniti sa f-jom
> colorize_node(). Moj predlog
> >       >       >>> je sledeci. Prvo, po nekoj ideji dizajna, f-je za I/O
> treba da budu
> >       >       >>> agnostic o tipovima i vrednostima boja, i slicnim
> detaljima --- krajnji
> >       >       >>> korisnik ce mozda zeleti da definise svoje custom
> boje, i da ih snima i
> >       >       >>> cita iz fajlova, ali mi sigurno ne zelimo da krajnji
> korisnik ceprka po
> >       >       >>> kodu I/O f-ja da bi mu to radilo. Za snimanje u fajl
> imamo lepo resenje
> >       >       >>> --- svaka boja u klasi Color ima definisanu f-ju
> get_color_value_as_str(),
> >       >       >>> i ti to koristis kada snimas boju u fajl, tako da te
> uopste ne zanima kako
> >       >       >>> je definisana vrednost boje (to je prosto neki string
> koji ces da snimis).
> >       >       >>>
> >       >       >>> Istu filozofiju treba primeniti i u slucaju citanja iz
> fajla, na sledeci
> >       >       >>> nacin --- prepravi f-ju colorize_node() tako da bude
> prosto wrapper f-ja
> >       >       >>> koja ce da poziva novu f-ju,
> >       >       >>>
> >       >       >>>   void Color::colorize_node_from_string( KSimplex* ks,
> int color_type,
> >       >       >>> string color_value );
> >       >       >>>
> >       >       >>> i samo toj f-ji prosledi pointer ks i parametre
> >       >       >>>
> >       >       >>>   int color_type =
> stoi(color_node->first_attribute()->value());
> >       >       >>>   string color_value = color_node->value();
> >       >       >>>
> >       >       >>> pa ce posao te f-je da bude da oboji simpleks kako
> treba, a ti samo
> >       >       >>> zavrsis colorize_node() f-ju. Pritom, celu switch/case
> strukturu preseli u
> >       >       >>> tu novu f-ju --- ona ce da zivi u klasi Color (prebaci
> je u color.cpp i
> >       >       >>> color.hpp fajlove), i nju ce krajnji korisnik moci da
> azurira kada/ako
> >       >       >>> bude dodavao svoje custom boje.
> >       >       >>>
> >       >       >>> Ovakvim wrapper-zahvatom postizemo dve stvari: (a)
> dodavanje novih boja
> >       >       >>> vise nema direktne veze sa I/O f-jama, nego se vrsi
> samo modifikovanjem
> >       >       >>> f-ja u klasi Color, i (b) kasnije cemo mozda
> switch/case strukturu da
> >       >       >>> zamenimo necim inteligentnijim, mozda za svaku boju da
> zahtevamo da ima
> >       >       >>> definisanu f-ju set_color_value_from_str(), poput ove
> koju si uveo za
> >       >       >>> ScreenCoordinateColor, itdisl. Generalno, to sve dalje
> vise nije tvoj
> >       >       >>> problem (za I/O f-je), a klasu Color cemo verovatno
> jos dosta da
> >       >       >>> (re)dizajniramo i doterujemo kasnije (bilo ti, bilo
> neko drugi, bilo
> >       >       >>> krajnji korisnik, o tom potom)...
> >       >       >>>
> >       >       >>> Mislim da bi ovakav dizajn bio generalno mudriji, pa
> vidi da tako
> >       >       >>> reorganizujes taj kod.
> >       >       >>>
> >       >       >>> I konacno, peta tema --- cini mi se da sam pronasao i
> jedan mali bag.
> >       >       >>> Naime, u switch/case strukturi unutar colorize_node()
> imas izmedju ostalog
> >       >       >>> i sledeci kod:
> >       >       >>>
> >       >       >>>    case TYPE_UNIQUE_ID:
> >       >       >>>         color = new
> UniqueIDColor(stoi(color_node->value()));
> >       >       >>>
> ks->colors.push_back(static_cast<UniqueIDColor*>(color));
> >       >       >>>         break;
> >       >       >>>
> >       >       >>> koji se izvrsava ako je snimljeni kompleks imao neke
> simplekse obojene
> >       >       >>> UniqueID bojama. Kada u nekoj kasnijoj sesiji (neki
> drugi main(), tj.
> >       >       >>> drugi program) ucitavas taj fajl i konstruises novi
> kompleks, moze da se
> >       >       >>> desi da su te snimljene UniqueID boje (iz fajla) vec
> iskoriscene za neki
> >       >       >>> drugi kompleks (seed-ovan ranije u ovoj novoj sesiji),
> sto vodi do
> >       >       >>> dupliranja UniqueID boja, sto ne sme da nam se dogodi.
> :-)
> >       >       >>>
> >       >       >>> Ovo dakle mora da se popravi, tako sto se dati
> simpleks ne oboji UniqueID
> >       >       >>> bojom koja je procitana iz fajla, nego mu se dodeli
> prvi slobodan UniqueID
> >       >       >>> iz tekuce sesije, ovako:
> >       >       >>>
> >       >       >>>    case TYPE_UNIQUE_ID:
> >       >       >>>         ks->colors.push_back(new UniqueIDColor());
> >       >       >>>         break;
> >       >       >>>
> >       >       >>> Jasno, tada vrednosti id-jeva za kompleks vise nece da
> se poklapaju sa
> >       >       >>> id-jevima koji pisu u fajlu. Ali to sto se ne
> poklapaju niti moze da se
> >       >       >>> garantuje, niti je vazno --- vazno je samo da su
> jedinstveni, tj. da nema
> >       >       >>> preklapanja ni sa jednim drugim simpleksom koji je
> trenutno u memoriji.
> >       >       >>> Tako da obavezno popravi i taj detalj. ;-)
> >       >       >>>
> >       >       >>> :-)
> >       >       >>> 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 Sat, 19 Nov 2022, Dušan Cvijetić wrote:
> >       >       >>>
> >       >       >>>>
> >       >       >>>> Pozdrav,
> >       >       >>>>
> >       >       >>>> Dovršio sam kod za ispis u fajl. Ostalo mi je da ga
> iskomentarišem i
> >       >       >>>> ozbiljnije istestiram. Na prvi pogled se čini da
> radi, i da je i redosled
> >       >       >>>> svih stavki očuvan.
> >       >       >>>>
> >       >       >>>> Planiram, takođe, još malo da ulepšam I/O funkcije,
> trenutno su mahom
> >       >       >>>> ogromne i ružne. Ostalo mi je par nedoumica oko nekih
> rešenja, koja sam
> >       >       >>>> označio u komentarima sa // NOTE: ili //
> >       >       >>>> TODO:. Uglavnom se tiču izuzetaka, ili rada u okviru
> postojeće
> >       >       >>>> arhitekture (konkretno, čitanje različitih boja sam
> rešio putem case
> >       >       >>>> strukture, što možda nije najsrećnije, ali mi ništa
> >       >       >>>> drugo nije palo na pamet).
> >       >       >>>>
> >       >       >>>> Pre nego što nastavim sa testiranjem, imam još jedan
> predlog: nedavno sam
> >       >       >>>> počeo da učim cmake, pa bih voleo da pokušam da
> napravim cmake za naš
> >       >       >>>> projekat, ako se slažete. Tako bismo
> >       >       >>>> mogli bolje da organizujemo testove i kompajliranje.
> >       >       >>>>
> >       >       >>>> Pozdravi,
> >       >       >>>> Dušan
> >       >       >>>>
> >       >       >>>> On 10/11/2022 11:55, Nenad Korolija wrote:
> >       >       >>>>       Zdravo Marko,
> >       >       >>>>
> >       >       >>>> Ni ja se nisam dalje bavio triangulatorom, ali sam
> bar završio i
> >       >       >>>> poslednje repove sa Amerikancima i valjda skoro sve
> oko papirologije za
> >       >       >>>> reizbor (tu je bilo komplikacija, ali će
> >       >       >>>> valjda sve proći u redu:).
> >       >       >>>> Ako ćeš imati vremena da baciš pogled na moje đubre,
> možda možemo i da
> >       >       >>>> budemo na vezi, pa da mi odmah kažeš šta da menjam
> (umesto da kucaš
> >       >       >>>> email), pa da nastaviš gledanje kad
> >       >       >>>> promenim...
> >       >       >>>>
> >       >       >>>> Vidimo se,
> >       >       >>>> Nenad
> >       >       >>>>
> >       >       >>>> On Thu, Nov 10, 2022 at 11:52 AM Nenad Korolija <
> nenadko at gmail.com>
> >       >       >>>> wrote:
> >       >       >>>>       Zdravo Dušane,
> >       >       >>>>
> >       >       >>>> Koliko vidim, snimanje simplicijalnog kompleksa radiš
> redom.
> >       >       >>>> for (unsigned int lvl = 0; lvl <
> simpComp->elements.size(); lvl++) {
> >       >       >>>>         for (auto ks : simpComp->elements[lvl]) {
> >       >       >>>> Dakle, verovatno je redosled snimanja i učitavanja
> isti, tj. nema potrebe
> >       >       >>>> da sortiraš po ID-u ili šta već.
> >       >       >>>> Dakle, trebalo bi da Markov predlog dobro testira
> snimanje i učitavanje -
> >       >       >>>> poređenje snimljenog sa onim što si nakon toga učitao
> pa snimio.
> >       >       >>>>
> >       >       >>>> Vidimo se,
> >       >       >>>> Nenad
> >       >       >>>>
> >       >       >>>> On Wed, Nov 9, 2022 at 10:52 PM Marko Vojinovic <
> vmarko at ipb.ac.rs> wrote:
> >       >       >>>>
> >       >       >>>>       Pozdrav Dusane i Nenade,
> >       >       >>>>
> >       >       >>>>       Evo konacno sam se vratio u Srbiju i uspeo malo
> da se organizujem.
> >       >       >>>> Dosad se nisam odazivao jer sam bio bas pretrpan
> obavezama, nisam stizao
> >       >       >>>> da pogledam sta ste
> >       >       >>>>       radili... :-( Ali nadalje cu biti malo bolji sa
> odgovaranjem na
> >       >       >>>> mail-ove. ;-)
> >       >       >>>>
> >       >       >>>>       Dusane, vidim da si poceo da radis na citanju
> kompleksa iz fajla, i
> >       >       >>>> otprilike sam bacio pogled na ono sto si stavio u
> svoj branch dosad.
> >       >       >>>> Nisam testirao, ali
> >       >       >>>>       pretpostavljam da radi, tj. da ispisuje na
> ekran ono sto procita?
> >       >       >>>> :-) Sto se tice posebne klase za I/O, svakako je
> napravi ako mislis da je
> >       >       >>>> potrebna, i Nenad i
> >       >       >>>>       ja se slazemo. Javi dokle si stigao i kako ide.
> >       >       >>>>
> >       >       >>>>       Btw, fundamentalni test za I/O moze da ide
> otprilike ovako:
> >       >       >>>>
> >       >       >>>>       (1) seed-ujes neki kompleks SimpComp *G1 (npr.
> 5-sferu ili stagod),
> >       >       >>>>
> >       >       >>>>       (2) snimis G1 u fajl-prvi.xml f-jom za snimanje
> (koju si napravio),
> >       >       >>>>
> >       >       >>>>       (3) ucitas fajl-prvi.xml u novi kompleks
> SimpComp *G2, f-jom za
> >       >       >>>> citanje (koju sad pravis),
> >       >       >>>>
> >       >       >>>>       (4) snimis G2 u fajl-drugi.xml f-jom za
> snimanje,
> >       >       >>>>
> >       >       >>>>       (5) uporedis fajl-prvi.xml i fajl-drugi.xml
> (npr. diff-om ili cime
> >       >       >>>> god).
> >       >       >>>>
> >       >       >>>>       Ako su dva fajla uglavnom identicna (do na
> vrednosti UniqueID
> >       >       >>>> brojeva i eventualne izmene u redosledu zapisivanja
> isl), test je prosao,
> >       >       >>>> i zadatak je resen. ;-)
> >       >       >>>>
> >       >       >>>>       Osim toga, ako bi uspeo jos da namestis obe
> f-je (za citanje i
> >       >       >>>> snimanje) tako da cak i redosled kojim su stavke
> zapisane u dva fajla
> >       >       >>>> bude isti, tj. da fajlovi
> >       >       >>>>       budu potpuno identicni (do na UniqueID-ove), to
> bi onda bila bas
> >       >       >>>> prava stvar. :-) Ali to nije obavezno --- redosled
> stavki u fajlovima u
> >       >       >>>> principu nije bitan,
> >       >       >>>>       dokle god mozemo pouzdano da se ubedimo da
> fajlovi zaista sadrze
> >       >       >>>> iste podatke.
> >       >       >>>>
> >       >       >>>>       :-)
> >       >       >>>>       Marko
> >       >       >>>>
> >       >       >>>>       P.S. Drago mi je da si se lepo proveo u CERN-u,
> i da postoji
> >       >       >>>> mogucnost da ides opet, svakako iskoristi priliku ako
> ti se ukaze...
> >       >       >>>>
> >       >       >>>>
> >       >       >>>>       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 Mon, 7 Nov 2022, Nenad Korolija wrote:
> >       >       >>>>
> >       >       >>>>       > Zdravo Dušane,
> >       >       >>>>       >
> >       >       >>>>       > Ja se slažem. Ima smisla izdvojiti celu I/O
> funkcionalnost u
> >       >       >>>> posebnu klasu, tj. fajl.
> >       >       >>>>       >
> >       >       >>>>       > Pozdrav,
> >       >       >>>>       > Nenad
> >       >       >>>>       >
> >       >       >>>>       > On Sun, Nov 6, 2022 at 5:16 PM Dušan Cvijetić
> >       >       >>>> <dusancvijetic2000 at gmail.com> wrote:
> >       >       >>>>       >       Pozdrav,
> >       >       >>>>       >
> >       >       >>>>       >       Predlažem da se za I/O funkcionalnosti
> napravi nova klasa,
> >       >       >>>> pošto
> >       >       >>>>       >       trenutno radim na čitanju kompleksa iz
> fajla i imam mnogo
> >       >       >>>> pomoćnih
> >       >       >>>>       >       funkcija koje sam napravio, a koje
> trenutno plutaju u etru,
> >       >       >>>> pa bi bilo
> >       >       >>>>       >       lepše grupisati ih.
> >       >       >>>>       >
> >       >       >>>>       >       Pozdravi,
> >       >       >>>>       >       Dušan
> >       >       >>>>       >
> >       >       >>>>       >       On 30/10/2022 19:58, Dušan Cvijetić
> wrote:
> >       >       >>>>       >       > Pozdrav,
> >       >       >>>>       >       >
> >       >       >>>>       >       > Radim na čitanju iz fajla, pošto sam
> konačno prešao na
> >       >       >>>> Ubuntu.
> >       >       >>>>       >       >
> >       >       >>>>       >       > Da li treba sada da razmišljam i o
> hvatanju izuzetaka,
> >       >       >>>> ili je to tema
> >       >       >>>>       >       > kojoj ćemo kasnije da se posvetimo?
> >       >       >>>>       >       >
> >       >       >>>>       >       > Pozdravi,
> >       >       >>>>       >       > Dušan
> >       >       >>>>       >       >
> >       >       >>>>       >       > On 07/03/2022 06:00, Marko Vojinovic
> wrote:
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> Vazi. :-)
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> Sto se citanja iz fajla tice, obrati
> samo paznju kako
> >       >       >>>> ces da
> >       >       >>>>       >       >> instanciras UniqueID boje ---
> moraces "rucno" da im
> >       >       >>>> menjas vrednosti
> >       >       >>>>       >       >> na osnovu onoga sto procitas iz .xml
> fajla, jer
> >       >       >>>> konstruktor
> >       >       >>>>       >       >> UniqueIDColor::UniqueIDColor()
> zadaje te id-jeve
> >       >       >>>> automatski.
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> Takodje, kad sve zavrsis, treba da
> setujes vrednost za
> >       >       >>>>       >       >> UniqueIDColor::next_free_uid_number
> na ono sto bi
> >       >       >>>> trebalo da bude
> >       >       >>>>       >       >> prvi slobodan id broj. To je valjda
> id vrednost prvog
> >       >       >>>> simpleksa u
> >       >       >>>>       >       >> fajlu, jer su oni u fajlu poredjani
> rastucim redom, a ti
> >       >       >>>> id-jevi iz
> >       >       >>>>       >       >> fajla ne treba da postoje u konacnoj
> strukturi u
> >       >       >>>> memoriji, pa bi prvi
> >       >       >>>>       >       >> od njih trebalo da bude "slobodan"
> na samom kraju...
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> Jedino nisam siguran kako ce
> next_free_uid_number da
> >       >       >>>> funkcionise u
> >       >       >>>>       >       >> kontekstu veceg broja istovremeno
> instanciranih
> >       >       >>>> kompleksa, ali to je
> >       >       >>>>       >       >> pitanje dizajna o kome moram jos da
> razmislim.
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> Ostatak algoritma osmisli sam, kako
> mislis da je
> >       >       >>>> najzgodnije.
> >       >       >>>>       >       >>
> >       >       >>>>       >       >> :-)
> >       >       >>>>       >       >> 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 Mon, 7 Mar 2022, Dusan Cvijetic
> wrote:
> >       >       >>>>       >       >>
> >       >       >>>>       >       >>> Pozdrav,
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>> S obzirom da sam radio ispis u .xml
> fajl, preuzeću i
> >       >       >>>> učitavanje
> >       >       >>>>       >       >>> kompleksa iz fajla.
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>> Pozdravi,
> >       >       >>>>       >       >>> Dušan
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>> пет, 11. феб 2022. у 23:17 Marko
> Vojinovic
> >       >       >>>> <vmarko at ipb.ac.rs> је
> >       >       >>>>       >       >>> написао/ла:
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>       Implementirati metod u klasi
> SimpComp koji ce da
> >       >       >>>> procita dati
> >       >       >>>>       >       >>> fajl i instancira u memoriji
> simplicijalni kompleks na
> >       >       >>>> osnovu
> >       >       >>>>       >       >>> podataka iz fajla:
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>          SimpComp*
> SimpComp::read_complex_from_file(
> >       >       >>>> file* f );
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>          Input: Pointer na fajl iz
> koga se citaju
> >       >       >>>> podaci.
> >       >       >>>>       >       >>>          Output: pointer na
> instancirani simplicijalni
> >       >       >>>> kompleks
> >       >       >>>>       >       >>> kreiran na osnovu podataka iz fajla.
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>       Ovaj zadatak treba da
> instancira nov prazan
> >       >       >>>> kompleks, zatim da
> >       >       >>>>       >       >>> cita dati fajl, interpretira
> sintaksu iz zadatka 7, i
> >       >       >>>> da na osnovu
> >       >       >>>>       >       >>> tih podataka popuni kompleks
> odgovarajucim
> >       >       >>>>       >       >>>       simpleksima datih nivoa, a
> zatim i boje i susede
> >       >       >>>> svakog
> >       >       >>>>       >       >>> simpleksa ponaosob. Ovo je u
> sustini inverzni algoritam
> >       >       >>>> u odnosu na
> >       >       >>>>       >       >>> zadatak 7, i zavisi od tacne
> implementacije tog
> >       >       >>>>       >       >>>       zadatka (tj. od tacne
> sintakse snimljenog fajla),
> >       >       >>>> pa ovaj
> >       >       >>>>       >       >>> zadatak treba raditi tek kada
> budemo sigurni da smo
> >       >       >>>> skroz zadovoljni
> >       >       >>>>       >       >>> sa radom f-ja za snimanje u fajl.
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>       I u ovom slucaju cemo mozda
> uraditi vise verzija
> >       >       >>>> f-je za
> >       >       >>>>       >       >>> citanje, po jednu za svaki format
> fajla.
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>
> >       >       >>>>       >       >>>       :-)
> >       >       >>>>       >       >>>       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
> >
> >
> >--
> 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/20221128/7af720d5/attachment-0001.htm>


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