Föreläsning 6. pseudokod problemlösning logik algoritmer

Transkript

1 Föreläsning 6 pseudokod problemlösning logik algoritmer Inledning Logik är läran om korrekt resonemang att kunna dra korrekta slutledningar utifrån det man vet. Vi gör detta ständigt utan att tänka på det men inom programmering så blir det ofta mer påtagligt. Det finns informell logik som är logiskt resonemang uttryck med naturligt språk. Det är detta vi använder till vardags när vi argumenterar eller resonerar om vardagliga frågor. Här hamnar även det vi kallar pseudokod även om detta är en mer strikt form av naturligt språk. Sedan har vi formell logik där formen för det korrekta resonemanget är fångat i ett formellt språk som exempelvis satslogik som vi kommer att titta på. De formella språken är begränsade av att man måste följa språkets regler och man kan inte uttrycka lika mycket med ett formellt språk som med naturligt språk. Java och andra programmeringsspråk kan ses som formella språk. DA129A Programmering 1 1

2 Pesudokod Vi börjar med pseudokod som kommer att bli ett oundvikligt redskap när du gör lite mer komplexa program. Pseudokod är egentligen bara naturligt språk strukturerat lite kortare och liknande det sätt man strukturerar källkod på. Du använder dig av satser och indrag men en sats kan vara betydligt större i sitt omfång än vad som är vanligt i det formella programmeringsspråket. Indragen blir mycket viktiga i pseudokod då dessa visar vilka satser som är underordnade andra satser. I pseudokod använder man sig sällan av något tecken för att starta eller sluta ett block. Pseudokod används för att bryta ner ett problem i mindre delar innan man sätter sig och skriver källkod. Detta gör man för att upptäcka hur man lämpligt kan dela in koden i metoder och kontrollstrukturer samt för att identifiera nödvändig indata. Pseudokod kan också användas för att testa en algoritm innan man kodar denna. Genom att kontrollera att pseudokoden löser problemet så sparar man tid innan man kodar och slipper risken att en massa kod är gjord förgäves och ändå måste slängas. Antag att vi har följande problem: Du är på biblioteket och vill låna boken Populärmusik från Vittula av Mikael Niemi. Tyvärr så sker det underhåll på deras elektroniska katalog så du kan inte via denna ta reda på om boken finns eller ej utan måste använda dig av en lite ålderdomligare metod att helt enkelt se om boken finns i hyllan eller inte. Finns boken i hyllan så tar du den och går till disken för att låna denna annars så går du till disken för att reservera boken. Då det är en skönlitterär bok så vet vi att den finns på hylla Hc. Om vi nu skall skriva pseudokod för hur vi löser problemet ovan så ställs vi inför några frågor: Vilka delar kan vi bryta ner det här problemet i? Hur mycket detaljer skall vi visa? Hur vi vet att boken finns är ganska lätt men hur vet vi om boken inte finns? De två första frågorna hör ihop. Ju fler detaljer vi vill visa desto fler delar måste vi bryta ner problemet i. Vi vill inte göra en för abstrakt pseudokod: gå till hyllan där boken borde finnas OM boken finns Ta boken och låna den ANNARS Reservera boken Detta hjälper ju inte oss särskilt mycket. Det är för generellt. Mer detaljer då: TILLS vi kommer till första hyllan Lyft fot 1 Placera fot 1 framför fot 2 Lyft fot 2 Placera framför fot 1 Det blir lite väl mycket detaljer. Konsten är alltså att hitta en nivå där man får med nödvändiga detaljer men kan utelämna sådant som är självklart. Vilka är våra viktiga delar då: vi måste hitta rätt hylla, vi måste hitta rätt författare och vi måste hitta rätt titel. Ordningen på ett bibliotek hjälper oss då vi kan utgå DA129A Programmering 1 2

