TDDD92 AI-projekt

Rapportskrivningsguide

Den här guiden är tänkt som stöd för rapportskrivningen. Här hittar du mer information om det förväntade innehållet och strukturen, men vi tittar även på vanliga misstag och hur man undviker dem.

Omfattning och format

Omfattning och sidantal

Hur många sidor ska rapporten ha? Precis som i ett examensarbete är det viktigaste att rapporten innehåller den förväntade informationen och att den är skriven på ett lättläst och tydligt sätt, utan att vara onödigt komprimerad men också utan att sväva ut alltför mycket i onödigt långrandiga diskussioner.

Om man skriver på detta sätt räknar vi med att det behövs omkring 5-7 sidor text i ett typiskt konferensartikelformat med dubbla kolumner såsom det som används i vår rapportmall. Referenslistan kommer utanför detta. Har du många bilder eller diagram räknas det heller inte in i sidantalet (bilder är väldigt bra för förståelsen och vi vill inte att ni ska behöva utesluta illustrationer för att hålla sidantalet nere).

Skulle du känna att du har så mycket att säga att du vill ha någon sida till kan det vara OK, speciellt om det gör att hela rapporten blir mer lättläst eller att du får bättre underlag för de slutsatser du drar. Men då behöver du först se till att du skriver på ett "lagom kortfattat och koncist" sätt, så att rapporten inte blir längre på grund av överflödigt material.

Försök inte att anpassa formatet eller texten för att få en alltför rapport att se större ut eller tvärtom. Det minskar bara läsbarheten.

Rapportspråk

Du måste skriva på svenska eftersom rapporten även ska språkgranskas.

Rapportmall

En mall i LaTeX-format finns tillgänglig. Mallen ser till att det mesta i artikeln får ett konsistent format i fråga om marginaler och avstånd, typsnitt, storlekar, citeringar och så vidare. Mallen innehåller de tänkta sektionsrubrikerna, som liknar den standardiserade indelningen av vetenskapliga rapporter men delvis är anpassad till utredningens specifika behov. (Rapportmallen är baserad på den för IJCAI-19 Proceedings, en av de högst rankade AI-konferenserna. Vi har gjort några mindre förändringar, ändrat rapportstrukturen, satt pappersstorleken till A4 och lagt till stöd för svenska.)

Vissa rekommenderar Overleaf för att arbeta med LaTeX på webben. LiU har en premiumlicens för Overleaf; se studentnätet och Overleafs sidor.

Det är också tillåtet att använda alternativa format såsom Word, så länge som stilen i standardmallen efterliknas (i princip samma marginaler, stilar, radavstånd med mera). Tänk dock på att kursledarna inte kan ta på sig ansvaret för eventuella kommentarer om utseendet från IKOS om ni inte använder LaTeX-mallen.

Läsarens förväntade bakgrund

För att du inte ska behöva skriva i onödan, och läsaren inte ska få onödigt mycket att läsa, kan du hålla dig till dessa antaganden.

• Utgå från att läsaren redan känner till StarCraft II i allmänhet och kanske har spelat spelet i någon timme. Du behöver alltså inte beskriva de mer grundläggande tankarna bakom spelet eller tala om vad en Terran är, men räkna inte med att läsaren känner till en Ultralisk eller Unit Dancing.

• Utgå från att läsaren redan vet i vilken kontext du skriver rapporten: Du är medlem i en projektgrupp som bygger en agent som ska spela StarCraft II. Detta behöver inte beskrivas på nytt i rapporten. Om det ändå beskrivs, räknas det inte med i rapportens omfattning.

• Utgå från att läsaren liksom du har gått ett par år på U-programmet (och alltså är programmeringskunnig och allmänt "tekniskt kunnig"), och att läsaren redan känner till AI-begrepp motsvarande kursen TDDC17. Det finns alltså en hel del grundläggande AI-kunskap som normalt inte behöver repeteras i rapporten, inklusive grundläggande begrepp som agenter, sökning, planering, vägplanering med mera.

Innehåll och övergripande struktur

Det finns ett förväntat flöde i en utredning, och man behöver tänka på att följa detta flöde i rapporten och att tydligt separera olika aspekter av arbetet! Detta leder till olika avsnitt i projektrapporten. Avsnitten finns redan med i mallen, så titta gärna på den parallellt med att du läser här.

