Se non erro, fino a non molto tempo fa un testcase faceva parte di un solo subtask, ma ora non è più così.
Un effetto non trascurabile di questo nuovo modo di assegnare i testcase è il seguente:
Sbagliando la soluzione di un solo test case si ottiene 0 in più subtasks.
Ad esempio, facendo modifiche al mio codice relativo a “datazione” in una sottoposizione questo ha sbagliato il testcase N1 (uno dei casi di esempio!), risultato 0 punti nei subtask: 1,2,5,6,7,8.
Prima sbagliando anche tutti i testcase del subtask1, purché solo quelli, si faceva 100/100.
Va bene così?
Sì, direi che se una soluzione sbaglia un esempio non si merita di fare 100
3 Mi Piace
Pienamente d’accordo, e passi per per i subtask di esempio ma merita di fare 0 o giù di li?
Quello che volevo dire è a cosa serve la suddivisione in subtasks se poi bisogna risolvere tutti i testcase di un subtask per far punti in parecchi dei subtasks successivi?
I subtask servono per dare punti alle soluzioni che risolvono il problema sotto ulteriori assunzioni.
Se per esempio una soluzione sbagliasse un caso con N≤100, evidentemente non risolverebbe neanche il problema sotto l’assunzione più debole N≤1000
2 Mi Piace
Beh però, ad esempio, l’editoriale a volte suggerisce approcci in qualche modo diversi e più raffinati al crescere di N. Vedere l’editoriale OII 2024 a riguardo di datazione.
Non capisco davvero cosa stai provando a dire. Il punto è che un singolo testcase spesso è valido per più di un subtask.
Riutilizzare i testcase di un subtask nei subtask con assunzioni più deboli rafforza i testcase a costo zero.
2 Mi Piace
Sto solamente provando a dire che preferivo il precedente modo di strutturare l’assegnazione dei testcase ai subtask, tutto qui, non che questo non abbia una sua logica. Ma è solo una idea.