3 från att hyllorna är sorterade efter det vanliga bibliotekssystemet och att författare är sorterade i bokstavsordning efter efternamn och böckerna för varje författare efter titel. Om vi under vårt letande kommer till en författare som finns efter Niemi i bokstavsordning eller en bok av Niemi som finns efter den vi söker så fanns inte boken Populärmusik från Vittula. Så om vi utgår från stegen ovan: 1 gå till närmsta hylla 2 TILLS hylltypen är Hc //vi förutsätter att det finns en hylla Hc 3 Gå till nästa hylla 4 //vi har nu hittat hylla Hc 5 FÖR VARJE författare på Hc 6 OM namn är Mikael Niemi 7 FÖR VARJE bok av Mikael Niemi 8 OM titel är Populärmusik från Vittula 9 ta boken 10 AVBRYT för varje bok av Mikael Niemi 11 AVBRYT för varje författare på Hc 12 ANNARS 13 OM författare kommer efter Niemi i bokstavsordning 14 AVBRYT för varje författare på Hc 15 //vi har nu hittat boken eller konstaterat att den inte fanns 16 gå till lånedisken 17 OM vi har boken med oss 18 låna boken 19 ANNARS 20 reservera boken Radnumreringen är inte nödvändig utan gör det bara lättare att referera till delar av psudokoden nu i denna text. Så låt oss nu analysera denna pseudokod och se vilka slutsatser vi kan dra från vår algoritm för att låna eller reservera en viss bok. I den första loopen (2) så gör vi ett antagande att det finns minst en hylla av typen Hc. Om det inte skulle finnas någon hylla av typen Hc så har vi en oändlig loop. Men då vi vet att det är ett vanligt bibliotek så kan detta vara ett rimligt antagande. Vi gör också ett antagande att det finns något sätt att ordna hyllorna i en ordning eller hålla reda på vilka vi tittat på eller inte. Vi har inte nästlat in senare händelser i denna loop utan när raden efter loopen startar (5) så kan vi utgå från att vi står vid första hyllan av typen Hc. I nästa loop (5) så tittar vi på alla författare som finns på Hc. Villkoret är här inte tills vi hittar Niemi utan vi måste använda en break-sats för att avbryta loopen när vi hittat Niemi eller vet att Niemi inte finns (11) respektive (14). Det händer egentligen ingenting avgörande om vi skulle fortsätta att titta på alla författare efter att vi hittat boken eller vet att den inte finns men det är ganska onödigt. Om vi i denna loop hittar Niemi så startas en ny loop där vi tittar på titlar(7). DA129A Programmering 1 3

4 Loopen som tittar på titlar (7) avbryts om vi hittar rätt bok(10) men om boken vi söker inte finns så kommer vi at titta på alla böcker av Niemi även om vi gått förbi den sökta boken i bokstavsordning. Vi får här avgöra om det är nödvändigt att lägga in detta avbrott eller inte. Är det värt en extra selektion för varje titel jämfört med någon iteration för mycket? När rad (16) inleds så har loopen som letar bland författare och titlar på Hc avslutats på något sätt och vi går till lånedisken då vi oavsett resultatet i looparna ovan skall dit. Väl framme vid lånedisken så avgör vi vad vi ska göra utifall vi har boken med oss eller inte. Detta kallas att man sätter en flagga och är vanligt när man har loopar som letar efter något. Alternativet hade varit att flytta upp denna kod till loopen på följande sätt: 8 OM titel är Populärmusik från Vittula 9 ta boken 9.1 gå till lånedisken och låna boken 10 AVBRYT för varje bok av Mikael Niemi samt 13 OM författare kommer efter Niemi i bokstavsordning 13.1 gå till lånedisken och reservera boken 14 AVBRYT för varje författare på Hc 15 //vi har nu hittat boken eller konstaterat att den inte fanns Här har vi ganska korta följder beroende på om vi hittar boken eller inte och det blir fortfarande läsbar kod. Men om det hade inneburit längre kodavsnitt så hade metoden med en flagga varit bättre. Lägg märke till hur viktigt det är att indragen ovan stämmer i pseudokoden för att avgöra vad som ingår i en viss loop. Om indragen inte stämmer blir pseudokoden fullständigt meningslös. Motsvarigheter till reserverade ord skrivs ofta med versaler i pseodukod för att öka läsbarheten då dessa ord lätt försvinner i mängden vanliga ord annars. Ett mer tillämpbart exempel: från menyn till testprogrammet till inlämningsuppgift 1. skapa instans av klassen Prog1 skriv ut menyn läs in val från menyn SÅ LÄNGE val inte är 0 anropa vald testmetod med den skapade instansen som argument läs in nytt val Den översta raden anger initieringen av en variabel. Det är inte alltid man anges dessa då de ofta är triviala och mest ger extra rader över något som är självklart. Här har den tagits med då den är viktig för utan denna variabel så kan vi inte korrekt anropa testmetoderna. Det blir också synligt att vi inte skapar en ny instans för varje anrop utan att vi skapar en instans som används upprepade gånger. Det har däremot utelämnats ovan vilken kontrollstruktur som används för att avgöra vilket val som gjorts ovan. Om man vill specificera något av detta så kan man skriva utförligare pseudokod: DA129A Programmering 1 4