Avsnitt 1: Problemställning

Du ska redan ha en problembeskrivning från din arbetsplanering i HT1. Använd gärna den som grund, men arbeta vidare med en tydligare och mer formell beskrivning av problemet.

Spela StarCraft: Du ska beskriva ett problem i StarCraft. Ursprungligen kanske du var mer intresserad av att testa en viss AI-teknik och letade efter ett problem du kunde lösa med detta. Här måste du ändå beskriva det problem du hittade: Du vill se till att agenten kan göra något, åstadkomma något, bestämma något, ha en viss förmåga... för att den sedan ska kunna spela bättre.

Spela StarCraft: Problemet att "jämföra Q-learning med supervised learning" är inte något som direkt uppkommer från StarCraft utan handlar om att undersöka egenskaper hos tekniker, och är alltså inte ett bra problem att välja i den här kursen. Att göra "opponent modeling" (punkt) är inte tillräckligt specifikt och konkret. Hitta i så fall ett spelrelaterat problem vars lösning direkt bidrar till att spela bättre StarCraft, och där lösningen kanske fås genom Q-learning eller opponent modeling.

Tydligt för andra: Tänk dig att du i din slutliga rapport ska beskriva detta för någon annan, som är den som faktiskt ska lösa problemet och implementera lösningen utan att behöva kontakta dig för att reda ut detaljerna! Kanske den som löser problemet dessutom är lite lat och gärna missförstår dig kreativt. Kan du undvika det, då har du nog varit tillräckligt tydlig. (Ta gärna hjälp av andra för att se om de förstår din problembeskrivning!)

Tydliga begrepp: Definiera dina begrepp!

• "Jag vill veta vart jag ska gå" – när, i vilken situation, ...?

• Vad menar du mer exakt med "arbetare", "jobb", "plats", och så vidare (om du använder dessa begrepp)?

• Vad är egentligen "kostnad" i din problemställning?

• Om du arbetar med "byggnadsplacering", vad är egentligen det? Är problemet (1) jag tänker placera ut någon sorts byggnad av okänd typ och vill veta var den ska vara, (2) jag tänker placera ut en byggnad av typ X och vill veta var den ska vara, (3) jag tänker placera ut n byggnader och vill veta var de ska vara, ...? Eller arbetar du rentav med att bestämma vilken byggnad som ska placeras ut?

Tänk dig att någon annan ska lösa problemet utifrån din beskrivning – problemställningen är då en kravspecifikation som måste vara extremt tydlig för att den personen inte ska spendera veckor på att lösa fel problem! Otydlighet kan ofta leda till komplettering.

Problem på rätt nivå: På hög nivå har man kanske en vision att "agenten ska vinna oftare" eller att "marines ska överleva längre" – men det ligger på en så hög nivå och är så brett i sin definition att det inte ger dig någon särskild vägledning, och då blir det svårt för dig själv att styra ditt arbete åt rätt håll. Att "undvika fiender på väg från A till B" är närmare rätt nivå av problem.

Generaliserad problemtyp: Du får gärna koppla det specifika problemet till en generell (men väldefinierad) problemtyp – "Detta kan ses som ett planeringsproblem", "detta är en form av path finding", "detta är ...".

Kopplingar: Ange tydligt vilken information du tänker dig ska finnas tillgänglig ("indata", allt det som lösningsmetoden får använda sig av för att lösa problemet) och hur den definieras, samt exakt vad du tänker dig att en lösning skulle åstadkomma. Ska du skapa utdata som någon annan använder, och i så fall på vilken form? Eller ska du ge "styrsignaler" till resten av systemet (t.ex. styra en scout så att den hämtar in data)?

Motivering: Motivera också din problemställning. Tala om tydligt varför man vill kunna lösa det här problemet. Det övergripande målet är samma för alla -- ungefär att maximera möjligheterna att vinna i spel mot andra agenter eller människor -- så det behöver inte diskuteras här, utan problemställningen ska fokusera på hur man tänker sig att det "X" ska kunna bidra till detta. Varför är det överhuvudtaget relevant för StarCraft-agenten} att klara"X"?

