[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla
Nenad Korolija
nenadko at gmail.com
Sat Nov 26 13:53:56 CET 2022
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20221126/5aa024e8/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list