Eksamen

def foo(bar):
    ham = bar[0]
    for egg in range(1, len(bar)):
        glass = bar[egg]
        if ham >= glass:
            return False
        ham = glass
    return True

Hva slags funksjon er dette?

• Forklar hva funksjonen gjør.
• Koden over har dårlige variabel- og funksjonsnavn, som gjør den vanskelig å lese og forstå. Forklar rollen til de ulike variablene i koden over, og foreslå nye, selvbeskrivende navn for variabel- og funksjonsnavn.

PS: svar gjerne med en tabell (kopier og fyll ut):

Maksimalt 600 ord.

Demonstrert forståelse (5 poeng):

• Argumentet til funksjonen er forventet å være en samling av ting
• Iteranden i løkken representerer en indeks
• Variablene «ham» og «glass» representerer ulike elementer i samlingen
• Funksjonen sammenligner elementer som ligger rett etter hverandre i ordningen. Dersom kandidaten på et eller annet vis kommuniserer at funksjonen sjekker om listen er sortert, skal dette punktet og punktene over alle regnes som forstått.
• Funksjonen returnerer True hvis hele samlingen av ting er strengt sortert (altså er sortert og alle elementene er ulike).

Fornuftige variabelnavn (5 poeng):

• foo: strictly_increasing, is_increasing, alphabetic, is_sorted osv er alle fullt godkjente.
• bar: elements, things, values, numbers, num_list, the_list, array, arr, words, names, strings, items, data_list og så videre er alle godkjente. Det er også godkjent med kun «a» med henvisning til konvensjon. Det er derimot ikke godkjent å bruke «list» som variabelnavn; selv om dette forsåvidt gir full uttelling for forståelse, er «list» navnet på en klasse i Python, og brukes f. eks. når man konverterer til liste (list('abc') == ['a', 'b', 'c']) eller for å opprette en tom liste (list())
• egg: i tillegg til «i» er også forslag som index og position godkjente. Ikke godkjent er forslag som iterand, element, value og lignende.
• ham: previous, prev_element, early_item, old_value, eller lignende. Noe som på en eller annen måte indikerer at det er et element som har en tidligere plass i ordningen.
• glass: value, current, this_element, later_item, new_value eller lignende. Noe som på en eller annen måte indikerer at det er et element i samlingen.

Poeng for «ham» og «glass» må sees i sammenheng; ett poeng hvis minst ett av navnene indikerer at dette er elementer i samlingen, to poeng hvis navngivningen til sammen indikerer rekkefølge på elementene.

Norske variabelnavn er OK så lenge man er konsekvent (ved blanding av norske og engelske variabelnavn scores besvarelsen som normalt, men maks poeng er 9/10).

Sensor kan gjøre en skjønnsmessig justering dersom kandidaten på andre måter demonstrerer vesentlig mer eller mindre forståelse enn hva rubrikken legger opp til.

Et gammelt jungelord sier at programmering består av 10% koding og 90% å forstå hvorfor det ikke virker. I denne oppgaven fokuserer vi på de siste 90%.

Du har nettopp slengt sammen et Asteroids-spill med god hjelp av kunstig intelligens. Spillet ser ut til å virke som det skal helt til en kule treffer en stein. Da krasjer spillet med denne feilmeldingen:

Traceback (most recent call last):
  File "/path/to/asteroids.py", line 55, in timer_fired
    check_bullet_hits(app)
  File "/path/to/asteroids.py", line 132, in check_bullet_hits
    x, y, radius, _, _ = app.stones[j]
                         ~~~~~~~~~~^^^
IndexError: list index out of range

Oppførselen vi beskriver over skjer de fleste ganger, men ikke alltid: av og til klarer skuddet faktisk å skyte bort steinen.

Kildekoden for spillet ligger i vedlagt pdf.

Forklar:

• Hva betyr feilmeldingen? Forklar all informasjonen feilmeldingen gir oss.
• Hva er grunnen til at feilen oppstår? Hvorfor krasjer ikke spillet hver eneste gang en kule treffer en stein?
• Hvilke mulige løsninger ser du for deg? Du skal ikke skrive kode, men forklare med ord og relevante fagbegreper hva som er mulige løsninger og hvordan de vil løse problemet.