5 skapa instans av klassen Prog1 skriv ut menyn läs in val från menyn SÅ LÄNGE val inte är 0 SWITCH val val är 1 Anropa testmetod A val är 2 Anropa testmetod B val är 3 Anropa testmetod C val är 4 Anropa testmetod D val är 5 Anropa testmetod E val är 6 Anropa testmetod F val är 7 Anropa testmetod G läs in nytt val Detta blev dock långt och gav oss inte så mycket mer information. Break-satsen i en switchsats har ansetts som underförstådd för att spara rader. Hur vi implementerar valet är ju en programmeringsteknisk detalj. Pseudokoden i det första alternativet visar bättre på styrkan hus denna, att kort kunna ange det viktigaste. I det här fallet att vi väljer olika metoder beroende på indata. Så som påpekat tidigare så är svårigheten att hitta den grad av detaljer som behövs. Det är bättre att börja med lite för lite detaljer för att se vad man behöver förtydliga när man skriver pseudokod än att börja med att grotta ner sig i en pseudkod som i princip är källkod direkt och ta onödigt lång tid på sig. Det gäller att komma ihåg att pseudokoden skall vara en förenklig av källkoden. DA129A Programmering 1 5

6 Satslogik Exempel på satslogik: P1 : Alla människor är dödliga. P2: Sokrates är människa. Slutsats: Sokrates är dödlig Om premisserna, i det här fallet P1 och P2, är sanna så måste slutsatsen vara sann. Då är det en giltig slutledning. Historia Exemplet ovan är från Aristoteles syllogismer skapade för ca: 2000 år sedan. Aristoteles hittade former för korrekta slutledningar. Även om vi ersatte människa med däggdjur och Katt istället för Sokrates i exemplet ovan skulle slutledningen vara riktig. Det är inte innehållet som gör slutledningen giltig utan formen. Logiken utvecklades inte så mycket efter Aristoteles fram till slutet av 1800-talet. Men då tog utvecklingen fart med matematiker som Russell och Frege. Då kom satslogiken och predikatslogiken (standardlogiker). Under 1900-talet har logiken utvecklats mycket. Datorutvecklingen är ett exempel på tillämpad logik. Satslogikens uppbyggnad Satslogiken består av atomära satser som representeras av en symbol, oftast i form av en bokstav (p, q, r, s, t ). Exempelvis p= solen skiner, q= himlen är blå Satserna knyts sedan samman av så kallade konnektiv som beskriver satsernas relation till varandra. Logiska konnektiv: Symbol Tolkning Namn icke Negation & och Konjunktion v eller Disjunktion om...så.. Implikation om och endast om Ekvivalens Andra symboler: (, ) förtydligar prioritetsordningen Du känner igen vissa begrepp här från de logiska operatorerna och det är för dessa som den stora vinsten ligger i att känna till en del om satslogik när man programmerar. Genom att kunna satslogik så kan du lättare kontrollera att dina villkor innebär det som du avser och hur du kan skriva om dina villkor till att bli kortare och mer effektiva. DA129A Programmering 1 6

