[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla
Dušan Cvijetić
dusancvijetic2000 at gmail.com
Sun Nov 27 19:42:46 CET 2022
Pozdrav,
Vidim sad da sam slučajno poslao prethodni mejl samo profesoru Koroliji,
pa ponavljam isti tekst ispod, ovaj put za celu listu.
>>>>>>>>>> ORIGINALNI TEKST <<<<<<<<<<
Nova verzija add_neighbor() rešava onaj bag koji sam imao, sada su .xml
fajlovi koje proizvodi identični, tako da ću da napravim pull request.
Planirao sam još neke testove da napravim, ali to ću ostaviti za nakon
što sredim cmake, jer ćemo onda imati sistematski način da ih dodajemo.
Pozdravi,
Dušan
On 26/11/2022 13:53, 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 <http://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 <http://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 <http://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
> <http://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
> <http://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
> <http://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/20221127/eba90372/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list