Datastructuren

Praktikum Voorjaar 2020

Meteen naar DomJudge

Je kunt over de opdrachten vragen stellen op het werkcollege, of een clarification request sturen aan het practicumteam. Stel geen vragen over een programmeeropdracht per mail! Mail ons nooit je C# code! Veel van wat je moet weten wordt op hoorcollege behandeld; bezoek dus de colleges zo veel mogelijk. Je mag aan de opdrachten beginnen voordat de theorie behandeld is, maar als je er dan niet uitkomt, kun je hem het beste even laten liggen tot na het college.

Wat gegeven is over de invoerwaarden, hoef je niet te controleren (als in Defensief Programmeren). Dus als de opdracht bv. zegt: op deze regel staat een getal kleiner dan 1000000, hoef je het getal niet te testen op deze grens. DomJudge test in principe alleen met legale invoeren, en als er per ongeluk toch een testinvoer niet klopt is dat onze verantwoordelijkheid.

Algemene aanwijzingen

Je programma moet voor invoer en uitvoer altijd de console gebruiken, dus de instructies Console.ReadLine(); en Console.WriteLine(...);. De voorbeelden geven de complete invoer en uitvoer als bestand, en je kunt om te testen de console koppelen aan een bestand met een redirect. Bij opdracht 1 is het paar ColVb1.in en ColVb1.out gegeven. Het windows-commando colprog.exe <ColVb1.in >mijnColVb1.out moet een bestand mijnColVb1.outopleveren dat exact gelijk is aan ColVb1.out.

Werken met DomJudge

Voor je gaat inleveren, kun je het best zorgen dat de gegeven voorbeeldinvoeren correct worden verwerkt (de correcte uitvoeren staan er naast). Probeer zelf met verdere tests vast te bevestigen dat je programma goed werkt. Bezoek dan de DomJudge TEAM pagina en log in met je Solis-id.

Submitten: Het inzenden van een C# oplossing is eenvoudig: Klik op de Overview-pagina "Browse..." en selecteer de file met je C#-code (extensie .cs, niet een .exe of .sln). DomJudge verwacht dat je alle code en alle classes in 1 file zet. Selecteer de gemaakte opdracht met problem en "kies" de language (alleen C# is mogelijk). Beuk op Submit en wacht af wat DomJudge van je programma vindt.

Beoordeling van DJ: DomJudge kan aangeven dat je programma niet compileert (COMPILER-ERROR), crasht (RUN-ERROR), te langzaam werkt (TIMELIMIT), geen (NO-OUTPUT) of een verkeerde uitvoer geeft (WRONG-ANSWER). Het mooist is de melding CORRECT want die betekent dat je programma goed is en je opdracht af. Door op de melding te klikken, krijg je meer informatie over de beoordeling.

DomJudge kan niet controleren of je het juiste algoritme hebt geïmplementeerd. Dus als de opdracht vermeldt implementeer QuickSort en je gebruikt HeapSort, zal je programma mogelijk door DomJudge worden geaccepteerd zonder dat het echt goed (dwz. conform de opdracht) is. Als DomJudge je programma zonder gepruttel accepteert (de letters CORRECT verschijnen in groen), en je hebt je gehouden aan de algoritmische eisen (voor zover die in de opdracht staan), heb je de opdracht in principe af. Alleen als je algoritmische eisen hebt genegeerd of fraude hebt gepleegd, kan je programma daarna nog door ons worden afgekeurd.

Kleine en grote tests: Meestal heeft DJ eerst een paar kleine testcases, om te zien of je oplossing correct werkt. Deze kunnen met een langzaam programma nog binnen de tijd lukken. Dan volgen meestal grotere invoeren, om te zien of je oplossing ook snel genoeg is.

Verborgen tests: DJ bevat een aantal openbare en een paar gesloten tests. Daarom kan het gebeuren dat je programma niet goed is, maar toch op alle zichtbare testcases CORRECT geeft. Het probleem zit dan in een verborgen testcase. Je moet dat wel oplossen, want je opdracht is nog niet af!

Clarification: Via Clarifications is communicatie met het praktikumteam mogelijk. Maar niet altijd en niet snel! Als je 5 minuten voor de deadline tegen een issue aanloopt en je kunt niet verder zonder hulp, dan heb je een probleem. Een Clarification is een soort vraag die je aan "de Jury" (het praktikumteam) kunt stellen. Wij proberen die vragen te beantwoorden, maar een snel antwoord kan niet altijd worden gegarandeerd, zeker niet vlak voor een deadline! Het is jouw verantwoordelijkheid dat je de deadline haalt, niet de onze!
Het is een goed idee om vroeg aan elke opdracht te beginnen! Als je al begint voordat de theorie erover is behandeld, en je krijgt de opdracht niet werkend, wacht dan tot de theorie behandeld is. Vermijd het, clarification te vragen over theorie die nog behandeld gaat worden. Stel geen vragen per mail over een opdracht.