Motivering: Vi rekommenderar mycket starkt att man baserar sin motivering på en eller flera specifika situationer i en spelomgång, helst med en eller flera skärmbilder: "Nu är spelet i detta läge, vi är i läge A och motståndaren i läge B, här försöker vi göra C och motståndaren vill göra D, i det läget är det viktigt att vi klarar av uppgift X, eftersom / för annars...". Att börja med detta kan också göra uppgiften och dess avgränsningar och krav mycket mer konkreta för dig själv och det kommer du själv att ha mycket nytta av!

Avsnitt 2: Utvärderingskriterier.

Under projektets gång ska man inte bara använda en AI-teknik, utan också utvärdera hur väl det gick att använda den.

Den här tanken behöver vi precisera i en uppsättning utvärderingskriterier. Vi hjälper er med tre gemensamma kriterier som alla ska använda, och som behöver beskrivas kort i avsnitt 2. Ni får gärna lägga till fler kriterier, men det är absolut inget krav. Kriterierna har inget att göra med vilka lösningstekniker man har hittat, så fortfarande hålls diskussionen fokuserad på problemet. Man ska t.ex. inte nämna något om inlärning, sökning, potentialfält, eller liknande.

1. Hur väl gick det att förstå, implementera och applicera den tänkta lösningsmetoden?

   Det kan till exempel vara mer eller mindre svårt att förstå hur metoden ska implementeras i Python-kod, mer eller mindre svårt att förstå vilka indata som krävs och hur man ska använda resultatet av metoden (utdata) i en agent, mer eller mindre svårt att få fram indata givet den ofullständiga information man har tillgänglig, med mera.

2. Hur väl verkar lösningsmetoden kunna lösa exakt det problem som ställdes upp? Med andra ord, givet att det gick att förstå och implementera metoden, hur bra blev lösningen på det specifika problemet (t.ex. att skapa en bra byggnadsordning)? Om det inte gick så bra, tror du det beror på metoden eller t.ex. tidsbrist vid implementationen? Varför?

3. Hur väl verkar lösningsmetoden kunna bidra till att agenten blir bättre på att spela StarCraft? Detta är ganska nära kopplat till den förra punkten, och i vissa fall kan man tänkas hänvisa direkt till svaret på den punkten. Det kan också tänkas att man t.ex. får en bra lösning på det specifika problemet (att undvika fiender på väg från A till B), men att det till slut inte påverkar agentens förmåga att vinna särskilt mycket.

4. Kanske något eget kriterium som är viktigt för ditt problem?

   Tänk i så fall på att "ja/nej"-kriterier kan vara för grovkorniga och kan vara svåra att utvärdera. "Kan algoritm X implementeras"? Ja, det kan den väl. "Kan teknik Y lösa problemet"? Kanske det, men det är mer intressant att få reda på hur väl den löser problemet.

   Var tydlig i definitionen, så man kan förstå exakt vad kriterierna betyder. Om du diskuterar tidskrav, diskutera då tydligt vad du menar. Ska det köras på 1/60 sekund? Ska det kunna uppdateras på 1 sekund inför att man kör igång spelet? Vad är "snabbt" egentligen?

   Skilj också t.ex. på att maximera sannolikheten att få information och att maximera mängden information man förväntas få. Tänk dig gärna att du definierar kriterierna för någon annan som ska utvärdera teknikerna. Otydligheter om vad som egentligen ska utvärderas kan göra att fel teknik kommer att väljas för projektet!

Kriterierna är numrerade och ska vara det även i rapporten, så du på ett tydligt sätt kan hänvisa till dem i utvärderingen. Kriterium 1--3 behöver ingen närmare förklaring utöver de tre frågor som redan står i mallen, eftersom de är samma för alla. Om du lägger till flera kriterier måste de förklaras betydligt noggrannare!

Avsnitt 3: Tekniker och algoritmer

Du behöver nu förklara vilka tekniker och algoritmer som har använts.

Till skillnad från tidigare år behöver dessa inte förklaras i sin helhet eller beskrivas med t.ex. fullständig pseudokod, då detta tar onödig tid från resten av projektet. Det som behövs är att du tydligt förklarar följande för läsaren vilken teknik som har använts och vilket problem den tekniken egentligen löser.

Exempel: Anta att du hade ett problem som du ville försöka lösa genom en sorteringsalgoritm. (Vi väljer detta som exempel just för att det inte alls kvalificerar sig som en AI-teknik!) Då skulle du t.ex. kunna ha med följande information, men givetvis skrivet i löpande text:

