On Fri, Feb 25, 2022 at 2:31 AM Marko Vojinovic <vmarko@ipb.ac.rs> wrote:

Evo pregledao sam izmene i testirao sva tri slucaja stampanja --- slucajevi "vAll and sAll" i "vAll and not sAll" rade ok, ali slucaj "not vAll" ispisuje po jedan simpleks manje na svakom nivou (preskoci prvi). Nasao sam i sta treba popraviti: u petlji u liniji 254 samo krenes od i=0 umesto od i=1, i onda ce i "not vAll" slucaj da proradi kako treba:

(l.254) for(size_t i = 1; i < elements[k].size(); i++){

Sto se tice f-ja koje si dodao, sve su ok i slazem se da su zgodne. Uslov "level > D" je tacan.

Nego imam dve sugestije oko generalnog dizajna celog koda za print_compact f-je...

Prva sugestija je da nije zgodno da imas dva nezavisna koda za ispisivanje verteksa u zagradama, (5-6-7). Jedan kod se nalazi u KSimplex::print_compact(), a drugi u SimpComp::print_compact(). Mislim da bi ceo kod mogao znacajno da se pojednostavi ako bi napravio zasebnu f-ju

KSimplex::print_vertices_in_parentheses()

koja bi ispisivala te zagrade ako su svi verteksi datog k-simpleksa obojeni, odnosno prazan string ako nisu. Tada bi obe gornje print_compact() f-je bile drasticno lakse.

Druga sugestija je vezana za to da cemo kasnije pisati druge KSimplex::print_nekako() f-je, po ugledu na KSimplex::print_compact(), pa bi bilo dobro da ona bude implementirana "modularno". Primera radi, kasnije cemo za potrebe GUI-ja mozda da napravimo f-ju KSimplex::print_hyperlink(), koja bi umesto "17 (2-3-4)" ispisivala recimo nesto ovako:

17 <a href="simplex-id-17.html">(2-3-4)</a>

ili slicno. Ne znam unapred kakve sve sintakse ispisivanja ce nam trebati u buducnosti, ali za svaku sintaksu cemo imati odgovarajucu KSimplex::print_nekako() f-ju. Pa bi bilo dobro da tvoja KSimplex::print_compact() f-ja budu napisana "studentima za ugled", da posle student moze lako da je razume, da je copy-paste-uje, preimenuje, i minimalno izmeni, i da time dobije novu KSimplex::print_nekako() f-ju koja ispisuje ono sto njemu treba.

Jedan znacajan element tog dizajna je da te kasnije f-je mozda nece da stampaju uvek na stdout (nego potencijalno u fajl ili negde drugo), pa je verovatno zgodno da odvojis u zasebnu f-ju postupak konstrukcije stringa koji treba stampati, a onda iz KSimplex::print_compact() samo pozoves tu f-ju da ti konstruise string, i zatim ga odstampas na stdout.

Ili tako nekako... Razmisljaj na sledeci nacin --- zamisli da cu kroz godinu dana traziti *tebi* da napravis jedno 5-6 novih print_nekako() f-ja, koje ce da ispisuju stvari razlicito i na razlicita mesta. Osmisli dizajn za KSimplex::print_compact() tako da za oko godinu-dve (kad zaboravis detalje sta i kako u njoj radi) mozes lako da realizujes tih 5-6 drugih. ;-)

Malo mi je glupo da te gnjavim sa ovako trivijalnom temom (ispisivanje brojeva na ekran), ali dizajn tih f-ja ce nam stvarno biti znacajan za kasnije, pa ako ga sad na pocetku uradimo kako treba, kasnije nece da nas boli glava... :-)

:-)
Marko

Dr. Marko Vojinovic
Group for Gravitation, Particles and Fields
Institute of Physics
University of Belgrade
======================
home page: www.markovojinovic.com
e-mail: vmarko@ipb.ac.rs

On Thu, 24 Feb 2022, Nenad Korolija wrote:

