[QGHG-it-dev-list] Zadatak 2 - bojenje kompleksa

Nenad Korolija nenadko at gmail.com
Tue Feb 22 11:04:00 CET 2022


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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220222/06b307c1/attachment-0001.htm>


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