Open zapotocnylubos opened 1 year ago
body prerozdelovat explicitne (dany pocet bodu - cele cislo).
entita Judging
nebude mit jako result pouhy string, ale i pocet ziskanych bodu.
Testcase
bude mit vlastnost, kolik bodu je za jeho splneni
@matous-volf jeste jeden mod (kapku univerzalnejsi) by bylo zarazovat testcases do nejakych skupin (podobne jako jsme bodovali minule finale) a pokud vsechny test cases z teto skupiny projdou, tak priradit odpoidajici pocet (procento?) bodu
jo, to zni lip. takze
TestcaseGroup
Problem
Testcase
Judging
result
musime asi nechat kvuli kompatibilite - napr. aby se zobrazovalo pri odevzdani, jaky typ chyby v reseni nastal.jelikoz Judging
bude mit int pocet bodu, bude nutne pridat novou metodu podobnou SubmissionService->getFinalResult()
volanou v JudgehostController
, ktera bude (podobne jako tato) na zaklade vsech judging runu (vysledku testu) daneho judgingu vyhodnocovat pocet ziskanych bodu v tomto judgingu.
existujici metoda dostava pole stringu - vysledky vsech JudgingRun
u v danem judgingu. kdyz jsou vsechny correct, vrati correct, jinak vrati dany chybny vysledek ("no-output" apod.).
nova metoda bude muset prijimat ne pole stringu, ale asi pole JudgingRun
(potrebuje znat jeho vysledek a skupinu, do ktere patri). bude tedy vracet int - pocet bodu ziskanych v tomto judgingu.
testcase
a u toho na testcaseGroup
TestcaseGroup
). tento soucet ze vsech splnenych skupin potom vrati.Chtel bych nejak ponechat funkcionalitu toho, ze max. pocet bodu co za vyreseni problemu muzes ziskat se urcuje v tom formulari editace contestu (jak jsou tam ty dynamicke radky na prirazovani problemu do contestu). Tedy kdyz tam si napisu 10, mel by to byt maximalni pocet, ktery dostanu, kdyz udelame vsechny testcasy.
Tvuj postup - vytvorit novou m:n propojovaci tabulku/entitu mezi testcase a novou entitou skupina je validni. Z hlediska navrhu to ale prinasi zbytecnou komplexitu, jelikoz mas takove dva zdroje pravdy na to kolik bodu je za ulohu a musis si treba hlidat, ze ten hlavni maximalni pocet se rovna souctu bodu, ktere si definujes v techto skupinach.
Aby ale tvoje reseni mohlo fungovat, musi byt DJ v modu, kdy vzdy spusti vsechny test cases (na pardubickem hackerovi jsem to uz prepnul)
Bez tohoto prepinace bys totiz nemohl rici realny pocet bodu, ale vzdy by jsi mohl vypocitat body pouze z dosavadne zelenych testcasu a az jeden spadne, uz bys nemohl pridat treba posledni bod na poslednim testcasu (grupe), na kterem by to soutezicimu proslo, ale dany testcase/group se vubec nespustil.
Zhlediska apliakce tedy bude nutne overovat, ze je tento full mod zapnuty (jinak to nema cenu pocitat a scoreboard by se nemel lisit od defaultniho chovani)
Do Judging bych pridal tedy nullable float, nullable aby byla moznost indikovat, ze judging je v "defaultnim" rezimu. Pokud bude 0, dostal doopravdy 0b. Melo by to pomoci pri editaci sablony -> bude pak nejdnodusi rozlisovat, kdy a kolik bodu zobrazovat.
nova metoda bude muset prijimat ne pole stringu, ale asi pole JudgingRun (potrebuje znat jeho vysledek a skupinu, do ktere patri). bude tedy vracet int - pocet bodu ziskanych v tomto judgingu.
Mozna bych nemodifikoval tuto core funcionalitu, ale spise rozsiril. Slo by pridat napriklad vlastni service na vypocet vysledku z danych JudgingRunu, kterou zalovas nekde v JudgehostController napr na teto radce po setResult
. Tim ziskas nativni funkcnost a bude stacit nasetovat vysledne (castcne) body do judgingu pomoci tve nove service tridy.
Tento set
muzes volat pokud $lazyEval == DOMJudgeService::EVAL_FULL
a mas k dispozici i $runs
, coz je pole JudgingRun
Zjednodusuje se pote i komatibilita s tim, pokud problem nebude mit zadnou testcase skupinu. Pokud bude mit dany problem 0 skupin, musis tvoji service napsat tak, ze vraci 0, pokud vysledek z getFinalResult
(to si asi predas jako parametr) neindikuje success a plne body, pokud indikuje success.
$judging->getSubmission()->getContestProblem()
Plne body bych vracel i v pripade, ze vysledek z getFinalResult rika success (bez nejakeho hledani a pocitani test case skupin -> proste ma vsechno spravne). Jsme totiz v modu, kdy uz vis, ze je vysledek kompletne spravny a kdy budes pocitat nejake double hodnoty, mohlo by se stat, ze misto 15b tam bude 14.998b
jo a budeme zohlednovat tyto parcialni body v razeni?
mas pravdu, o pouziti problemu ve vice contestech jsem vubec neuvazoval. tak procenta jsou tim padem lepsi. a celkove mi tve reseni dava smysl.
Tvuj postup - vytvorit novou m:n propojovaci tabulku/entitu mezi testcase a novou entitou skupina je validni.
puvodne jsem myslel testcase:skupina jako n:1 -> neni potreba propojovaci tabulka. nebo chceme moznost, ze jeden testcase patri do vice skupin?
Do Judging bych pridal tedy nullable float
to bude tedy pocet bodu (predpokladam) nebo procentualni splneni?
jo a budeme zohlednovat tyto parcialni body v razeni?
za me by to bylo fajn, budeme teda muset prepocitat i stavajici judgingy?
puvodne jsem myslel testcase:skupina jako n:1 -> neni potreba propojovaci tabulka. nebo chceme moznost, ze jeden testcase patri do vice skupin?
sorry, jojo, nebude to m:n, jenom 1:n
to bude tedy pocet bodu (predpokladam) nebo procentualni splneni?
jj bylo by to finalni ohodnoceni.
V pripade, ze problem/DJ ma nastavene lazy eval, tak by se to nemelo nastavit => zustane default null
Chceme tam null, protoze se nam pak v scoreboard sablone bude dobre rozhodovat, co zobrazit. Nechceme totiz zobrazovat 0b, pokud to je v lazy rezimu, to by ta scoreboard byla plna nul a bylo by to demotivujici. Pokud to null nebude, vypsat to cislo nekam do te bunky tabulky.
Zaokrouhlovani bych resil normale (do 0.5 dolu, >= 0.5 nahoru [pokud bude 0 des. mist], priapdne si tento priklad posun o prislusny pocet des. mist). Pocet des. mist z DJ configu s default honotou treba 1 des. misto. Asi by se tedy hodilo mit ciselnou reprezentaci pro sortovani, ale take stringovou hodnotu pro reprezetnaci cisla na spravny pocet des. mist. To by mohl byt nejaky rozsireny getter (jeden na "raw" hodnotu [zaohrouhlenou] a jeden na "human" hodnotu [vraci string])
Suffix bodu bych volil anglicky, ne tedy 5b, ale 5pt? (pripadne 5.1pt)
V pripade, ze mame full hodnoceni, muzeme provest rozhodnuti o plnem poctu bodu ihned, pokud je cele odevzdani zelene (uz nemusime pocitat procenta podle skupin.
V ostatnich pripadech (tedy neni lazy eval a neni 100% spravne) prejdeme do hlavni logiky tve nove service pro vypocet bodu
za me by to bylo fajn, budeme teda muset prepocitat i stavajici judgingy?
DJ ma na podobne pripady (napr pridani noveho testcase nebo uprava stavajiciho) tu funkci recalculate scoreboard a nejake clearovani cache.
Takze by melo byt mozne ponechat stavajici vysledky tak jak jsou.
Mozna jeste vedle kontroly, ze je to full judging jeste pridat do contestu prepinac na to, jestli se toto parcialni hodnoceni ma aktivovat nebo ne. (podobe jako jsou prepinace, jestli se maji davat medaile, ty balloons atd..)
Je totiz mozne, ze na urovni celeho DJ zapneme FULL rezim, ale nektere contesty nebudeme chtit parcialne hodnotit (treba ty testovaci ulohy) [a tedy i razeni ve scoreboard se nebude menit, protoze nebudeme pocitat ty parcialni body], ale nejake contesty ano (treba ty soutezni)
Some other aspects to consider when upstreaming:
Navrhnout novy styl hodnoceni a bodovani odevzdanych reseni.
Melo by byt schopne prerozdelit celkove body nastavene v problmu bud
Zaroven je tento soucet nutne ukazovat a propagovat do scoreboardu
Pro tento mod je nutne zapnout ci upravit funkcionalitu odevzdavani, aby to vzdy proslo vsechny test cases
Cas odevzdani by se mel projevit az v poslednim kroku serazeni vysledku -> pokud nekdo bude mit stejny pocet bodu, mel by zahrat roli cas odevzdavani (tak jak je to default)