7 Sanningsvärdestabeller Ett sätt att definiera konnektiven är att rita en sanningsvärdes tabell. Sanningsvärdestabell kan även användas för att visa om en slutledning är logiskt giltig eller inte. Definition av konnektivet : Ex. p= solen skiner p utläses solen skiner inte Om p är sann så är p falsk. Om p är falsk så är p sann. p sann falsk p falsk sann Definition av konnektivet &: Ex. p= solen skiner, q= himlen är blå p&q utläses solen skiner och himlen är blå p & q är bara sann om både p och q är sann. p q p&q sann falsk falsk sann sann sann falsk sann falsk falsk falsk falsk Definition av konnektivet v: Ex. p= solen skiner, q= himlen är blå p v q utläses solen skiner eller himlen är blå p v q är bara falsk om både p och q är falska p q p v q sann falsk sann sann sann sann falsk sann sann falsk falsk falsk Definition av konnektivet : Ex. p= solen skiner, q= himlen är blå p q utläses om solen skiner så är himlen blå p q är bara falsk om både p är sann men q är falsk. p q p q sann falsk falsk sann sann sann falsk sann sann falsk falsk sann DA129A Programmering 1 7

8 Definition av konnektivet : Ex. p= solen skiner, q= himlen är blå p q utläses om och endast om solen skiner är himlen blå p q är sann om både p och q har samma sanningsvärde. p q p q sann falsk falsk sann sann sann falsk sann falsk falsk falsk sann För att kunna se den logiska strukturen i ett resonemang kan det vara bra att översätta resonemanget till satslogik. Exempel: Du hinner i tid om du skyndar dig. Annars hinner du inte. p= du hinner i tid q= du skyndar dig (q p)& ( q p ) kan även skrivas // Tabell A nedan (q p)& (p q ) kan även skrivas // Tabell B nedan q p // Tabell C nedan Kan du se att dessa tre översättningar har samma sanningsvärde för alla möjliga kombinationer av sanningsvärden på p och q? Vi gör sanningsvärdestabeller: Tabell A q p (q p) q p ( q p ) (q p)& ( q p ) s s s f f S s s f f f s S f f s s s f F f f f s s s S s Kolumn 1 och 2 visar alla möjliga sanningsvärden på p och q och hur dessa kan kombineras. Kolumn 3 följer av 1, 2 och definitionen av implikation. Kolumn 4 och 5 följer av 1, 2 och definitionen av negation. Kolumn 6 följer av 4, 5 och definitionen av implikation. Kolumn 7 följer av 3, 6 och definitionen av konjunktion. DA129A Programmering 1 8

9 Tabell B q p (q p) (p q ) (q p)& (p q ) s s s s s s f f s f f s s f f f f s s s Kolumn 1 och 2 visar alla möjliga sanningsvärden på p och q och hur dessa kan kombineras. Kolumn 3 följer av 1, 2 och definitionen av implikation. Kolumn 4 följer av 1, 2 och definitionen av implikation. Kolumn 5 följer av 3, 4 och definitionen av konjunktion. Tabell C q p q p s s s s f f f s f f f s Kolumn 1 och 2 visar alla möjliga sanningsvärden på p och q och hur dessa kan kombineras. Kolumn 3 följer av 1, 2 och definitionen av ekvivalens. Om du nu jämför värdena för de sist kolumnerna i de tre tabellerna ovan så ser du att dessa stämmer överens. Logiska lagar I satslogiken finns det beskrivet några logiska lagar och grundformerna för giltiga slutledningar. Dessa hjälper dig att kunna omforma uttryck. Exempel på logiska lagar är dubbla negationslagen, de Morgans lagar, kommutativa lagen, associativa lagar, omvändningslagen och disjunktiv utbytesregel. Exempel på giltig slutledning är modes ponens, modus tollens, disjunktiv slutlednings regel och reduktion ad absurdum. Vi kommer att gå igenom dessa nedan. Vi börjar med lagarna. Dubbla negationslagen ( p) p Det är inte så att jag är orädd, är det samma som att jag är rädd. I meningen ovan så är där två negationer, först inte och sedan o- som tar ut varandra. DA129A Programmering 1 9