• För att lösa problemet har du använt en sorteringsalgoritm.

• Närmare bestämt: Bubble Sort (referens!) och QuickSort.

• En sorteringsalgoritm tar innehållet i en lista och sorterar det enligt något lämpligt kriterium. Till exempel kan de sortera en lista med strängar i alfabetisk ordning. De gör detta genom att stegvis byta plats på element i listan till den är helt sorterad.

Du behöver som sagt inte ha med fullständiga algoritmbeskrivningar eller pseudokod, utan det viktiga är att läsaren kan förstå vilket specifikt problem algoritmen löser. Algoritmer och pseudokod är dock tillåtet om du tycker att det är ett bättre eller enklare sätt att förmedla den förståelsen.

Du får gärna använda figurer för att förklara. Det går bra att ha med figurer från källartiklar så länge som figurerna citerar artikeln, t.ex. genom en citering i figurtexten.

Utvärdera inte ännu. Det finns ett separat avsnitt även för detta. Blanda alltså inte in några egna värderingar av teknikerna ännu, utan håll dig helt och hållet till en objektiv beskrivning av valda tekniker utan att explicit koppla det till StarCraft II.

Avsnitt 4: Modellering och användning i StarCraft II

Från problemställningen vet vi redan problemets indata och utdata. Du kanske till exempel har en lista på n byggnader och vill lösa problemet att konstruera dessa byggnader så snabbt som möjligt med de resurser som finns tillgängliga.

Nu vill vi se hur man kan applicera din valda AI-teknik på ditt problem. Kanske du har valt att använda A*-sökning, och den behöver indata bestående av en sökrymd (med noder och handlingar), en kostnadsfunktion och en admissible heuristik. Du måste alltså modellera ditt problem på det sätt som AI-tekniken vill. Du behöver också diskutera hur svaret används – någon som använder Bayesianska nätverk kan räkna ut en uppsättning sannolikheter, som sedan behöver användas för att lösa det ursprungliga problemet.

Du behöver därför beskriva hur en vald teknik skulle kunna tänkas appliceras. Här är några exempel på den information som kan behövas. Exemplen kan vara ofullständiga!

• Vid användning av sökalgoritmer som A*: Hur genereras en graf att söka i -- exakt vilka är tillstånden och bågarna, så att någon annan kan återskapa exakt samma graf utan att ha tillgång till din kod? Vad är start- och målnoderna? Vilken kostnadsfunktion används för att avgöra hur dyr en båge är (formel)? Om du använder A* eller liknande informerad sökmetod, vilken heuristikfunktion används (formel), och hur kan du visa att den är admissible?

  Det kan också vara intressant att veta hur detta integreras. Hur kommer man fram till grafen utifrån det API som man använder i StarCraft II? Vad är det som ska röra sig enligt den väg som genereras?

• Bayesianska nätverk: Här behöver man också veta exakt hur noder/variabler, bågar/nätstrukturer och kostnader definierades. Det gäller inte bara att veta vilka värden som används, utan varför / var det kommer från.

• Potentialfält: Exakt hur beräknas potentialen i varje punkt (formel), och vad motsvarar detta rent intuitivt? Vilka punkter/rutor finns? Hur påverkar potentialen sedan spelet och de beslut som tas? Används den som bas för en kostnadsfunktion i A* (hur?), eller styr den direkt vart man går (hur?), eller hur används den? När räknas potentialerna om utifrån förändrade förutsättningar?

• Regionsindelning: Finns det några parametrar du har valt på ett speciellt sätt? Finns det annat som påverkar modelleringen?

• Maskininlärning: Vad har du använt för grunddata för inlärningen? Vilka features har du baserat inlärningen på (vid vissa typer av inlärning)? Hur har inlärningen gått till? Vad blev resultatet? Vid Q-learning, vilka tillståndsstrukturer användes, vilka belöningar gavs, vilka vilken policy blev resultatet? Vid inlärning med Bayesianska nätverk, vad blev de inlärda sannolikheterna?

• Replays och andra externa data: Om du har använt sådant, tala då om både var det kommer från och vilka replays du har använt. (Om detta tar mycket plats går det bra att ta extra sidor till en tabell på slutet.)