Hva betyr feilmeldingen? Forklar all informasjonen feilmeldingen gir oss.

• Feilmeldingen forteller at indeksen j er for stor eller for liten («out of range»), slik at det ikke finnes noe element i denne posisjonen i app.stones.
• Vi ser også at app.stones er en liste («list index out of range»).
• Krasjen skjer på linje 132, som er en del av funksjonen check_bullet_hits i filen asteroids.py.
• Funksjonen check_bullet_hits ble kalt på linje 55, som er en del av funksjonen timer_fired i filen asteroids.py.

Hva er grunnen til at feilen oppstår?

Listen app.stones blir kortere underveis i for-løkken hvor j er iteranden (.pop fjerner jo et element fra listen). Hvilke verdier løkken skal iterere gjennom ble derimot bestemt før løkken egentlig startet, nemlig da uttrykket range(len(app.stones)) ble evaluert. Når løkken kommer til siste iterasjon viser iteranden j altså til siste indeks i app.stones slik den var da løkken startet. Men fordi den har krympet underveis, er indeksen for stor, og programmet krasjer.

(forøvrig har koden akkurat samme bug når det gjelder app.bullets og løkken med iteranden i)

Hvorfor krasjer ikke spillet hver eneste gang en kule treffer en stein?

Programmet vil ikke krasje her dersom steinen som treffes er den siste steinen i listen.

Hvilke mulige løsninger ser du for deg?

Jeg ser for meg flere mulige løsninger:

1. Returner fra funksjonen med en gang vi finner en stein truffet av en kule. Funksjonen vil riktignok kun fjerne én stein og én kule, men siden funksjonen kalles veldig ofte er det ikke så lenge til neste gang den kalles at det vil være noe problem i praksis. I teorien vil vi kunne få situasjoner der en kule flyr gjennom en stein uten å ødelegge den, så den er ikke helt idéell.

2. Kall en hjelpefunksjon som fjerner første funnede treff i en while-løkke. Dette er i grunnen den samme løsningen som nummer (1), men vi lar funksjonen returnere True hvis den fant en treff og fjernet stein/kule og False hvis ikke. Så bruker vi den som en hjelpefunksjon, og kaller på den i en while-løkke helt til den returnerer False.

3. Bruk break for å avbryte løkken når en stein er truffet. Det er en rimelig antakelse at én kule kun treffer én stein – så når vi har funnet en truffet stein er det strengt tatt ikke behov for flere iterasjoner av den indre løkken som går gjennom steinene, og vi kan bruke break for å avslutte løkken tidlig. Denne løsningen gjør forsåvidt at problemet med krasj på linje 132 forsvinner, men løser ikke det tilsvarende problemet som er gjeldende for app.bullets og i i den ytterste løkken.

4. Legg steiner og kuler som skal fjernes i egen liste først. Vi bruker først en løkke lignende den vi allerede har for å identifisere hva som skal fjernes av steiner og kuler, men i stedet for å fjerne («poppe»), legger vi istedet det som skal fjernes i egne lister over «markerte» steiner/kuler. Deretter har vi ekstra løkker etterpå for å fjerne de markerte steinene/kulene.

5. Opprett nye lister over kuler og steiner i stedet for å mutere eksisterende liste. Vi kan først opprette en ny liste som inneholder alle steiner som ikke er truffet av noen kule, og tilsvarende en ny liste av alle kuler som ikke er truffet av noen stein, og så la app.bullets og app.stones vise til disse nye listene. Det er i så fall aktuelt med hjelpefunksjoner stone_is_hit(single_stone, list_of_bullets) og bullet_hit_something(single_bullet, list_of_stones) for å avgjøre hvilke kuler og steiner vi skal ta vare på. Alternativt kan vi også gjøre som i løsningsforslag (4) først, og deretter lage de nye listene over kuler og steiner med de elementene som ikke er markert.