10 De Morgans lagar (p &q) p v q (p v q) p & q Det är inte både så att det regnar och solen skiner är det samma som det regnar inte eller solen skiner inte. Det är inte så att det är torsdag eller fredag är det samma som det är inte torsdag och det är inte fredag. Kommutativa lagen p & q q & p p v q q v p p q q p Man kan kasta om ordningen på satserna vid &, v och Associativa lagar (p & q) & r p & (q & r) (p v q) v r p v (q v r) ((p q) r) (p (q r)) Paranteserna spelar ingen roll för &,v och Omvändningslagen p q q p Om solen skiner så är himlen blå. Är det samma som: Om himlen inte är blå så skiner inte solen. Disjunktiv utbytesregel p v q p q Solen skiner inte eller himlen är blå. Är det samma som: Om solen skiner så är himlen blå. Om du tycker någon lag ser knepig ut så skriv up en sanningsvärdestabell för att övertyga dig om att det stämmer. DA129A Programmering 1 10

11 Vi kommer nu till former för slutledningar. Dessa skrivs på en speciell form så som du såg i det allra första exemplet. De ingående premisserna listas ovanför varandra och under strecket skrivs den slutsats vi kan dra av premisserna. Slutsatsen kan dras under förutsättning att alla premisserna är sanna(p1&p2). p=det är fredag idag q=det är lördag imorgon Modus Ponens p q p q Om det är fredag idag så är det lördag imorgon. Det är fredag idag. Slutsats: Det är lördag imorgon. Modus Tollens p q q p Om det är fredag i dag så är det lördag imorgon. Det är inte lördag imorgon. Slutsats: Det är inte fredag idag. Disjunktiv slutledningsregel p v q p q Det är fredag idag eller så är jag pank. Det är inte fredag idag. Slutledning: Jag är pank. Reduktion ad absurdum p q p q p Om en premiss leder fram till en motsägelse så måste premissen vara falsk. Detta är ett så kallat motsägelsebevis. De två premisserna kan inte vara sanna samtidigt om p är sann alltså måste p vara falsk det vill säga p. DA129A Programmering 1 11

12 Exempel: Premiss 1: Vi far till stranden Premiss 2: välj något av alternativen nedan a) Endast om det regnar far vi till stranden. b) Om solen skiner far vi till stranden. c) Vi far inte till stranden om det åskar d) Om det inte är kallt far vi till stranden. e) Vi far till stranden endast om det inte blåser. f) Endast om solen inte skiner far vi inte till stranden. g) Om vi far till stranden skiner solen. Kan vi dra någon giltig slutsats av dessa två premisser (Premiss 1 och Premiss 2a t.ex.)? Jag kan avslöja att utifrån Premiss 1 och Premiss 2a kan vi dra slutsatsen att det regnar. Hur kontrollerar vi detta: p = vi far till stranden q= det regnar P1: Vi far till stranden, p P2a: Endast om det regnar far vi till stranden, p q (Om vi far till stranden så regnar det) p p q q Slutsats enligt modus ponens Vad kan vi säga om P1 och P2b? p = vi far till stranden q = solen skiner P1: Vi far till stranden, p P2: Om solen skiner far vi till stranden. q p p q p ingen slutledning kan göras för vi kan inte säga något om q utifrån att p är sann. Vi vet inte vad vi gör om solen inte skiner, vi kan ju åka till stranden ändå. Vi vet bara att OM solen skiner så åker vi till stranden. Vad kan vi säga om P1 och P2c? p = vi far till stranden q = det åskar P1: Vi far till stranden, p P2: Vi far inte till stranden om det åskar, q p (om det åskar far vi inte till stranden) p q p q enligt modus tollens. Detta då om vi vet att p och q p medför q. Ser du hur det inte måste skrivas på just detta sätt utan att det viktiga är att p:na i det här fallet är motsatta varandra med det ena negerat och det andra inte. DA129A Programmering 1 12