I samtliga fall är det viktigt att beskriva modelleringen tydligt och precist. Det är absolut också viktigt att ge intuitioner, men detaljerna måste också finnas med. Vi är inte ute efter en ungefärlig beskrivning för att kunna se att "det låter väl rätt rimligt att göra ungefär så här". Vi är snarare ute efter att:

• Förstå i detalj vad du har gjort och varför resultaten blev som de blev. Det behövs precision i informationen för att kunna analysera och förstå anledningarna till ett resultat, t.ex. analysera varför maskininlärningen tog så lång tid – eller avgöra om dina slutsatser om resultatet verkar rimliga. Samma sak gäller att förstå exakt vad det var som egentligen fungerade.

• Åtminstone i teorin kunna upprepa det du gjorde genom att följa dina instruktioner! Reproducibility is a major principle underpinning the scientific method. With a narrower scope, reproducibility has been introduced in computational sciences: Any results should be documented by making all data and code available in such a way that the computations can be executed again with identical results. [Wikipedia] Vi kommer inte att nå riktigt ända dit, men ha den tanken i bakhuvudet. Exempel: Istället för att beskriva ungefär vad en heuristik baseras på, beskriv den exakta formeln.

Mer som är bra att veta:

• Beskriv gärna andra alternativ du har undersökt, om det finns sådana. Du kanske till exempel har arbetat mycket med en alternativ problemmodellering som visade sig ge problem, eller med andra parametrar som gav sämre resultat.

• Förklarande diagram och figurer är starkt rekommenderade.

• Tabeller och listor i punktform kan ofta vara tydligare än löpande text om man t.ex. ska beskriva alla bågar och sannolikheter i ett nätverk, alla handlingar tillgängliga för en planerare, och så vidare. Använd dem gärna om det blir tydligare än att söka genom ett långt stycke löpande text efter informationen.

Avsnitt 5: Kopplingar till övrig implementation

Är din implementation (alternativt dess in/utdata) kopplad till andra tekniker eller andra gruppmedlemmars individuella arbete? I så fall, hur? Vilka data får du från vem? Vilken information ger du till vem? Eller är den i princip fristående från övriga specifika AI-tekniker?

Hur är den i övrigt inkopplad i agenten som en helhet, så att den faktiskt används när agenten spelar?

Notera att "hur" är tänkt att tolkas på en högre abstraktionsnivå. Vi är inte intresserade av vilka Python-funktioner som anropar varandra, utan av hur teknikerna fungerar ihop, hur de hjälper varandra, hur de beror på varandra, vilken sorts information de ger och får – eller som ett alternativ, hur och varför de kan användas helt oberoende av varandra utan att den ena behöver känna till den andra. Ett enkelt diagram kan ofta vara bra för förståelsen.

Diskutera gärna hur integration och "inkoppling av funktionaliteterna" har påverkat ditt arbete. Finns det till exempel ytterligare krav som ställs på din teknik för att integrationen ska fungera? Har förenklingar skett genom att fler personer kan dela på implementerad funktionalitet?

Avsnitt 6: Resultat och utvärdering

I detta avsnitt är det dags att beskriva resultatet och utvärdera det. Detta är också en mycket viktig del: Att kunna utvärdera tekniska lösningar är ett av de uttryckliga kursmålen som måste examineras!

Tänk på att vi inte är ute efter subjektiva värderingar utan fokusera på en motiverad och objektiv bedömning av det tekniska resultatet. Det kan göras på flera nivåer:

• Direkta resultat för din AI-teknik, i isolering.

  Om du har arbetat med att hitta flaskhalsar, vilka flaskhalsar hittas då i några olika kartor? Om du har arbetat med att hitta vägar från A till B, vilka vägar hittas då i några olika scenarion? Är dessa resultat bra eller dåliga? Varför?

  Har ditt arbete resulterat i en annan byggnadsordning, och i så fall hur? Är den bättre eller sämre och i så fall varför? "I och med att vi bygger i en bättre ordning händer X och det bör hjälpa oss mot fienden genom Y."

  Hur lång tid tar det att köra algoritmen? Är det rimligt utifrån när algoritmen behöver köras?