Clarifications op zaterdag: Op zaterdag is de jurystoel onbemensd, en dan is beantwoording van Clarifications onzeker. Vermijd daarom dat je op de dag van een deadline nog van clarifications afhankelijk bent! Zorg dat je uiterlijk vrijdag de opdracht snapt en voldoende precies weet hoe je hem op moet lossen.

Deadline: De deadlines staan niet exact op middernacht ingesteld. Houd er rekening mee, dat inleveren in de laatste seconde van de dag onmogelijk is, en in de laatste minuut moeilijk kan zijn. Als je de deadline niet hebt gehaald, email ons dan je programma niet! Een programma kan na de deadline niet meer meetellen, we draaien het niet proef "alleen maar om te kijken of-ie het nu doet", en we geven geen feedback op programma's van na de deadline. (Storingen in het DomJudge platform zijn uiteraard reden voor ons om de deadline op te schuiven.) Als je de deadline niet hebt gehaald, zorg dan dat je aan de reparatie kunt meedoen en lever het dan opnieuw in.

Vorig jaar al gedaan? Je moet de opdrachten dit jaar inleveren: wat je vorig jaar bij Datastructuren hebt ingeleverd, telt nu niet vanzelf weer mee. Als de opdracht hetzelfde is, mag je natuurlijk wel je (eigen!) code oppoetsen, versnellen en/of verbeteren en opnieuw inleveren.

Fraude, Plagiaat en Verboden samenwerking

Samenvatting: Je moet al je code zelf schrijven, je mag geen code overnemen, en je code ook niet aan anderen geven of publiek maken.

Voor vrijwel iedereen is 100% duidelijk wat hiermee wordt bedoeld. Heb je hier toch nog vragen over, lees dan verder. Je mag uiteraard met anderen over de opdracht praten, wij moedigen dit zelfs aan omdat je van elkaar het meeste kunt leren. De samenwerking gaat te ver als er code wordt overgenomen of code van anderen ingestuurd. Het zelf intypen van code die je afleest van het scherm van een medestudent of die een medestudent opleest, zien wij niet als zelf schrijven van een programma!

Let op: DomJudge bevat plagiaat-detectie en plagiaat wordt bestraft! Je inzending wordt ook vergeleken met inzendingen van vorig jaar. Docent of nakijkers kunnen je vragen, delen van je code toe te lichten.

Als je delen van je code van internet haalt (bijvoorbeeld voor algemene veelvoorkomende datastructuren) dan moet je in een comment de bron vermelden.

Ook het delen van code is niet toegestaan! Je mag je programma niet door anderen laten bewaren of testen en het niet op openbare code-platforms zetten. Geef zeker nooit je code aan iemand die er niet uit komt, ook niet "alleen om te kijken". Als je dat toch doet, en een studiegenoot levert jouw code in of een variant daarvan, kun jij bestraft worden voor fraude!

Hetzelfde nogmaals in informelere taal:
Hoe ver mag samenwerken gaan bij het praktikum? Je mag wel met elkaar praten over hoe je dingen hebt opgelost. Maar je moet het uiteindelijk allemaal zelf doen en zelf maken.
Er mag nooit code van je medestudent in een submission naar DomJudge zitten. En let op: DomJudge bewaart alle submissies, ook als je daarna een nieuwere versie instuurt! Je mag nooit je code aan een collega-student geven. Niet als inspiratie, niet om te helpen, niet om te testen, niet als backup, dus gewoon nooit! Je mag ook niet je code op openbare platforms op Internet zetten.
Als wij merken dat je een van deze dingen wel doet, wordt op z'n minst je opdracht ongeldig, maar strengere straffen kunnen ook. Is het halen van Datastructuren belangrijk voor je, zorg dan dat dit jou niet overkomt.

Waar zit het grootste "risico" voor fraude? Praktikumfraude komt in ongeveer driekwart van de gevallen voort uit tijdnood. Je zit vlak voor de DomJudge-deadline maar komt er niet uit, en je hebt wel de code van iemand anders bij de hand. Je wilde er alleen maar naar kijken en het dan zelf oplossen, maar ... de deadline komt dichterbij en je beseft dat je het niet gaat halen ... zonder een piepklein stukje code over te nemen. Als je het een beetje verandert merkt vast niemand dat, en je hebt toch echt wel begrepen hoe het werkt dus is dat nou zo erg? Over het eerste: bestaande code zo veranderen dat het origineel lijkt is meer werk dan nieuwe code schrijven. Over het tweede: ja, het is erg! Afgezien van de ethische kant (hoe hard verdien je een voldoende als je hem op deze manier haalt), als wij het merken ben je de opdracht sowieso kwijt en je behulpzame collega ook! Overnemen van code is dus ongeveer het stomste wat je kunt doen.
Dit samen met het doorgeven van je eigen code. Want je begrijpt uit dit verhaal dat als jij je code aan een vriendje geeft, en die verwerkt dat op een stomme manier in zijn programma, dan ben jij ook de klos! En hey, als jouw vriendje zo slim zou zijn om op een slimme manier te frauderen, dan kon hij die code ook wel zelf schrijven, toch?