13 Vad kan vi säga om P1 och P2d? p = vi far till stranden q = det är kallt P1: Vi far till stranden, p P2: Om det inte är kallt far vi till stranden q p p q p ingen slutledning kan göras för vi kan inte säga något om q utifrån att p är sann. Vi vet inte vad som sker om det är kallt, vi kan åka till stranden ändå. Vad kan vi säga om P1 och P2e? p = vi far till stranden q = det blåser P1: Vi far till stranden, p P2: Vi far till stranden endast om det inte blåser, p q (om vi far till stranden blåser det inte) p p q q Enligt modus ponens. Vad kan vi säga om P1 och P2f? p = vi far till stranden q = solen skiner P1: Vi far till stranden, p P2: Endast om solen inte skiner far vi inte till stranden, p q (om vi inte far till stranden skiner solen inte) vilket enligt omvändningslagen kan skrivas q p (solen skiner) p q p ingen slutledning kan göras för vi kan inte säga något om q utifrån att p är sann. Vi kan åka till stranden även om solen inte skiner. Vi vet bara att om vi inte åkt till stranden så skiner inte solen. Vad kan vi säga om P1 och P2g? p = vi far till stranden q = solen skiner P1: Vi far till stranden, p P2: Om vi far till stranden skiner solen p q p p q q Enligt modus ponens. DA129A Programmering 1 13

14 Observera att satslogiken och vardagligt tal inte alltid ser på innebörden på samma sätt. När vi i vardagligt tal säger att Om solen skiner far vi till stranden och sedan åker till stranden så menas det vanligtvis också att solen skiner. Satslogiken tillåter inte den tolkning vi gör i vardagligt tal. Det gäller alltså att komma ihåg att de inte är innehållet i en sats som gör att vi kan dra några slutsatser utan formen på satserna. Andra formella notationer Det finns ett flertal mer formella notationer utöver satslogik som kommer till nytta inom programmering och som är mer formella än pseudokod. Aktivitetsdiagram Du har redan stött på ett flertal aktivitetsdiagram för att beskriva en algoritms utseende. Aktivitetsdiagram lämpar sig speciellt väl för att beskriva en algoritms olika flöden beroende på indata som påverkar utfallet. Aktivitetsdiagram lämpar sig också väl när man skall beskriva parallella flöden av händelser vilket pseudokod inte är lämpat för. aktivitet Fyrkanten används för att representera en aktivitet. Texten i rutan skall mycket kortfattat beskriva aktiviteten. beslut Romben används för att representera ett beslut. Texten i romben skall mycket kortfattat beskriva valet. true Pilen används för att representera förflyttning till en annan aktivitet eller beslut. Om pilen leder från ett beslut skall det visas vilket beslut som denna pil representerar. En pil utan början representerar startpunkten och en pil utan slut representerar slutet Den tjocka linjen används för att representera en synkronisering mellan aktiviteter. Det kan handla om att vänta in vissa aktiviteter innan nästa på börjas eller att flera olika aktiviteter påbörjas vid ett tillfälle. DA129A Programmering 1 14

15 Exempel på aktivitetsdiagram över att tappa upp ett bad. Gå till badrummet Fyll badkaret Hämta nya handdukar badsalt ja Häll i badsalt nej Kryp ner i badkaret Klassdiagram Aktivitetsdiagram eller pseudokod fungerar inte för att beskriva hur klasser refererar till varandra. För detta behöver man ett klassdiagram. För varje klass i ett klassdiagram listar man namn, attribut och metoder i en fyrkant enligt modellen: klassnamn attribut1:datatyp attribut2 : datatyp Beroende på antalet klasser och attribut och metoder så stryker man ibland attributen och metoderna och visar endast klassnamnet. Vi kommer att återkomma till klassdiagram när vi kommer till den del som handlar om klasser och relationer mellan klasser. metod1 matod2(parameter) DA129A Programmering 1 15

16 UML UML Unified Modeling Language- används för att beskriva olika mjukvara och olika delar av denna i en utvecklingsprocess. Detta är en objektorienterad notation som starkt fokuserar på användarperspektiv och klasser. UML är mycket användbart inom mjukvaruutveckling och används i kurslitteraturen för aktivitetsdiagram med mera. Notationen för dessa skiljer sig från den anklare notationen presenterad ovan. UML innehåller dock mycket mer än aktivitetsdiagram. Att gå in på hur UML fungerar från grunden kräver en förståelse för mjukvaruutveckling som ligger utanför denna kurs. UML är dock ett begrepp som det är bra att känna till. Den intresserade kan hämta mer information från webben, t.ex. från DA129A Programmering 1 16