• Resultat för agentens spelkvalitet.

  Om du har arbetat med att hitta flaskhalsar, blev agenten bättre på att spela StarCraft på något märkbart sätt? I så fall, hur mycket, på vilket sätt, och varför? Blev den till och med sämre, eller hände ingenting? (Hur vill du mäta detta -- genom att spela ett antal spelomgångar mot en alternativ agent?)

• Slutlig utvärdering enligt utvärderingskriterierna.

  Diskutera och motivera hur väl varje vald teknik uppfyller varje angivet kriterium.

  Gå genom alla de numrerade kriterierna du satte upp, och se till att samtliga kriterier faktiskt utvärderas i tur och ordning, för samtliga tekniker / lösningar som ingår i din studie. För att det ska vara lätt att hitta påbörjar du gärna ett nytt stycke för varje kriterium.

  Var extra noga med att ge argument för alla påståenden, och ge exempel som tydliggör vad som menas. Det räcker inte att säga vad man tycker, utan man behöver motivera varför läsaren borde hålla med.

Tydliga och välmotiverade utvärderingar

När vi säger "hur mycket, på vilket sätt, varför?" menar vi också att vi vill se tydliga beskrivningar av resultaten och hur de yttrade sig i spelet.

Går det att se hur mycket oftare man vinner? "Lite oftare", är det 10% oftare eller 50% oftare?

Ofta går det att beskriva mer kring skillnaderna: "förut gjorde den så här men med den nya tekniken beter den sig så här istället"... med en del detaljer som gör att man förstår det hela, och varför det inträffar.

Det handlar alltså inte bara om en allmän slutsats om att "det gick väl bra", utan om att visa hur man uppfyller lärandemålet att kunna utvärdera AI-tekniker och hur de påverkar ett system.

Ärliga och opartiska utvärderingar

Meningen med utvärderingen är inte att motivera varför den egna lösningen är bra. Vi fokuserar inte på "prestationen", eftersom vi är medvetna om att kurstiden inte räcker för att man ska uppnå den perfekta implementationen, och mycket kan hända som man inte har kontroll över.

Det handlar mer om att analysera varför den allmänna tekniken och den specifika implementationen gav vissa resultat, än om att analysera varför man själv kom dit man kom.

Det handlar inte heller om att man måste motivera varför det egna arbetet gjorde att agenten spelade mycket bättre. Det kan hända att det inte alls blev bättre. Beskriv detta och utvärdera varför det blev som det blev!

Lagom starka slutsatser

Det är viktigt att komma fram till slutsatser av rimlig styrka, varken alldeles för starka eller alldeles för svaga. Försök hitta en lagom nivå, och argumentera sedan för dina uttalanden så att läsaren övertygas om att det du faktiskt säger verkar korrekt.

Skriv till exempel inte "X är definitivt bra på kriterium Y" om du bara har underlag för "X kan nog vara ganska bra på kriterium Y, men det finns en del osäkerheter av dessa anledningar". Om det inte finns mer evidens än så, är det ju detta som är den korrekta utvärderingen.

Bara resultat och utvärdering

Varje avsnitt har sitt eget ämne, och här handlar det om just utvärdering.

Om du under utvärderingen kommer på att det saknas information om hur teknikerna och algoritmerna fungerar eller om hur du har applicerat dem, försök då lägga in den informationen i motsvarande tidigare avsnitt – inte här.

Avsnitt 7: Egna slutsatser kring AI-tekniker

Här kan du dra egna slutsatser kring ditt arbete med AI-tekniker i projektet. Hur svårt var det att applicera en viss teknik? Gick det som du förväntade dig? Avsnittet behöver inte vara särskilt långt.

Avsnitt 8: Insatser i gemensamt arbete

En kort beskrivning / sammanfattning av vad du har gjort i den gemensamma implementationen och ungefär hur stor del av tiden du har lagt på den aspekten av agenten.

Om referenser och plagiat

Utredningen ska baseras på vetenskapliga artiklar. Alltså behöver man hitta sådana artiklar och även referera till dem på lämpliga ställen i texten.

Vi skriver "artiklar" i plural, eftersom en utredning av den här typen normalt inte kan baseras bara på en enda artikel. Ett normalt antal kan vara 3-5 olika referenser (varav någon kan vara en bok), i vilka man t.ex. kan hitta olika information om samma lösningstekniker, eller mer information om flera olika tekniker.