> Modifikovao, ali ti je jasno da nemam pojma zasto ti to treba. :)
> U skladu sa mojim nagadjanjima, napravio sam funkcije koje bi mogle da nam olaksaju zivot tipa:
> - nadji prvu uniqueID boju i
> - nadji sve vertekse.
>
> Mozes da pogledas sve izmene i testiras kopiranjem poslednjih linija main-a i jednostavnim komentarisanjem i menjanjem broja u zagradi:
> UniqueIDColor::colorize_simplices_at_level(tetrahedron, 0);
> UniqueIDColor::colorize_entire_complex(tetrahedron);
>
> Nadam se da sa > D nisam omanuo uslov:
> bool SimpComp::all_uniqueID(int level){
> size_t i = 0;
> if(level > D)
> return false;
>
> Pozdrav,
> Nenad
>
> On Wed, Feb 23, 2022 at 5:54 AM Marko Vojinovic <vmarko@ipb.ac.rs> wrote:
>
> Da, ovakvo ispisivanje sa & u compact_print nije zgodno. Uradi ovako --- za svaki simpleks, pronadji prvu instancu UniqueID boje i ispisi uvek samo nju, a ostale instance
> ignorisi (ako postoje). To je najjednostavnija varijanta, i dovoljna je za nase potrebe.
>
> Takodje, ako vec sredjujes print_compact, mozes da namestis i sledecu logiku ispisivanja (smislio sam pre neki dan precizna pravila):
>
>    * Prvo proveri da li su verteksi (k=0) obojeni svi (v=all), ili ima nekih koji nisu obojeni (v=notall).
>    * Zatim proveri da li su ostali simpleksi (k>0) obojeni svi (s=all), ili ima nekih koji nisu obojeni (s=notall).
>
> Kad to saznas, onda ih ispisuj ovako:
>
>    * Ako je v=all i s=all --- ispisi standardno prvo boje svih verteksa: 1, 2, 3,..., pa zatim za ostale simplekse njihove boje i u zagradama boje njihovih verteksa. Sve
> sortiraj. Primer: 14 (2-4-8), 15 (3-5-9), ...
>    * Ako je v=all i s=notall --- ispisi boje svih verteksa: 1, 2, 3,..., pa zatim za ostale simplekse samo boje njihovih verteksa u zagradama, sortirane: (2-4-8), (3-5-9),
> ...
>    * Ako je v=notall i (s=all ili s=notall) --- i za vertekse i za ostale simplekse samo napisi boju ako je ima, odnosno rec "Simplex" ako je nema, bez zagrada i bez
> sortiranja: 8, 4, Simplex, 15, ...
>
> Ova pravila pokrivaju sve slucajeve. Naravno, u svemu ovome gore razvrstavas ispisivanje po nivoima, za svako k jedan zaseban red, kao i dosad sto je bilo.
>
> U main.cpp testiraj prvi slucaj tako sto obojis ceo tetraedar, drugi slucaj tako sto obojis k=0 level za tetraedar, a treci tako sto obojis recimo k=2 level za tetraedar,
> Dusanovim f-jama. Naravno, instanciraj tri nezavisna tetraedra za ovo, da mozes sve odjednom da testiras.
>
> Btw, smisao ovih pravila: prva dva slucaja (v=all) su regularna i verovatno ce se cesto pojavljivati u praksi, dok treci slucaj (v=notall) nije regularan i signalizira da je
> korisnik nesto negde zabrljao sa bojama (ispisivanjem reci "Simplex" bar na nekom mestu). ;-)
>
> :-)
> Marko
>
>
> Dr. Marko Vojinovic
> Group for Gravitation, Particles and Fields
> Institute of Physics
> University of Belgrade
> ======================
> home page: www.markovojinovic.com
> e-mail: vmarko@ipb.ac.rs
>
>
>
> On Wed, 23 Feb 2022, Nenad Korolija wrote:
>
> > Marko, planirao sam sortiranje UniqueID boja i ispisivanje redom. To se kosi sa potrebama. Kakvo ispisivanje zelis u slucaju ivice sa 4&7 izmedju verteksa sa 8&9 i 10&11,
> > 4&7 (8&9-10&11)?
> >
> > On Tue, Feb 22, 2022 at 11:23 PM Nenad Korolija <nenadko@gmail.com> wrote:
> > Sa svim se slazem...
> > Marko, druge funkcije color.cpp su ispale 0-3 linije koda, ali bih rado ubio colorize_simplices_at_level, ako sama po sebi nema svrhu, iako Dušanove imaju po 4 linije. :)
> > Vidim da si ti kreirao naziv funkcija koje sam komentarisao. Ako stari nazivi imaju neku interpretaciju koju ne vidimo, javi da vratimo.
> >
> > On Tue, Feb 22, 2022 at 9:52 PM Dusan Cvijetic <dusancvijetic2000@gmail.com> wrote:
> > Da, nisam u prošlom mejlu napisao, kada je dozvoljeno da simpleks ima više UniqueIDColor objekata, štampanje pobrljavi. Boje simpleksa se štampaju spojeno, a pošto
> pri
> > štampanju samo prolazi kroz skup svih UniqueIDColor-a, ukoliko, recimo, želimo da štampamo ivicu, kada tačke imaju po dva UniqueIDColor objekta, ištampaće ivice kao
> da
> > imaju četiri suseda. Recimo, ukoliko verteksi v1 i v2 imaju UniqueIDColor boje 1, 5 i 2, 6, redom (tako je trenutno u main.cpp fajlu), ivicu 9 koja je između njih
> > štampa kao Simplices k = 1: 9 (1-2-5-6), pri čemu vertekse štampa kao 15 i 26. Nisam siguran je li nameravano da se funkcija za štampanje ovako ponaša, pa samo da
> > napomenem.
> >
> > уто, 22. феб 2022. у 21:45 Dusan Cvijetic <dusancvijetic2000@gmail.com> је написао/ла:
> > Pozdrav,
> >
> > nemoj da proveravas da li simpleks vec ima UniqueID boju
> >
> > Prepravio i pushovao, proverite je li sad u redu.
> >
> > samo bi mozda imalo smisla staviti forward deklaracije u color.hpp a ne direktno u triangulator.hpp.
> >
> > Premešteno.
> >
> > Nase klase su samo malo komplikovaniji slucaj istog tog koncepta --- unakrsno referenciraju jedna drugu u svojim definicijama.
> >
> > Imao sam, pre oko godinu dana, problem s ovim u svom kodu i nisam znao kako da ga rešim, pa sam reorganizovao klase. Sad mi je interesantan ovaj način rešavanja
> > unakrsne rekurzije, ne bi mi palo na pamet jer smo na fakultetu učili jedan šablon, koji je predstavljen kao Sveto Pismo, pa nisam nikad od njega divergirao.
> >
> > Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako:
> >
> > Trebalo bi da moj deo koda sad prati ove konvencije, ostalo nisam hteo da diram, ali mogu kroz sve da prođem, ako želite.
> >
> > neka zasad f-je uvek vracaju samo true
> >
> > Prepravljeno.
> >
> > Pozdravi,
> > Dušan
> >
> >
> >
> > уто, 22. феб 2022. у 17:54 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> >
> > Evo da vam odgovorim obojici odjednom... :-)
> >
> > Dusane, odlicno si ovo uradio, svidja mi se, samo cu da te zamolim za jednu sustinsku izmenu --- nemoj da proveravas da li simpleks vec ima UniqueID boju.
> > Obe f-je treba prosto da dodaju
> > *nove* boje, cak i ako su simpleksi vec bili obojeni sa UniqueID. Ne zelimo da dopunjavamo kompleks bojama, nego da ga obojimo "jos jednom", da se tako
> > izrazim. Inace, ne postoji nikakav problem da isti simpleks nosi dve UniqueID boje (obrnuto naravno ne sme), u zadatku 7 se cak oslanjamo na to.
> >
> > Sto se tice konkretnih pitanja, ovako:
> >
> > > Tek kada sam izvršio commit sam se setio da poruke treba da pišem na engleskom
> >
> > Nije problem, samo pazi na to ubuduce --- neko ko ne zna srpski ce mozda pozeleti da gleda GitHub, zato je sve na engleskom. Btw, budite srecni sto vas ne
> > teram da i komunikacija na mailing listi bude na engleskom. :-D
> >
> > > Color traži da budu već deklarisani SimpComp i KSimplex, a KSimplex traži da već bude deklarisan Color, a SimpComp traži KSimplex: Color > SimpComp >
> > KSimplex > Color. Naterao sam
> > > ga da radi dodavši forward deklaracije za KSimplex i SimpComp u triangulator.hpp, ali ne mislim da je to dobro rešenje.
> >
> > Naprotiv, forward deklaracije su upravo ono sto nam treba. :-) Te tri klase su ukrstene by design --- jer to tacno odgovara matematickim strukturama sa
> > kojima radimo. U tom kontekstu, bilo kakvo uvodjenje nekih dodatnih klasa da se to "popravi" bi bilo skroz vestacko i nepotrebno. Znaci dobro si uradio,
> > samo bi mozda imalo smisla staviti forward deklaracije u color.hpp a ne direktno u triangulator.hpp.
> >
> > > Trenutno mi deluje neprijatno da polje klase namešta samo sebe
> >
> > Sigurno si vec naviknut na koncept dinamicke liste --- nju kreiras strukturom koja u svojoj definiciji referencira samu sebe. Nase klase su samo malo
> > komplikovaniji slucaj istog tog koncepta --- unakrsno referenciraju jedna drugu u svojim definicijama. Unakrsnu rekurziju [1] si sigurno video u
> > algoritmima (npr. rekurzivni spust), jedino mozda nisi navikao da pravis klase na istu foru. ;-)
> >
> > > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo pisati.
> >
> > Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako: imena funkcija su under_scored, imena klasa su CamelCase, imena promenljivih su camelCase, a
> > imena konstanti su UNDER_SCORED_CAPS. Bice zabavno. ;-) Inace, sto se tice generalnih konvencija kucanja koda, ponekad se trazi i word-wrap na 79-toj
> > koloni, ali mene to strasno nervira na velikom monitoru pa se ja prvi necu pridrzavati toga, niti cu vas da teram. ;-)
> >
> > > nije naznačeno šta označava bool vrednost koju funkcija vraća, pa sam namestio da vraća true ukoliko je bar jedan simpleks obojen njenim pozivom.
> > > Ne vidim koje bi se greške mogle javiti pri bojenju
> >
> > Ovo sam ja zaboravio da preciziram u zadatku --- f-je treba da vrate false samo ukoliko ne uspeju da urade svoj posao. Jedine situacije u kojima je ovo
> > zamislivo su out-of-memory problemi, npr. ako "new UniqueIDColor()" odbije da adresira memoriju, ili sl. Ali posto o takvim stvarima za sada generalno ne
> > brinemo nigde u kodu, necemo ni ovde --- neka zasad f-je uvek vracaju samo true, pa cemo to da promenimo kad (ako) budemo radili code hardening.
> >
> > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> >
> > Jeste, ovo je prirodnije ime, vidim da ga je Dusan vec popravio.
> >
> > > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u dva fajla:
> >
> > Jeste, podelite classes.hpp na simpcomp.hpp i ksimplex.hpp (i odgovarajuce .cpp-ove). I naravno dodajte unutra forward-deklaracije klasa koje vam trebaju.
> >
> > :-)
> > Marko
> >
> > [1] https://en.wikipedia.org/wiki/Mutual_recursion
> >
> >
> >
> > Dr. Marko Vojinovic
> > Group for Gravitation, Particles and Fields
> > Institute of Physics
> > University of Belgrade
> > ======================
> > home page: www.markovojinovic.com
> > e-mail: vmarko@ipb.ac.rs
> >
> >
> >
> > On Tue, 22 Feb 2022, Dusan Cvijetic wrote:
> >
> > > Pozdrav,
> > >
> > > Ono sto sam primetio je drugacije imenovanje
> > >
> > > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo pisati. Moj deo koda
> > je mali i lako ćemo ga
> > > prepraviti da isprati bilo koji sistem.
> > >
> > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> > >
> > >
> > > Slažem se, ime koje ste predložili mi je jasnije. Promenio sam u kodu, pa mogu ponovo da ga ispravim ukoliko nije po volji - još nemamo toliko mnogo koda
> > da bi prepravljanje bilo
> > > ozbiljan posao.
> > >
> > > Ova petlja bez potrebe nastavlja i posle nadjene odgovarajuce boje:
> > >
> > > Ispravio.
> > >
> > > Ovde mi se ne svidja neuniformnost:
> > >
> > > Mislim da je ovo ispravljeno menjanjem imena funkcije za bojenje po nivoima.
> > >
> > > Deluje da ce colorization biti successful ako se bar jedan simplex oboji. Jel treba tako?
> > >
> > > To sam zaboravio da spomenem u mejlu, nije naznačeno šta označava bool vrednost koju funkcija vraća, pa sam namestio da vraća true ukoliko je bar jedan
> > simpleks obojen njenim pozivom.
> > > Ne vidim koje bi se greške mogle javiti pri bojenju, a da ih mi hvatamo, osim da simpleksi ne postoje, a tada vraća false. Nije mi bilo logično da vraća
> > false ukoliko ne oboji bar neki
> > > simpleks jer je moguće da neki nivo neće imati simplekse (ne znam da li je to sa strane primene tako, ali mi je situacija u kome postoje samo 3D elementi
> > u 8D kompleksu zamisliva), pa
> > > bi bilo mnogo false slučajeva za situacije koje su legitimne. Trebalo je ranije da pitam, ali šta je ideja sa bool vrednošću koju f-ja vraća?
> > >
> > > Usput, kako si testirao?
> > >
> > > Koristio sam samo onaj kod iz main.cpp, gde sam obojio tetrahedron. Uz to, testirao sam je uz pravljenje dva tetraedra da bih proverio kako se ponaša
> > kada ubacimo više objekata, i bilo
> > > je OK. Taj deo nisam hteo da ostavljam da ne bih previše remetio main.cpp.
> > >
> > > Moj bespotrebni kod si mogao slobodno da ubijes, umesto da ga ostavljas iskomentarisanog.
> > >
> > > Urađeno.
> > >
> > > Pozdravi,
> > > Dušan
> > >
> > >
> > > уто, 22. феб 2022. у 11:04 Nenad Korolija <nenadko@gmail.com> је написао/ла:
> > > Zdravo Dušane,
> > >
> > > Marko ce videti validnost bojenja.
> > >
> > > Ja pisem ocima najgoreg neprijatelja, cisto da bi se svi navikavali na to da obracaju paznju i na detalje (mozda nakon sto napisu kako im je najlakse,
> > mada verovatno bolje od
> > > starta):
> > >
> > > Ono sto sam primetio je drugacije imenovanje (sa underscore, tj. _) u odnosu na moje (camel case, npr. " bool hasUniqueColor = false;"). Meni je OK
> > bilo koja varijanta, samo da
> > > bude uniformno, a ne da neko ko radi na kodu treba svaki cas da prilagodjava mindset prema tome ko je kucao taj deo koda. :)
> > >
> > > Druga stvar koja mi je zapala za oko je colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda colorize_simplices_at_level?
> > >
> > > Ova petlja bez potrebe nastavlja i posle nadjene odgovarajuce boje:
> > > already_has_unique_id = false;
> > > for (auto cl : simplex->colors)
> > > if (cl->type == TYPE_UNIQUE_ID)
> > > already_has_unique_id = true;
> > >
> > > Ovde mi se ne svidja neuniformnost:
> > > colorize_entire_complex
> > > samo ide po nivoima i poziva:
> > > colorize_all_simplices
> > >
> > > Funkcije su kratke i lako se razumeju, ali je nezahvalno da neko mora da cita kod i zakljucuje, a da su nazivi funkcija neuniformni i misleading.
> > >
> > > Deluje da ce colorization biti successful ako se bar jedan simplex oboji. Jel treba tako?
> > >
> > > Usput, kako si testirao?
> > >
> > > Moj bespotrebni kod si mogao slobodno da ubijes, umesto da ga ostavljas iskomentarisanog. Sad imamo cist nacin, a ono moje je bilo cisto za testiranje
> > print_compact.
> > >
> > >
> > > Sto se tice toga kako treba uvezivati, mi smo inicijalno radili sve u jednom fajlu, pa smo razdelili, pa se Marko potrudio da napravi biblioteku i
> > razresi neke probleme.
> > > Radio sam za Italijane, Amerikance, Nemce i Engleze i svuda smo imali Makefile koji je kompajlirao pojedine cpp fajlove u .o objekte, pa ih link-ovao.
> > Verovatno je ovo nase
> > > trenutno include-ovanje nesto sto smeta VS-u.
> > > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u dva fajla:
> > > class KSimplex;
> > > class SimpComp{
> > > public:
> > > Ali ako je VS problem resen, mozemo da radimo dalje.
> > > Hvala za forward deklaracije za KSimplex i SimpComp. :)
> > >
> > > Pozdrav,
> > > Nenad
> > >
> > > On Tue, Feb 22, 2022 at 10:09 AM Dusan Cvijetic <dusancvijetic2000@gmail.com> wrote:
> > > Pozdrav,
> > >
> > > Odradio sam funkcije za zadatak, proverite je li sve u redu.
> > >
> > > Tek kada sam izvršio commit sam se setio da poruke treba da pišem na engleskom, ispraviću sledeći put, nadam se da nije veliki problem.
> > >
> > > I pored refaktorisanog koda, organizacija klasa Color i KSimplex/SimpComp stvara probleme. Color traži da budu već deklarisani SimpComp i KSimplex, a
> > KSimplex traži da već
> > > bude deklarisan Color, a SimpComp traži KSimplex: Color > SimpComp > KSimplex > Color. Naterao sam ga da radi dodavši forward deklaracije za KSimplex i
> > SimpComp u
> > > triangulator.hpp, ali ne mislim da je to dobro rešenje. Iz mog ograničenog iskustva, ovo mi deluje kao loša delegacija odgovornosti. Možda bi bolje bilo
> > da SimpComp samog
> > > sebe boji, ili da imamo posebnu klasu "molera" koja će da boji simplekse po potrebi? Tako bi ona mogla da uključi i Color i KSimplex i SimpComp, bez
> > problema koje trenutno
> > > imamo. Trenutno mi deluje neprijatno da polje klase namešta samo sebe, lepše mi je da to bude odgovornost samog objekta, ili nekog njemu nadređenog.
> > >
> > > Opet, moje iskustvo s ovakvim problemima se svodi na samo jedan iole ozbiljniji projekat koji sam radio, tako da mi javite ukoliko grešim, zanima me kako
> > se ove strukture
> > > obično rešavaju u praksi.
> > >
> > > Pozdravi,
> > > Dušan
> > >
> > > уто, 22. феб 2022. у 01:26 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> > >
> > > Pozdrav Dusane,
> > >
> > > Potpuno si u pravu da f-je za bojenje ne mogu (i ne treba) da se pozivaju za pojedinacnu boju. Dakle svakako, stavi ih kao static za klasu. Ja sam
> > to zaboravio
> > > da naglasim u definiciji zadatka, ali iz smisla tih f-ja je relativno ocigledno. :-)
> > >
> > > A taman posla da isti pointer dodeljujes celom kompleksu, to uopste nije bila ideja... ;-)
> > >
> > > Sto se tice rekurzivnog ukljucivanja fajlova generalno, slazem se da to moze bolje da se uradi, i to cu da reorganizujem uskoro (veceras ili sutra,
> > poslacu
> > > zaseban mail o tome). Reorganizacija ce da pomogne i za Visual Studio --- da se include-uju samo .hpp fajlovi a ne i .cpp fajlovi, da mozete da
> > napravite
> > > projekat, mozda cak da koristite i njegov kompajler, itdisl.
> > >
> > > A sto se tice rekurzivnog ukljucivanja fajlova u kontekstu zadatka 2, nemoj da se sekiras za to, nego treba samo da uradis sledece --- da
> > deklaracije f-ja stavis
> > > u color.hpp fajl (gde im je mesto u njihovoj klasi), a da implementacije tih f-ja stavis u color.cpp, gde se nalaze implementacije i za sve ostale
> > f-je koje su
> > > deklarisane u color.hpp. I onda kad si to uradio, testiraj f-je tako sto ces u main.cpp fajlu da obojis ceo tetrahedron (ili samo njegove vertekse,
> > level=0) i da
> > > ga ispises ponovo --- tj. nakon pozivanja njegovog tetrahedron->print_compact(), uradi
> > >
> > >    UniqueIDColor::colorize_entire_complex( tetrahedron );
> > >
> > > ili umesto toga uradi
> > >
> > >    UniqueIDColor::colorize_all_simplices( tetrahedron , 0 );
> > >
> > > i onda iza toga jos jednom pozovi tetrahedron->print_compact(). Zatim kompajliraj main.cpp i uporedi output-e ispisivanja tetrahedron-a pre i
> > posle, da vidis
> > > kako tvoje f-je menjaju ono sto se ispisuje. I to je to. ;-)
> > >
> > > :-)
> > > Marko
> > >
> > >
> > > Dr. Marko Vojinovic
> > > Group for Gravitation, Particles and Fields
> > > Institute of Physics
> > > University of Belgrade
> > > ======================
> > > home page: www.markovojinovic.com
> > > e-mail: vmarko@ipb.ac.rs
> > >
> > >
> > >
> > > On Mon, 21 Feb 2022, Dusan Cvijetic wrote:
> > >
> > > > Pozdrav,
> > > >
> > > > Konačno jedno pitanje koje se ne tiče Visual Studio-a, već samog koda.
> > > >
> > > > Naime, koliko sam razumeo iz potpisa funkcija, one treba da budu članice klase UniqueIDColor. Pošto je kroz ovu funkciju iz jednog poteza
> > potrebno dodeliti
> > > boje celom skupu simpleksa, a
> > > > svaki simpleks dobija svoju jedinstvenu boju, ne vidim kako bi se ona mogla pozivati za pojedinačne objekte ove klase (trebalo bi pozvati
> > konstruktore boje za
> > > svaki simpleks), pa sam
> > > > mislio da je realizujem kao statičnu funkciju članicu klase. Da li sam pogrešno razumeo ovaj deo, i zapravo treba dodeliti pokazivač na istu boju
> > celom delu
> > > simplicijalnog kompleksa,
> > > > tj. čitavom kompleksu?
> > > >
> > > > Nezavisno od prethodnog tumačenja, imam problem sa hijerarhijom klasa koji ne mogu da savladam. Potrebno je da KSimplex ima vektor pokazivača na
> > objekte klase
> > > Color, pa je u classes.hpp
> > > > uključen color.cpp. S druge strane, u color.hpp potrebno je uključiti classes.hpp, da bih mogao da iteriram kroz vektor simpleksa u kompleksu i
> > dodeljujem
> > > boje. Ovo vodi do rekurzivnog
> > > > uključivanja fajlova: classes.hpp->color.cpp->color.hpp->classes.hpp. Čak i da se klasa KSimplex deklariše pre #include "color.cpp", ostaje isti
> > problem, pošto
> > > bez definicije klase ne
> > > > mogu da pristupam njenim poljima, jer je i dalje nepotpuni tip. Trenutno ne vidim način da se ovo izbegne, osim da se izmeni hijerarhija klasa,
> > ili raspored po
> > > .hpp fajlovima. Propuštam
> > > > li nešto ovde? Nikad nisam radio sa tuđim kodom na ovaj način, pa se izvinjavam što mi treba više vremena da savladam sve.
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > > пон, 21. феб 2022. у 22:36 Dusan Cvijetic <dusancvijetic2000@gmail.com> је написао/ла:
> > > > Pozdrav,
> > > >
> > > > Hvala Vam mnogo, ponovio sam korake koje ste naveli u poruci, i Visual Studio sada uspeva da izgradi i izvrši kod, a čak uspeva i da mi farba
> > kod bez dodatnih
> > > koraka. Ipak, ne
> > > > vidim koja je razlika u odnosu na ono što sam ja radio (File/New project from existing code), osim što se fajlovi nalaze na drugom mestu. Nije mi
> > jasno zašto
> > > isti kod hoće da
> > > > izvrši kada se u projekat unese na jedan način, a baca greške kada se uveze na drugi...
> > > >
> > > > Isprva sam pokušao da ispratim vaše korake bez prethodno kreiranog main.cpp fajla, i video da tada Visual Studio uopšte ne nudi meni
> > > Debug/Properties/Configuration Properties/C++,
> > > > pretpostavljam zato što nema koda na osnovu kog bi zaključio u kom jeziku ću pisati (?). Pretpostavljajući da će pronaći ispravan kompajler
> > ukoliko direktno u
> > > VS kreiram main
> > > > funkciju, prekopirao sam sve .hpp i .cpp fajlove u direktorijum projekta, prethodno napravivši main.cpp u VS uz kopiranje koda iz originala.
> > Nadao sam se da ću
> > > tako izbeći
> > > > uključivanje dodatnih direktorijuma, i eventualno namestiti da mi se projekat nalazi u lokalnom git direktorijumu, što bi mi bilo najzgodnije
> > (ako je ovo iz
> > > nekog razloga loša
> > > > praksa, napomenite mi, da odmah odustanem). Međutim, kada fajlove uvezem na ovaj način, ponovo baca iste greške kao i ranije.
> > > >
> > > > Pošto ovakva konfiguracija za sad radi, držaću se nje, ali ako neko ima ideju šta mi se dešava, bio bih zahvalan na objašnjenju.
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > > пон, 21. феб 2022. у 18:09 Jaroslav Blagojevic <jaroslav.blagojevic@gmail.com> је написао/ла:
> > > > Ja sam napravio prazan Visual Studio 2019 projekat, u drugom direktorijumu nego download-ovani repozitorijum, samo sa main.cpp fajlom kao
> > "source files"
> > > (hpp fajlovi
> > > > kao "include files" i dodao direktorijum sa download-ovanim repozitorijumom u
> > Dеbug->Properties->Configuration Properties->C++->General->Additional
> > > Include
> > > > Directories).Taj projekat sam izvršio uspešno, a za potrebe menjanja, pošto nije hteo da mi farba kod, sam morao da copy&paste-ujem .hpp
> > fajlove (i cpp
> > > fajl na kome
> > > > radim) iz download-ovanog repozitorijuma u direktorijum projekta, izmenim .hpp fajlove (dodao sam nastavak '1' na svaki) da ne uključuju
> > .cpp, kopiram i
> > > .cpp fajl
> > > > (isto dodajući nastavak '1'), izmenim, testiram i copy&paste-ujem promene nazad. Neće da farba kod u .cpp fajlovima, zato što ih ne tretira
> > kao include
> > > fajlove. Dotle
> > > > sam stigao. Visual Studio traži da mu se svi .cpp fajlovi stave u projekat, a ne da se include-ju .cpp fajlovi u okviru jedan drugog.
> > Pretpostavljam da
> > > ako to uradimo,
> > > > da će biti problem sa g++-om (da li on podržava projekte?)
> > > >
> > > > Pozdrav,
> > > >
> > > > Jaroslav
> > > >
> > > >
> > > > On Sun, Feb 20, 2022 at 7:13 AM Marko Vojinovic <vmarko@ipb.ac.rs> wrote:
> > > >
> > > > Pozdrav Dusane,
> > > >
> > > > Meni se cini da svi problemi na koje si naisao izgleda dolaze iz neke greske prilikom import-ovanja koda u Visual Studio. Ja ne koristim VS
> > i ne umem da
> > > ti
> > > > pomognem oko toga, ali Jaroslav rece da je uspesno importovao kod u VS, pa verovatno moze on da ti pomogne.
> > > >
> > > > Trenutna verzija koda je inace skroz kompletna, sve je definisano, implementirano i radi kako treba --- ja ga u Linux-u prosto kompajliram
> > iz komandne
> > > linije,
> > > > ovako:
> > > >
> > > >    g++ main.cpp -o izvrsi-me
> > > >
> > > > i onda kad izvrsim fajl "izvrsi-me", dobijem ocekivani output. Kompajler ne prijavljuje nikakve greske, sve prolazi savrseno glatko.
> > > >
> > > > > Koliko sam video, greške koje mi kompajler baca se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz standardne
> > biblioteke.
> > > >
> > > > Pomoglo bi da nam posaljes te greske (makar prvih nekoliko), da vidimo o cemu se radi.
> > > >
> > > > > Video sam da je using namespace std iskorišćen na početku triangulator.hpp fajla, ali me je zanimalo zašto ta komanda ne stoji na početku
> > svakog .hpp
> > > fajla? Da
> > > > li bi to bilo redudantno?
> > > >
> > > > Da, bilo bi redundantno. Dizajn je da main.cpp include-uje samo triangulator.hpp, a da ovaj u sebi include-uje sve ostalo sto mu treba. Ne
> > vidim zasto bi
> > > zeleo
> > > > da deklarises namespace std vise puta. Mada mi se cini da cak i ako to uradis, ne bi trebalo da nastane nikakav problem.
> > > >
> > > > Bila bi dobra ideja da na papiru nacrtas "drvo include-ova": koren je main.cpp, pogledas koji fajlovi su tu include-ovani, pa se onda
> > spustas po granama
> > > tako sto
> > > > onda otvoris te include-ovane fajlove i vidis sta oni include-uju, itd. Ja sam to bio uradio jednom, i preporucujem i tebi --- to drvo ti
> > pruza vrlo lep
> > > uvid u
> > > > organizaciju koda.
> > > >
> > > > > Da li postoji neko pravilo kada treba da uključujem .hpp, a kada .cpp fajlove?
> > > >
> > > > Genericki receno, .hpp fajlovi sadrze definicije klasa i deklaracije njihovih metoda i f-ja, a .cpp fajlovi sadrze implementacije tih
> > metoda i f-ja
> > > deklarisanih
> > > > u .hpp fajlovima. Oni su vec namesteni da include-uju jedni druge, prema onom drvetu, ti tu ne bi morao nista dodatno da radis.
> > > >
> > > > > Još jedna od praksi koje su nas uvek terali da ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define - #endif strukture
> > > >
> > > > Ta praksa je sigurno dobra, ali mi smo #define-ovali konstante samo u constants.hpp fajlu, i nigde drugo. Iz drveta mozes da vidis da je
> > constants.hpp
> > > > include-ovan samo jedanput (unutar classes.hpp), pa ne bi smela nigde da ti se pojavi dupla definicija tih konstanti. Kasnije cemo
> > verovatno da dodamo
> > > #ifndef
> > > > strukturu u constants.hpp, da budemo u skladu sa praksom, ali to nije sad najhitnija stvar --- kod momentalno radi ispravno i bez toga. :-)
> > > >
> > > > > pa bih cenio bilo kakvu pomoć koju možete da mi pružite.
> > > >
> > > > Jaroslave, jel' bilo neceg netrivijalnog oko ubacivanja koda u Visual Studio? Jel' imas neki hint za Dusana?
> > > >
> > > > :-)
> > > > Marko
> > > >
> > > >
> > > > Dr. Marko Vojinovic
> > > > Group for Gravitation, Particles and Fields
> > > > Institute of Physics
> > > > University of Belgrade
> > > > ======================
> > > > home page: www.markovojinovic.com
> > > > e-mail: vmarko@ipb.ac.rs
> > > >
> > > >
> > > >
> > > > On Sun, 20 Feb 2022, Dusan Cvijetic wrote:
> > > >
> > > > > Pozdrav,
> > > > >
> > > > > Počeo sam da radim drugi zadatak kao što smo pričali, i imam problem sa pokretanjem koda. Nisam ništa menjao u fajlovima, samo sam
> > napravio projekat u
> > > Visual
> > > > Studio-u 2019
> > > > > (File/New/Project from existing code, sa svim default opcijama), i kada pokušam da ga pokrenem, kompajler mi baci gomilu grešaka. Da li
> > je u ovom
> > > trenutku
> > > > generalno nemoguće pokrenuti
> > > > > main.cpp, ili ja pravim neku grešku?
> > > > >
> > > > > Koliko sam video, greške koje mi kompajler baca se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz standardne
> > biblioteke. Video
> > > sam da
> > > > je using namespace std
> > > > > iskorišćen na početku triangulator.hpp fajla, ali me je zanimalo zašto ta komanda ne stoji na početku svakog .hpp fajla? Da li bi to bilo
> > redudantno?
> > > > >
> > > > > Kada smo na fakultetu radili C++, uvek smo #include direktive koristili da uvezemo neke header-e u trenutni fajl, no video sam da se u
> > kodu ovde nekada
> > > > uključuju .hpp, a nekada .cpp
> > > > > fajlovi. Da li postoji neko pravilo kada treba da uključujem .hpp, a kada .cpp fajlove?
> > > > >
> > > > > Još jedna od praksi koje su nas uvek terali da ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define - #endif strukture
> > (tražili su nam
> > > da ne
> > > > koristimo #pragma once jer
> > > > > zavisi od kompajlera) kako bismo izbegli višestruku definiciju pri uključivanju zaglavlja. Da li mi koristimo neku drugu zaštitu za
> > zaglavlja? Dosta
> > > grešaka
> > > > koje mi je kompajler bacio
> > > > > je bilo zbog redefinicije promenljivih, pa pretpostavljam da je to zbog odsustva zaštite zaglavlja.
> > > > >
> > > > > Na par mesta su se pojavila imena koja ranije nisu definisana. Pretpostavljam da je to zato što još uvek nemamo ceo kod, pa nisu sve
> > funkcije i
> > > promenljive
> > > > uvedene, no hteo sam ovde da
> > > > > spomenem i te greške za slučaj da su problem samo kod mene.
> > > > >
> > > > > Na kraju sam pokušao da izmenim kod na mestima koje sam gore spominjao, samo da vidim mogu li ga naterati da se pokrene, i iako je
> > kompajler prestao da
> > > se
> > > > javlja, linker je počeo da mi
> > > > > baca greške. Pretpostavljam da postoji neko sistematičnije rešenje za moje probleme (do sada mi se linker javljao samo kada ne startujem
> > projekat u VS
> > > kako
> > > > treba), pa bih cenio bilo
> > > > > kakvu pomoć koju možete da mi pružite.
> > > > >
> > > > > Pozdravi,
> > > > > Dušan
> > > > >
> > > > >
> > > > > пет, 11. феб 2022. у 22:34 Marko Vojinovic <vmarko@ipb.ac.rs> је написао/ла:
> > > > >
> > > > > Upoznati se sa osnovnom klasom Color i njenim child-klasama kroz problem dodeljivanja boje UniqueIDColor datom delu simplicijalnog
> > kompleksa,
> > > odnosno
> > > > celom kompleksu:
> > > > >
> > > > >    bool UniqueIDColor::colorize_all_simplices( SimpComp* G , int level );
> > > > >    bool UniqueIDColor::colorize_entire_complex( SimpComp* G );
> > > > >
> > > > >    Input: pointer na simplicijalni kompleks, nivo "k" za k-simplekse koje treba obojiti.
> > > > >    Output: true ako je uspesno izvrseno bojenje, false ako je doslo do neke greske.
> > > > >
> > > > > F-ja colorize_all_simplices() treba da prodje kroz sve simplekse iz G.elements[level] (ili se pise G->elements[level]?), i svakom
> > od njih da
> > > dodeli
> > > > instancu boje klase
> > > > > UniqueIDColor. F-ja colorize_entire_complex() treba da izvrsi prethodnu f-ju za sve vrednosti 0 <= level <= D. Nakon toga,
> > zakomentariti kod koji
> > > > dodeljuje ovu boju u seed
> > > > > f-ji seed_single_triangle() (boju boundary ne dirati, ona treba da ostane u seed f-ji), i umesto toga u main() f-ji eksplicitno
> > pozvati
> > > > colorize_entire_complex() da oboji
> > > > > kompleks za trougao, odmah nakon sto se ovaj instancira.
> > > > >
> > > > >
> > > > > :-)
> > > > > Marko
> > > > >
> > > > >
> > > > > Dr. Marko Vojinovic
> > > > > Group for Gravitation, Particles and Fields
> > > > > Institute of Physics
> > > > > University of Belgrade
> > > > > ======================
> > > > > home page: www.markovojinovic.com
> > > > > e-mail: vmarko@ipb.ac.rs
> > > > >
> > > > >
> > > > > --
> > > > > QGHG-it-dev-list mailing list
> > > > > QGHG-it-dev-list@ipb.ac.rs
> > > > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > > >
> > > > >
> > > > >--
> > > > QGHG-it-dev-list mailing list
> > > > QGHG-it-dev-list@ipb.ac.rs
> > > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > >
> > > > --
> > > > QGHG-it-dev-list mailing list
> > > > QGHG-it-dev-list@ipb.ac.rs
> > > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > > >
> > > >
> > > >--
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list@ipb.ac.rs
> > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > > --
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list@ipb.ac.rs
> > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > > --
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list@ipb.ac.rs
> > > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > >
> > >--
> > QGHG-it-dev-list mailing list
> > QGHG-it-dev-list@ipb.ac.rs
> > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> > --
> > QGHG-it-dev-list mailing list
> > QGHG-it-dev-list@ipb.ac.rs
> > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list@ipb.ac.rs
> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>
>
>--
QGHG-it-dev-list mailing list
QGHG-it-dev-list@ipb.ac.rs
http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list