6. Gå gjennom indeksene baklengs. I stedet for at løkkene begynner med den første indeksen og beveger seg oppover, kan vi i stedet begynne med den høyeste indeksen og gå nedover. Da får vi ikke problemer når listen blir kortere, siden elementene som får nye indekser etter popping er de elementene som allerede er ferdig sjekket. For å gjøre dette kan vi bruke en range med negative steg, f. eks. range(len(app.stones) - 1, -1, -1) i stedet for range(len(app.stones)) og range(len(app.bullets) - 1, -1, -1) i stedet for range(len(app.stones)). En annen variant av dette er å bruke negative indekser når vi henter ut elementer, dvs bruke app.stones[-j-1] i stedet for app.stones[j] og app.stones.pop(-j-1) i stedet for app.stones.pop(j) (og tilsvarende for i og app.bullets).

7. Bruk while-løkker. Ved å bruke while-løkker i stedet for for-løkker har vi større kontroll på hvordan indeksen endrer seg fra iterasjon til iterasjon. Betingelsen i while-løkker (typisk i < len(app.bullets) og j < len(app.stones)) sjekkes dessuten på nytt i hver iterasjon, slik at hvis lengden på listene minker underveis, vil løkken også gjøre færre iterasjoner. Det kan imidlertid oppstå feil ved at noen sjekker «hoppes over» om vi ikke er forsiktig med hvordan indeksene økes: når vi fjerner noe fra en liste, vil resten av listen flytte seg nedover, så å øke indeksen vil hoppe over elementet som ble flyttet ned. Vi kan ta høyde for dette ved å kun inkrementere indeksene dersom vi ikke fjernet. Uansett om vi ikke tar høyde for dette, vil feilen være av begrenset betydning i praksis, siden funksjonen kalles på nytt mange ganger i sekundet.

Hva betyr feilmeldingen? (4 poeng)

• Listen er for liten for indeksen som benyttes (2 poeng).
• Identifiserer at krasjen skjer på linje 132, eller identifiserer at feilen skjer som en del av et funksjonskall til check_bullet_hits (1 poeng).
• Identifiserer at funksjonskallet til check_bullet_hits ble gjort på linje 55, eller at det ble gjort som en del av timer_fired (1 poeng).

Hva er grunnen til at feilen oppstår? Hvorfor krasjer ikke spillet hver eneste gang en kule treffer en stein? (3 poeng)

• Listen blir kortere underveis i løkken (2 poeng).
• Programmet vil ikke krasje her dersom steinen som treffes er den siste steinen i listen (1 poeng).

Hvilke mulige løsninger ser du for deg? (4 + 1 poeng)

• Et løsningsforslag som ikke fungerer gir 0-1 poeng basert på sensors skjønn.
• Et løsningsforslag som vil fungere greit i praksis, men som i teorien har noen svakheter (f. eks. å returnere fra funksjonen etter første treff) gir 2 poeng hvis det presenteres uten å påpeke svakhetene, men gir 3 poeng hvis svakhetene drøftes.
• Et fullverdig løsningsidé gir 4 poeng. Løsningen trenger ikke beskrives i pinlig detalj, så lenge idéen er kommunisert (for eksempel er det tilstrekkelig å si at vi kan gå gjennom listene baklengs i stedet for fremlengs uten å gå i detalj om hvordan dette gjøres.)

I tillegg

• Løsningsforslaget tar hensyn til funksjonen som helhet og retter også opp identisk bug/den delen av bug’en som er knyttet til app.bullets og ytterste løkke. Poenget deles ut så lenge kandidaten viser forståelse for at samme bug gjelder for app.bullets og ytre løkke, eller om løsningsforslaget implisitt tar slike hensyn. (1 poeng).

Helhetsvurdering (3 poeng). Poengene i denne kategorien deles ut helhetlig, ikke punkt for punkt. Sensor kan bruke dennne kategorien for å trekke opp eller ned kandidater som demonstrerer større eller mindre forståelse enn hva rubrikken forøvrig tilsier. Sensor ser etter:

• Det er lett å forstå hva kandidaten mener.
• God/relevant bruk av faguuttrykk.
• Demonstrerer forståelse av koden og mulighetene for endring.

Skriv en kodesnutt slik at minnets tilstand blir som vist over. Du vil ikke få trekk i poeng dersom du definerer andre variabler i tilegg.