Vi kommer inte att kräva att ni hittar den allra "bästa" eller nyaste artikeln att referera till. Kursen är inte tillräckligt stor för att ni ska kunna lägga ner ett enormt arbete på det (skulle lätt kunna ta en hel termin att göra en rejäl undersökning). Istället är det viktigaste att man kan utvärdera på ett bra sätt efter de relevanta referenser och studier man faktiskt har tillgång till.

Om du märker att information som du är intresserad av saknas i litteraturen, eller att underlaget inte räcker till, får du gärna (kortfattat) nämna vad du inte har kunnat ta reda på. Det visar att du inte bara missade viktiga aspekter, utan att informationen saknades.

Att citera en referens

Under föreläsningen om rapportskrivande kommer IKOS att diskutera korrekt sätt att citera en referens. Rapportmallen har även exempel på hur det går till rent tekniskt.

I vetenskaplig litteratur, och i era rapporter, bör man också tänka på att citera rätt referens. Referenser ger en form av "credit" till författaren, och då är det viktigt att man hellre citerar den som ursprungligen kom fram till något (eller utvecklade en algoritm) istället för någon som senare skrev om det. Det är också en anledning till att man hellre citerar en artikel än en (kurs)bok.

Citering, parafrasering, och plagiat

För att undvika ofrivilligt plagiat: Läs på om att referera, citera och parafrasera i universitetets "NoPlagiat"-självstudie. Den kan nås från årets Lisam-sida, under "Test".

NoPlagiat är en självstudieguide om plagiering och upphovsrätt som hjälper dig undvika vanliga misstag när man skriver rapporter. Se till att gå igenom modulen tidigt så att du hinner använda modulens lärdomar. Det krävs 100% rätt svar för att bli godkänd på NoPlagiat-modulen, vilket är en förutsättning för inlämningen. Med andra ord, det blir ingen granskning innan NoPlagiat-kravet uppfylls.

Även om du inte genomgår hela NoPlagiat-studierna behöver du veta hur man ska använda citeringar. Det räcker t.ex. inte bara att en artikel refereras till någonstans i texten, utan man behöver veta vad som kommer från just den artikeln, genom hela rapporten!

Var alltså mycket noga med att skilja på vad som är ditt material (dina egna åsikter och slutsatser) och vad som är taget mer eller mindre direkt från artiklarna. I vetenskapliga artiklar som bygger på andras material är det ofta tätt mellan referenserna. Om du plockar information från samma artikel på 20 olika ställen är det rätt att referera till artikeln på alla dessa 20 ställen, så det blir tydligt var informationen kommer från!

Språk och struktur

Läs till exempel genom informationen om rapportstruktur en gång till. Kör också rapporten genom en stavningskontroll, och om möjligt en grammatikkontroll. Tänk på tydligheten och försök undvika syftningsfel, svengelska, med mera.

Här nedan ger vi några tips anpassade till just TDDD92.

Språk och struktur: Terminologi och tekniska begrepp

Några allmänna tips om ord och begrepp som man kan ha missförstått:

• Optimal = perfekt. Ibland vill man ha "bra" och kräver inte "optimal".

• Tidskomplexitet = hur tidsåtgången varierar med storleken på problemet. Sortering kan göras med tidskomplexitet n log n, där n är antalet element. Ibland vill man undersöka ungefärlig uppskattad tidsåtgång snarare än formell tidskomplexitet.

• Var noga med skillnad mellan olika tekniska begrepp som tillstånd, stokastiska variabler vars värden är tillstånd, med mera. Och om du pratar om tillstånd, vilken sorts information ingår i ett tillstånd?

• Använd genomgående samma ord för att beskriva samma sak. Kalla inte något ett "område" ibland och en "zon" ibland; i tekniskt skrivande är vi inte ute efter variation, utan vill ha maximal tydlighet.

Språk och struktur: Skrivfel och oversittings

Några andra tips...

• eftersom att -- korrekt är "eftersom" eller "för att" eller "på grund av att".

• "Human" = mänsklig i betydelsen god, barmhärtig, "inte grym".

• "Flertalet" = "de flesta" -- "ett flertal" = "många"

Språk och struktur: Svengelska

Här samlar vi en del tips för att undvika svengelska i just TDDD92-rapporter.Om du undrar över översättningen av något ord som inte finns med här: Sök gärna på nätet och fråga oss annars.

