Bodovani podle sad test casu

[zapotocnylubos]

Navrhnout novy styl hodnoceni a bodovani odevzdanych reseni.

Melo by byt schopne prerozdelit celkove body nastavene v problmu bud

• explicitne = tato sada, pokud bude zelena, dostane za ni 2 body
• procentualne = tato sada, pokud bude zelena, dostane za ni 20% celkovych

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)

[matous-volf]

• body prerozdelovat explicitne (dany pocet bodu - cele cislo).

  • nemusi se resit, aby vychazely procenta.
  • bude nutne navrhovat ta bodova ohodnoceni inteligentne - aby se nedalo za neco trivialniho ziskat stejny pocet bodu jako za neco sloziteho. ale to by se resilo i v procentualnim pristupu.

• entita Judging nebude mit jako result pouhy string, ale i pocet ziskanych bodu.

• Testcase bude mit vlastnost, kolik bodu je za jeho splneni

[zapotocnylubos]

@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

[matous-volf]

jo, to zni lip. takze

vlastnosti entit

• nova entita TestcaseGroup
  • problem, do ktereho patri (fk v db)
  • testcasy, ktere do ni patri
  • pocet bodu za jeji splneni
  • nazev (pro jury) - jaky jev ulohy tato skupina testuje
• Problem
  • kolekce techto skupin
  • max mozny pocet bodu za splneni celeho problemu
• Testcase
  • skupina, do ktere patri (fk v db)
• Judging
  • int ziskany pocet bodu
  • string result musime asi nechat kvuli kompatibilite - napr. aby se zobrazovalo pri odevzdani, jaky typ chyby v reseni nastal.

logika

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 JudgingRunu 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.

• u kazdeho runu se podiva na vlastnost testcase a u toho na testcaseGroup
• kdyz budou vsechny runy s danou skupinou "correct", pricte k ziskanym bodum pocet bodu za splneni teto skupiny (to je vlastnost TestcaseGroup). tento soucet ze vsech splnenych skupin potom vrati.

[zapotocnylubos]

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.

• definice testcase <-> group neni vazana na contest, tedy uloha musi byt univerzalni i kdyz v jednom contestu bude za 10b a i kdyz bude v druhem za 15b. Navrhuji tedy v TestcaseGroup ukladat pouze procentualni (double [0, 1]) hodnotu, za kolik se tato skupina hodnoti z hlavniho bodoveho ohodonoceni. Pokud bude tedy skupina s ohodnocenim 0.25 splnena a cely problem v contestu bude za 20b, uzivateli do vysledneho hodnoceni muzes pridat 5b.

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.

• budes si muset predat i aktualni problemcontest, aby jsi mohl vrati max pocet bodu
• $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

[zapotocnylubos]

jo a budeme zohlednovat tyto parcialni body v razeni?

[matous-volf]

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?

[zapotocnylubos]

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)

[zapotocnylubos]

Some other aspects to consider when upstreaming:

• how do test case groups interact with verdict priorities?
• how do test case groups interact with lazy evaluation?
• how does one specify this in the problem format? (the ICPC version of https://icpc.io/problem-package-format/spec/problem_package_format#test-data-groups is not complete)