Klikk på «se steg» -knappen for å verifisere at denne koden gir riktig bilde av minnet.

a = [1, 2, 3]
b = a
c = [[1, 2, 3], a]

temp1 = [1, 2, 3]
temp2 = [1, 2, 3]

a = temp1
b = temp1
c = [temp2, temp1]

c = [[1, 2, 3], [1, 2, 3]]
a = c[1]
b = c[1]

a = b = [1, 2, 3]
c = [[1, 2, 3], a]

• 1 poeng hvis a og b begge er like [1, 2, 3] og c er lik [[1, 2, 3], [1, 2, 3]]
• 1 poeng hvis a og b er aliaser
• 1 poeng hvis c[1] er alias med a og b, mens c[0] ikke er alias med hverken a eller b.

Sensor har anledning til å gjøre en skjønnsmessig justering i tilfeller der det er gjort feil disse testene ikke tar høyde for. Poengsummen som beskrevet over kan regnes ut med følgende kode:

points = sum([
    a == b == [1, 2, 3] and c == [[1, 2, 3], [1, 2, 3]],
    a is b,
    c[1] is a is b and a is not c[0] is not b,
])
# PS: i kontekst av matematisk aritmetikk regnes True som 1 og False som 0.

I denne oppgaven skal vi mutere oppslagsverk der noen av nøklene begynner med 'lab' mens andre ikke gjør det. For eksempel:

{
    'student_name':	'Kari',
    'lab1':	20,
    'lab2':	22,
    'lab3':	23,
}

Vi vet ikke hvor mange nøkler det er eller hvor mange av dem som begynner med ’lab’, men vi vet at for alle nøkler som begynner med ’lab’ skal verdien være en tallverdi.

Skriv funksjon add_total_lab_score med en parameter data for et oppslagsverk på formen beskrevet over. Funksjonen skal regne ut summen av alle verdiene knyttet til nøkler som begynner med ’lab’. Deretter skal funksjonen mutere oppslagsverket ved å legge til nøkkel 'total_lab_score' som viser verdien som ble funnet.

Testen under dokumenterer hvordan vi forventer at funksjonen skal fungere:

def test_add_total_lab_score():
    print('Testing add_total_lab_score...', end='')

    # Test A
    data = {
        'student_name': 'Kari',
        'lab1': 20,
        'lab2': 22,
        'lab3': 23,
    }
    add_total_lab_score(data)
    assert data == {
        'student_name': 'Kari',
        'lab1': 20,
        'lab2': 22,
        'lab3': 23,
        'total_lab_score': 65,
    }

    # Test B
    data = {
        'course_id': 'FNI100',
        'labA': 25,
        'labB': 25,
    }
    add_total_lab_score(data)
    assert data == {
        'course_id': 'FNI100',
        'labA': 25,
        'labB': 25,
        'total_lab_score': 50,
    }
    print(' OK')

• Funksjonsdefinisjonen har én parameter (1 poeng)
• Løkke gjennom oppslagsverket (2 poeng)
• Korrekt forståelse av hva som er nøkkel og hva som er verdi i løkken (2 poeng)
• Fornuftig sjekk om en streng begynner med ’lab’, her godtar vi både startswith og beskjæring (og også full pott for feil navngitte versjoner av dette, for eksempel «beginswith», eller feilaktig syntaks men som likevel demonstrerer forståelse av hva som er hva, for eksempel my_key(0,3) som et forsøk på beskjæring). Mislykkede forsøk på en slik sjekk (f. eks. if 'lab' == noe_helt_feil) men som likevel er bra plassert i forhold til løkken gir 50% uttelling på dette punktet. (2 poeng)
• Fornuftig akkummulering av resultatat i en samlevariabel (2 poeng).
• Legge til ny nøkkel i oppslagsverket med opptelt verdi. Det trenger ikke være syntaktisk korrekt så lenge plassering er fornuftig og intensjonen er tydelig. (1 poeng)

Dersom en besvarelse er betydelig bedre eller dårligere enn rubrikken tilsier, har sensor anledning til å justere poengsummen etter eget skjønn.