Om ett ord inte kommer genom din stavningskontroll (för en sådan gör du väl?) kan det bero på att det är svengelska.

• Bayesian networks - Bayesianska nätverk (uppkallat efter Thomas Bayes)
• Hidden Markov Model - dold markovmodell
• Hungarian method - ungerska metoden
• Q-learning - Q-inlärning eller Q-learning i kursiv stil
• action - handling (inte aktion!)
• back propagation - bakåtpropagering
• barracks - kasern (en barack är något annat)
• branch-and-bound -- översätts inte, skrivs i kursiv stil. "Branch" är att förgrena ut sökningen i ett sökträd, "bound" är att begränsa längden på grenarna då man ser att man inte kommer att kunna hitta bättre lösningar i den gren man arbetar med.
• breadth first - bredden först (bredden-först-sökning)
• build order - byggordning
• choke point - finns ingen perfekt översättning; kan skriva flaskhals ("choke point")första gången det används, och sedan använda flaskhals, så har man kopplat det tydligt till ursprungsbegreppet och det blir varken missförstånd eller svengelska.
• concept - begrepp (oftast -- "koncept" kan ha en något annorlunda betydelse!)
• constant - konstant
• depth first - djupet först (djupet-först-sökning)
• determine - t.ex. bestämma (inte determinera)
• deterministic - deterministisk
• discretization - diskretisering
• edge - båge
• entries - poster
• flow fields - flödesfält
• fuzzy set - suddig mängd, oskarp mängd (motsatsen kan kallas "skarp mängd")
• gradient descent - gradientsökning
• graph - graf
• greedy - girig
• grid - rutnät
• grid cell, cell - ruta
• harvest - skörd, skörda
• hidden layer - gömt/gömda lager
• layer - lager
• make a decision - ta (ett) beslut (inte "göra")
• map editor - karteditor
• marine - marinsoldat
• node - nod
• ordered pair - ordnat par (som har en ordning)
• potential fields - potentialfält (inte "potentiella"!)
• potential flow - potentialflöde
• range - räckvidd (om det handlar om att nå fienden med vapen)
• ratio - kvot
• reinforcement learning - förstärkningsinlärning (inte "förstärkt inlärning")
• reward - belöning
• scouting - utforskning, patrullering, rekognosering
• simplify - förenkla (inte simplifiera!)
• space - rymd (state space = tillståndsrymd)
• state - tillstånd
• state variable - tillståndsvariabel
• supervised learning - övervakad inlärning
• supply depot - depå, förråd, lager
• temporal - temporal
• temporary - temporär
• time step - tidssteg
• unit - enhet
• unit collision - att man kolliderar med en annan enhet
• utility function - nyttofunktion
• variable elimination - variabeleliminering
• weighted - viktad
• win/lose - vinna/förlora

Samtidigt finns också en del terminologi där det inte finns någon vedertagen svensk översättning. Där kan det vara minst förvirrande att fortsätta använda de engelska orden. Det kan rekommenderas att sätta dem i kursiv stil, reaper, eller inom citattecken, "reaper", för att markera att man använder specifika termer snarare än att man bara har missat att översätta något.

• Tekniker och algoritmer med "egennamn", som Q-learning, reinforcement learning, supervised learning, ...
• Reaper, marauder, ... -- dessa kan vi också se som egennamn som man inte nödvändigtvis förstår om man översätter dem "direkt". Ett undantag är marine som bör översättas till marinsoldat.
• Kiting
• ...

Att få hjälp att skriva

Skulle du behöva hjälp med språket? Kanske Språkverkstaden kan ge några tips. De hjälper dock inte till med korrekturläsning. Se även studentsidan om språkstöd.

Är du dyslektisk eller har andra läs- och skrivsvårigheter? Informationen vi har fått är att din rapport ändå måste nå upp till rätt nivå rent språkligt, eftersom rapporten inte bara är en projektrapport utan även ingår i ett språkmoment i kursen. Detta är alltså ett centralt beslut som vi själva inte bestämmer över. Däremot kan du som har diagnosticerade språksvårigheter kanske få mer hjälp från Språkverkstaden. Du kan också be om utförligare kommentarer från IKOS när du gör din inlämning.