Datorlaborationer, Objektorienterad modellering och design (EDAF25)

Transkript

1 Datorlaborationer, Objektorienterad modellering och design (EDAF25) Datorlaborationerna ger exempel på tillämpningar av det material som behandlas under kursen. Uppgifterna i laborationerna ska lösas i par om två. Laborationerna är obligatoriska. Det betyder att du måste bli godkänd på alla uppgifterna under ordinarie laborationstid. Om du skulle vara sjuk vid något laborationstillfälle så måste du anmäla detta till kursansvarig lärare före laborationen (epost-adress finns på kursens hemsida). Om du varit sjuk bör du göra uppgiften på egen hand och redovisa den under påföljande laborationstillfälle. Det kommer också att anordnas en uppsamlingslaboration i slutet av kursen. Detta tillfälle erbjuds dock bara till dem som haft giltigt skäl för frånvaro på någon laboration eller som varit närvarande vid samtliga laborationer men, trots rimliga förberedelser, inte hunnit bli färdiga. Laborationerna kräver en hel del förberedelser. I början av varje laboration finns anvisningar om förberedelser under rubrikerna Läsanvisningar och Förberedelser. Läsanvisningarna anger vilka avsnitt i läroboken som ska läsas. Under rubriken Förberedelser anges vilka av laborationsuppgifterna som ska lösas före laborationstillfället. Du ska också ha läst igenom de övriga uppgifterna och gärna försökt lösa dem. Det är inget krav att att du kommer med helt färdiga lösningar. Men det är ditt och din laborationspartners ansvar att ha förberett er så att ni bedömer att ni hinner bli klara under laborationen. Ni får naturligtvis under dessa förberedelser gärna kontakta kursansvarig lärare om ni stöter på svårigheter. Du måste för varje laboration se till att laborationsledaren noterar dig som godkänd på listan på nästa sida. Om du hittar någonting i uppgifterna eller andra anvisningar som är felaktigt eller oklart så meddela gärna detta till kursansvarig lärare. Innehåll 1 Laboration Laboration Laboration Laboration Laboration

2 2 Godkända laborationsuppgifter Objektorienterad modellering och design (EDAF25), godkända laborationsuppgifter Skriv ditt namn och din namnteckning nedan: Namn: Namnteckning: Godkänd laboration Datum Laborationsledarens namnteckning

3 Laboration 1 3 Laboration 1 Mål: Att få insikt i hur ett generiskt interface för grafer, deras noder och bågar kan utformas. Att ge träning i att använda ett sådant interface och en färdigskriven implementerande klass. Laborationen ger också träning i att använda verktyget JUnit för test. Läsanvisningar Läs igenom följande avsnitt i boken (Koffman, Wolfgang): Observera att vi på laborationen kommer att använda ett annorlunda interface för att representera grafer än det som finns i boken. Förberedelser Eclipse Under laborationerna ska programutvecklingsmiljön Eclipse användas. Ni som inte använt Eclipse kan läsa mer om detta verktyg i ett PM som finns på kursens hemsida. På skolans datorer finns Eclipse installerat. Om du vill jobba med laborationen hemma och inte redan laddat ner Eclipse så finns anvisningar för detta på hemsidan. Nedan ges kortfattade anvisningar för att hämta ett förberett arbetsområde för kursens laborationer och för att starta Eclipse på skolans datorer. Det finns ett förberett arbetsområde (workspace) för laborationerna på denna kurs i packad form i filen edaf25-workspace.zip. Filen finns att hämta från kursens hemsida. Starta en webbläsare och gå till adressen Klicka där på länken Laborationer i menyn till vänster. Ladda ner filen edaf25-workspace.zip till din hemkatalog och packa upp den. Lägg katalogen edaf25-workspace där du vill ha den, i din hemkatalog. Starta Eclipse. Efter en stund får du en dialogruta där Eclipse frågar efter vilket workspace (arbetsområde) du vill använda. Leta efter arbetsområdet edaf25-workspace och välj detta. I Eclipse-fönstret visas då i projektvyn ( Package Explorer, längst till vänster) alla projekten i arbetsområdet. Projekten öppnas genom att man klickar på pilen bredvid projektnamnet. I projekten finns det förberett ett eller flera paket. Dessa öppnas genom att man klickar på pilen bredvid deras namn. Enskilda filer i paketen öppnas i editorn genom att man dubbelklickar på deras namn. Förberedelser för den första laborationen Läs igenom den inledande texten nedan under rubriken Datorarbete. Lös uppgift D1 och D2. Läs igenom uppgifterna D3 och D4. Datorarbete För att kunna implementera grafalgoritmer behöver vi en abstrakt datatyp (ADT) som representerar grafer, deras noder och bågar tillsammans med operationer på objekt av dessa typer. I Javas klassbibliotek finns det inte några sådana interface eller klasser. I boken finns i avsnitt 10.2 ett förslag till en ADT, men denna är inte generell. Det finns t.ex inte någon riktig representation av grafens noder som objekt utan dessa representeras av heltal. Vidare förutsätter man att de data som knyts till bågar i grafen är av typen double. I en generell representation vill vi tillåta data av godtycklig typ att knytas till noder respektive bågar. Med hjälp av generiken i Java kan vi uppnå detta genom att införa typparametriserade interface för grafer samt deras noder och bågar.

4 4 Laboration 1 För att kunna göra generella implementationer av algoritmer är det en god idé att programmera mot interface i stället för mot konkreta klasser. Tag som exempel en metod som skall ha en lista som parameter. Antag att vi ger den följande signatur: public void dosomething(linkedlist<e> list) {... Vi kan då anropa metoden med en aktuell parameter av typen LinkedList. Vi kan däremot inte anropa den med en aktuell parameter av typen ArrayList. Om vi i stället i metodsignaturen använder interfacet List som typ för parametern: public void dosomething(list<e> list) {... så kan vi vid anrop som aktuell parameter ha objekt av alla klasser som implementerar interfacet List d.v.s. både LinkedList och ArrayList. Vi bör alltså för grafer införa ett interface med två typparametrar V och E där V är typen för de data som knyts till noder i grafen och E är typen för data knutna till bågar. På kursens hemsida (under fliken laborationer) finns länk till dokumentation för ett sådant interface. Det har följande uppbyggnad: interface Graph<V,E> extends Iterable<Graph.Vertex<V,E>> {... operationer på en graf... interface Vertex<V,E> extends Iterable<Edge<V,E>> {... operationer på en nod... interface Edge<V,E> {... operationer på en båge... I det yttre interfacet finns följande operationer: Vertex<V,E> addvertex(v value) som lägger in en ny nod innehållande värdet value i grafen. Den skapade noden returneras som resultat. Den nya noden har från början inga bågar till andra noder i grafen. void addedge(e value, Vertex<V,E> source, Vertex<V,E> destination) som sätter in en båge mellan noderna source och destination. Bågen får värdet value. void unvisit() som markerar alla noder i grafen som obesökta. Det är vanligt att man i grafalgoritmer behöver hålla reda på vilka noder som besökts framförallt för att undvika att hamna i loop, vilket annars kan inträffa när grafen har cykler. Grafinterfacet är förberett för detta. unvisit ger användare möjlighet att, när det behövs, markera alla noder som ej besökta. (Enskilda noder kan markeras som besökta/obesökta genom operationer som finns i interfacet Vertex, se nedan). Eftersom interfacet Graph ärver från interfacet Iterable<Graph.Vertex<V,E» så måste den som implementerar interfacet även implementera följande metod: Iterator<Graph.Vertex<V, E>> iterator()

5 Laboration 1 5 Om vi har en graf av typen Graph<V,E> kan vi därför gå igenom alla noder med följande kod: for (Graph.Vertex<V,E> v : g) {... Det nästlade interfacet Vertex har följande rubrik: interface Vertex<V,E> extends Iterable<Edge<V,E>> och innehåller följande operationer på noder: V getvalue() och void setvalue(v value) för att ta reda på respektive uppdatera värdet som associeras med noden. void visit(), void unvisit() och boolean isvisited() för att markera noder som besökta respektive ej besökta samt ta reda på om en nod är besökt eller ej. Eftersom interfacet ärver från implementera följande metod: Iterable<Edge<V,E» så måste den som implementerar det även Iterator<Graph.Edge<V,E>> iterator() Denna operation skall returnera en iterator för alla bågar som utgår från noden. Vi kan därför gå igenom alla sådana bågar med följande kod (där vi antar att v är av typen Graph.Vertex<V,E>): for (Graph.Edge<V,E> e : v {... Det interface som representerar bågar har följande rubrik: interface Edge<V,E> och har följande metoder: E getvalue() och void setvalue(e value) för att ta reda på respektive uppdatera det värde som associeras till bågen. Vertex<V,E> source() och Vertex<V,E> destination(). För att ta reda på noderna i bågens ändpunkter. Bågarna är riktade och går från den nod som source returnerar till den nod som returneras av destination Trots att interfacet ovan har riktade bågar går det att använda för oriktade grafer. Om grafen är oriktad och det finns en båge mellan två noder u och v så skall det vara mjöligt att från u nå v via denna båge och vice versa. Detta kan vi åstadkomma vid grafbygget genom att sätta in två riktade bågar i grafen (med samma data), en från u till v och en från v till u. Det finns även en färdigskriven klass som implementerar grafinterfacen. Dokumentation av denna finns också på hemsidan. Klassen heter DiGraph och använder sig av närhetslistor (eller snarare närhetsmängder) för att representera grafen:

6 6 Laboration 1 I klassen som implementerar det yttre interfacet placeras alla noder i en mängd efterhand som de sätts in. Iteratoroperationen i grafklassen returnerar en iterator för denna mängd. I klassen som implementerar Vertex håller man reda på utgående bågar i en mängd. Iteratoroperationen för utgående bågar returnerar en iterator för denna mängd. Klassen har också ett attribut för att hålla reda på om noden är besökt eller ej samt ett attribut (av typen V) som innehåller nodens värde. Klassen som implementerar Edge har tre attribut: Värdet som är knutet till bågen samt de två noder som bågen förbinder. Förutom de i interfacen specificerade operationerna innehåller samtliga tre klasser i DiGraph en operation tostring() som skuggar tostring() i Object. I nod- och bågklasserna returnerar denna en strängrepresentation av de associerade värdena. I grafklassen går man igenom alla noder och anropar tostring() på dem och alla deras utgående bågar. Vi kan därför skriva ut en graf g av typen codedigraph så här: System.out.println(g); Vi kan skapa en graf av typen DiGraph där nodernas data består av en sträng och bågarnas av ett heltal på följande sätt: Graph<String,Integer> g = new DiGraph<String,Integer>(); Följande kod lägger in två noder och en båge från den första till den andra: Graph.Vertex<String,Integer> v1 = g.addvertex("nod 1"); Graph.Vertex<String,Integer> v2 = g.addvertex("nod 2"); g.addedge(10,v1,v2); // om grafen skall vara oriktad måste vi även anropa g.addedge(10,v2,v1) Uppgifterna i denna labb ger övning på att använda de presenterade interfacen för att implementera några enkla operationer på grafer. Ni kommer också att testa dessa algoritmer genom att bygga några grafer av typen DiGraph och kontrollera att era algoritmer ger rätt resultat för dessa. D1. I projektet lab1 i kursens arbetsområde i Eclipse finns det i src-katalogen ett paket graph_util. I detta finns klassen GraphUtilities påbörjad. I denna uppgift skall en av metoderna i klassen implementeras: public static <V,E> int nbrofvertices(graph<v,e> g) Metoden skall returnera antalet noder i grafen g. Några kommentarer till metodsignaturen: Metoden har deklarerats som static eftersom den inte behöver använda några attribut i den omgivande klassen. Metoden har utformats så att den blir generell genom att parametern är ett interface som har typparametrar. Metoden är alltså generisk och kan anropas med en aktuell parameter som är ett objekt av en godtycklig klass som implementerar interfacet och med godtyckliga värden på typparametrarna.

7 Laboration 1 7 Syntaxen för statiska metoder som har typparametriserade parametrar kräver att dessa räknas upp i metodrubriken före metodens returtyp. Ex: public static <T> void p(list<t> list) {... public static <T extends Comparable<T>> void max(list<t> list) {... D2. Testa din implementation från föregående uppgift. I paketet graph_util_tests finns en testklass TestGraphUtilities i JUnit. Den bygger några grafer av typen DiGraph och anropar metoden i föregående uppgift på dessa och jämför med korrekt svar. Korrigera eventuellt din kod i föregående uppgift och test på nytt tills alla test ger grönt ljus. D3. I klassen GraphUtilities finns även följande två metodrubriker: public static <V,E> int nbrofedges(graph<v,e> g, boolean directed) public static <V,E> boolean edgebetween(graph.vertex<v,e> from, Graph.Vertex<V,E> to) Den första metoden skall returnera antalet bågar i grafen g. Metodens andra parameter anger om grafen är riktad eller inte. Om den inte är riktad förutsätter vi att en båge mellan två noder representeras av två riktade bågar då man bygger grafen. I detta fall måste alltså antalet bågar divideras med 2 innan det returneras. Den andra metoden skall undersöka om det finns en båge från noden from till noden to. Implementera båda metoderna. D4. Lägg i klassen TestGraphUtilities till test för de båda metoderna i föregående uppgift och gör eventuellt korrigeringar av koden tills alla test ger grönt ljus. Testa båda metoderna för grafer av olika storlekar. Vilka specialfall behöver testas? Testa den första metoden på både riktade och oriktade grafer av olika storlekar. Testa den andra metoden för både sant och falskt.

8 8 Laboration 2 Laboration 2 Mål: Att ge träning i att lösa olika problem med hjälp av djupet-först-genomgång av grafer. Att kunna implementera genomgång av grafen på ett sådant sätt att användare enkelt kan använda det för många olika problem. Laborationen ger också träning i att uttrycka lösningar med rekursiv teknik i Java. Läsanvisningar Läs igenom följande avsnitt i boken (Koffman, Wolfgang): Under laborationen kommer vi att använda samma grafinterface och grafklasser som under föregående laboration. Förberedelser Läs igenom den inledande texten nedan under rubriken Datorarbete. Lös uppgifterna D1 och D2. Läs igenom uppgift D3. Läs texten efter uppgift D4. Läs igenom uppgift D5. Om det blir tid över på laborationen så lös även den frivilliga upgiften D4. Datorarbete Under denna laboration skall vi behandla några grafproblem som alla har det gemensamt att de kan lösas genom att man traverserar grafen djupetförst. Djupetförstgenomgång utgående från en nod v kan uttryckas så här i pseudokod (dfs är metodens namn och v är en nod i grafen): dfs(v) markera v som besökt för alla bågar e som utgår från noden v: w = noden i andra änden av e om inte w är besökt dfs(w); Metoden ovan markerar alla de noder som går att nå från v som besökta. Det är dock inte säkert att alla noder kan nås på detta sätt eftersom en graf kan bestå av flera komponenter. För att besöka samtliga noder i en graf med djupetförstteknik kan vi därför behöva göra upprepade anrop av metoden ovan tills alla noder är besökta. Pseudokod finns nedan. Parametern g är nu den graf som skall traverseras djupetförst. dfs(g) markera alla noder i grafen som obesökta for varje nod v i grafen om v inte är besökt dfs(v) Några observationer: Den första metoden markerar alla noder i den komponent av grafen som v tillhör som besökta. Den andra metoden ser till att samtliga komponenter besöks. Det är viktigt att markera behandlade noder som besökta eftersom det kan finnas cykler i grafer. Vi kan därför under rekursionen komma tillbaks till en nod som vi redan besökt. Om vi då inte kontrollerar detta utan bara gör ett rekursivt anrop så hamnar vi i en evig loop.

9 Laboration 2 9 Det är viktigt att starta med att markera alla noder som obesökta i den andra metoden. Annars kan markeringar som gjorts av samma algoritm vid tidigare anrop eller av andra algoritmer finnas kvar. Algoritmen ovan gör inget meningsfullt. Den visar bara hur en genomgång djupetförst går till i princip. Ni kommer under denna laboration att komplettera koden på olika sätt för att lösa flera olika grafproblem. I kursens arbetsområde i Eclipse finns det ett projekt med namnet lab2. I detta finns det i paketet dfs_applications en klass med namnet DFS.java. I denna klass finns det färdigskrivet två statiska metoder som motsvarar pseudokoden ovan. Metoderna har följande rubriker: public static <V,E> void dfs(graph<v,e> g); private static <V,E> void dfs(graph.vertex<v,e> v) Den första metoden är den som ser till att alla komponenter besöks och den andra är den som utför traversering djupet-först utgående från den nod som är parameter. Titta på koden i Eclipse. D1. Börja med att lösa följande problem : Undersök om en oriktad graf är sammanhängande. En oriktad graf är sammanhängade om det för varje par av noder gäller att det finns en väg (en serie bågar) mellan noderna. För att avgöra om detta är fallet räcker det att välja ut en godtycklig nod (v) och undersöka om det finns vägar från denna till alla andra noder i grafen: Om det inte finns vägar från v till alla andra noder så är grafen inte sammanhängande (enligt definitionen). Om det finns en väg från v till alla andra noder så finns det också vägar mellan godtyckliga par av noder: Tag ett godtyckligt par av noder {u,w. Vi vet att det finns en väg från v till u och en väg från v till w. Eftersom grafen är oriktad så finns det då också en väg från u till v (och en från w till v). Alltså finns det säkert en väg från u till w (via v). Ovanstående observation gör det enkelt att undersöka om en graf är sammanhängade: Välj en nod och utför en genomgång av grafen djupet-först och markera alla noder som nås som besökta. Undersök därefter om alla besökts. I så fall är grafen sammanhängande. I klassen DFS (se föregående uppgift) finns följande metodrubrik: public static <V,E> boolean isconnected(graph<v,e> g) Komplettera koden i denna så att den returnerar true om grafen är sammanhängande och false om den inte är sammanhängade. Tips: Du kan anropa den privata metoden dfs(digraph.vertex<v,e> v) för en godtycklig nod i grafen, t.ex. den första nod som en iterator på grafen träffar på. I paketet dfs_tests i projektet lab2 finns i klassen TestConnected färdigskrivna test av metoden. Kör dessa test och korrigera eventuellt tills allt fungerar. Du kör test i JUnit genom att högerklicka på testklassen och välja RunAs > JUnit Test. D2. Implementera en metod som räknar antalet komponenter i en graf. Metodrubrik (finns i klassen DFS):

10 10 Laboration 2 public static <V,E> int nbrofcomponents(graph<v,e> g) Tips: Även här kan du använda dig av den privats metoden dfs(graph.vertex<v,e> v). I paketet dfs_tests i projektet lab2 finns i klassen TestNbrOfComponents färdigskrivna test av implementationen. Kör dessa test och korrigera eventuellt tills allt fungerar. D3. I denna uppgift skall ett tredje problem lösas med djupetförstgenomgång. Det gäller att avgöra om det finns en väg mellan två noder. Metodrubriken, som finns i klassen DFS är följande: /** Undersöker om det finns en väg från u till v i grafen g. */ public static <V,E> boolean pathexists(graph<v,e> g, Graph.Vertex<V,E> v, Graph.Vertex<V,E> u) Metoden skall undersöka om det finns en väg mellan v och u och i så fall returnera true. Annars skall false returneras. Krav och tips: Algoritmen skall avbrytas och returnera true så fort u påträffas. Även denna lösning måste utformas i två steg. Metoden vars rubrik givits har som ansvar att markera alla noder obesökta och därefter anropa en hjälpmetod som utför traversering från v. Det går inte längre att använda den färdigskrivna metoden för djupetförsttraversering p.g.a. kravet på att bryta så snart u påträffas. (Annars kunde man använda den och efter genomgången undersöka om u blivit besökt eller ej. En sådan lösning innebär emellertid att många noder kan komma att besökas i onödan, efter det att u påträffats.) Implementera i stället en egen privat hjälpmetod som returnerar true om/när målnoden besöks och false om den ej påträffas. I paketet dfs_tests i projektet lab2 finns i klassen TestPathExists färdigskrivna test av metoden. Kör dessa test och korrigera eventuellt tills allt fungerar. D4. Frivillig uppgift. Antag att man inte bara är intresserad av om det finns en väg mellan två noder utan också hur en sådan väg ser ut. Vi kan t.ex. returnera en lista av de noder som finns på vägen mellan noderna. Om vi hittat en väg kommer alltså v att vara det första elementet i den returnerade listan och u det sista. Metoden kan ha följande rubrik: public static <V,E> List<Graph.Vertex<V,E>> findpath(graph<v,e> g, Graph.Vertex<V,E> v, Graph.Vertex<V,E> u) Denna metodrubrik finns redan i klassen DFS. Implementera metoden. Tips: Använd även här en hjälpmetod som utför själva genomgången. Denna kan nu ha en extra parameter som är den lista man fyller på med noder efter hand som vägen konstrueras. Det kan vara praktiskt att låta hjälpmetoden returnera true/false för att kunna bryta så snart en väg hittats. När en nod besöks läggs den in i listan. Om man besöker alla grannar utan att hitta en väg tar man bort den igen.

11 Laboration 2 11 Generell utformning av djupetförstgenomgång Lösningarna till de behandlade problemen blir väldigt lika. Alla gör en genomgång av grafen djupetförst. Det som skiljer dem åt är t.ex. Antal parametrar till den publika metoden och dess hjälpmetoder I den tredje algoritmen (pathexists) måste båda ha en parameter mer än motsvarande metoder i de båda tidigare metoderna. Vi behöver ju även målnoden för att kunna avgöra när vi är klara. Vad som utförs i samband med att en nod besöks I de båda första problemen markerar man bara noden som besökt medan man i den tredje och fjärde även undersöker om man nått det sökta målet (noden u). Vad som utförs i samband med att utgående bågar från en nod behandlas I våra algoritmer behöver man inte göra någonting om noden i andra änden av bågen redan är besökt. Fallet att den inte är besökt behandlas däremot på olika sätt. I de båda första algoritmerna gör man bara ett rekursivt anrop medan man i den tredje och fjärde tar vara på resultatet av ett sådant anrop för att eventuellt avbryta genomgången. Vad som returneras I de båda första algoritmerna behöver inte hjälpmetoderna returnera något. Den skall bara gå igenom grafen och markera alla noder som då påträffas som besökta. I den tredje algoritmen måste hjälpmetoden returnera ett resultat som informerar anropande metod om man påträffat en väg från grannen till målet eller ej. En fråga som då bör ställas är om det finns något sätt att implementera genomgång djupetförst så att den kan återanvändas för alla eller i varje fall många problem vars lösning i princip kan uttryckas med en sådan genomgång. Målet är att en användare med ett specifikt sådant problem inte skall behöva implementera traverseringen på nytt utan på något sätt göra de tillägg som behövs för att lösa det aktuella problemet. Det finns flera olika sätt att implementera en generell djupetförstgenomgång. Vi skall här visa ett av dem. Det bygger på att vi vid anropet kan överföra ett objekt av en klass som innehåller metoder som anropas på olika ställen under genomgången. Vi kommer inte att ta upp den mest generella varianten utan nöja oss med att demonstrera tekniken. En klass med följande metoder införs: public class VertexVisitor<V,E> { public boolean isdone() { return false; public void previsit(graph.vertex<v,e> v) { public void postvisit(graph.vertex<v,e> v){ Den generella varianten av djupetförstgenomgång utgående från en nod v får en extra parameter av typen VertexVisitor: public static <V,E> void dfs(graph.vertex<v,e> v, VertexVisitor<V,E> visitor) { if (visitor.isdone()) { return; visitor.previsit(v);

12 12 Laboration 2 v.visit(); for (Graph.Edge<V,E> e : v) { Graph.Vertex<V,E> w = e.destination(); if (!w.isvisited()) { dfs(w,visitor); visitor.postvisit(v); Idén är att en användare implementerar en subklass till VertexVisitor där någon eller några av de tre metoderna skuggas. Ett objekt av denna klass överförs sedan vid anrop till metoden dfs. Koden ovan finns i laborationens projektkatalog i paketet dfs_with_visitors. Här finns klasserna VertexVisitor och DFS. Den senare innehåller dfs-metoden. Vi skall nu se hur man kan använda den mera generella utformningen för att lösa några problem. Låt oss som första exempel ta ett av de redan tidigare lösta: att avgöra om en graf är sammanhängande eller ej. Vi löste det genom att gå igenom grafen djupetförst utgående från en godtycklig nod och undersökte därefter om alla noder blivit besökta. Vi skall här inte avbryta metoden under genomgången och isdone kan därför alltid returnera false. Det skall inte heller utföras någonting annat än att markera noderna besökta då vi träffar på dem. Alltså behöver previsit och postvisit inte göra någonting. Vi behöver alltså inte skugga några av metoderna i VertexVisitor och därför inte heller införa någon subklass till denna. Lösningen blir: public static <V,E> boolean isconnected(graph<v,e> g) { g.unvisit(); DFS.dfs(g.iterator().next(), new VertexVisitor<V,E>()); for (Graph.Vertex<V,E> v : g) { if (! v.isvisited()) { return false; return true; Ett annat exempel: Vi vill räkna antalet noder i den komponent som en viss nod v tillhör i en oriktad graf. Vi vet att vi når alla noder som tillhör komponenten om vi gör en djupetförstgenomgång utgående från v. Lösningen blir att införa en subklass till VertexVisitor där vi vid besök av en nod ökar en räknare. Denna räknare får vara attribut i subklassen: class CountingVisitor<V,E> extends VertexVisitor<V,E> { private int count; public CountingVisitor() { super(); count = 0; public void previsit(graph.vertex<v,e> v) { count++;

13 Laboration 2 13 isdone behöver inte skuggas eftersom vi skall fortsätta genomgången tills vi besökt alla noder som går att nå. Vi behöver inte heller göra någonting då vi lämnar en nod. Alltså behöver inte postvisit skuggas. Lösningen till vårt problem kan nu utformas så här: public static <V,E> int componentsize(graph<v,e> g, Graph.Vertex<V,E> v) { CountingVisitor<V,E> cv= new CountingVisitor<V,E>(); g.unvisit(); DFS.dfs(v,cv); return cv.count; Anmärkning: Vi använder ovan punktnotation för att hämta värdet på attributet count fastän det är privat. Detta förutsätter att klassen CountingVisitor är en nästlad klass till den klass som innehåller metoden componentsize. Om så inte är fallet så får man lägga till en publik metod i CountingVisitor för att hämta attributets värde. I projektet lab2 finns i paketet dfs_with_visitors_applications en klass DFS_With_Visitors_Applications. I denna klass finns de båda metoderna ovan redan färdigskrivna. D5. Lös ett av de andra tidigare behandlade problemen med visitortekniken: att undersöka om det finns en väg mellan två noder. Följande metod kan då införas i klassen DFS_With_Visitors_Applications: public static <V,E> boolean pathexists(graph<v,e> g, Graph.Vertex<V,E> v, Graph.Vertex<V,E> u) Inför också en subklass till VertexVisitor som nästlad klass. I denna införs de attribut och skuggas de metoder som behövs för att lösa problemet. Testa din lösning. När du redovisar din lösning ska du visa att du har förstått hur man implementerar en djupetförst-genomgång av en graf samt hur man med hjälp av visitormönstret kan skilja algoritmen från strukturen på vilken den opererar.

14 14 Laboration 3 Laboration 3 Mål: Att förstå hur en breddenförstsökning går till i en graf och hur man vid en sådan genomgång kan beräkna kortaste avstånd mellan noder i en graf där alla bågar har lika vikt. En implementation av ett ordspel ( Word Ladder") skall utföras på ett sådant sätt att den kan återanvändas för olika kriterier för grannskap mellan ord. Läsanvisningar Läs följande avsnitt i läroboken: 10.4 (de delar som handlar om breddenförstgenomgång). Läs också föreläsningsbilder från de föreläsningar, som behandlar motsvarande avsnitt. Dessa finns på kursens hemsida. Förberedelser Läs igenom den inledande texten under rubriken Datorarbete nedan och lös uppgifterna D1 D4. Läs igenom och sätt dig in i uppgifterna D5 D7. Datorarbete Word ladder är ett spel där det gäller att hitta en så kort kedja av ord som möjligt mellan två ord av samma längd. Två intilliggande ord i kedjan skall därvid uppfylla ett visst kriterium. Om vi som kriterium t.ex använder att orden skiljer sig åt på en bokstav och vi behandlar engelska ord med längden 4 så består den kortaste kedjan mellan COLD och WARM av fem ord. Nedan visas en av de kedjor som har denna längd: COLD > CORD > CARD > WARD > WARM Spelet uppfanns 1877 av Lewis Carroll. Den berömde datalogen Donald Knuth använde datorer för att studera ordkedjor i en mängd bestående av 5757 engelska ord av längd 5. Han fann t.ex att endast cirka 12% av dessa inte ingår i någon kedja med andra ord. Som kriterium för att två ord följer på varandra i en kedja använde han då att de skiljer sig åt på precis en bokstav. Problemet med att hitta ordkedjor kan modelleras med en graf. En nod i grafen motsvarar ett ord. Det finns en båge mellan två noder om de ord som noderna motsvarar uppfyller kriteriet för att vara grannar i en ordkedja t.ex. om en bokstav skiljer dem åt. Problemet att hitta en kedja med minimal längd mellan två ord kan med grafen som modell omformuleras till att söka kortaste väg mellan två noder. Med väglängd avses då antalet bågar på vägen (vilket är en skillnad mot exemplet ovan där vi räknade antalet ord i kedjan. I fortsättningen kommer vi med en ordkedjas längd att avse antalet bågar på vägen). Till bågarna knyts i detta fall inte någon data. Detta tillsammans med att noderna bara representerar strängar gör att det är onödigt att använda en generell klass för att representera grafen. Vi kan i stället använda en Map<String, Set<String>. Nycklarna i denna utgörs av orden i vår ordlista. Till varje ord associeras en mängd av ord (strängar) som är grannar till nyckelordet. På tidigare föreläsning har visats hur man med hjälp av breddenförstsökning kan söka kortaste väg från en nod u till en nod v i en graf där alla bågar har samma vikt. Nedan finns pseudokod för en lite annorlunda utformad variant som lämpar sig speciellt bra när breddenförstgenomgång används för att bestämma kortaste avstånd: distance = 0 markera u besökt actlevel = tom mängd lägg in u i actlevel

15 Laboration 3 15 så länge actlevel inte är tom nextlevel = tom mängd för varje nod w i actlevel om w == v returnera distance för varje granne n till w om n inte är besökt markera n besökt lägg in n i nextlevel distance++; actlevel = nextlevel returnera -1 I denna utformning väljer vi inte att (som boken) lägga alla noder i en och samma kö efterhand som vi besöker dem. I stället använder vi två mängder: en som består av de noder som finns på ett visst kortaste avstånd, distance, från utgångsnoden (v) och en för dem som befinner sig på avståndet distance+1 från denna. Den senare (nextlevel) byggs upp av ännu ej besökta grannar till den förra (actlevel) i loopen. I slutet av loopen låter vi sedan nextlevel bli den aktuella nivån och ökar distance med ett så att värdet motsvarar det avstånd noderna i actlevel ligger från utgångsnoden. Om vi använt en kö i stället för två mängder så hade kön tidvis innehållit element på två olika nivåer (den aktuella och den som ligger på avstånd ett mer än den aktuella från utgångsnoden). Då hade vi behövt något sätt att hålla reda på de individuella köelementens avstånd. Genom att dela upp elementen i två olika samlingar slipper vi denna komplikation. Vi kunde ha valt två köer, men två mängder går lika bra eftersom det saknar betydelse i vilken ordning noderna på en viss nivå besöks. Som framgår av koden ovan så behöver vi för varje nod som behandlas i grafen få tillgång till grannarna. Detta är den enda grafoperation som utförs. Om vi väljer att arbeta direkt med maprepresentationen av grafen så kan vi enkelt få tillgång till grannar genom att anropa get med aktuell nod (ord) som parameter. Om vi i stället vill öppna för andra representationer av grafen så är det bättre om vi inför ett interface: public interface SimpleGraph { public Set<String> adjacentto(string s); Det enda detta enkla interface innehåller är alltså en metod som givet en sträng (ord) returnerar mängden av de strängar (ord) som är grannar. Interfacet finns i paketet wordladders i projektet lab3 i kursens arbetsområde i Eclipse. D1. Inför en klass som implementerar interfacet SimpleGraph och som internt har ett attribut som representerar grafen enligt ovan med hjälp av en map. Klassen skall också ha en konstruktor som bygger upp grafen utgående från en fil som innehåller orden. Filnamnet skall vara parameter till konstruktorn. I konstruktorn läses orden från filen och grafen (mappen) byggs. Börja med att läsa in alla orden och lägg in dem som nycklar i mappen med en tom mängd som associerat värde. I nästa uppgift kommer konstruktorn att kompletteras så att bågarna läggs in. Följande kod visar hur man läser från en fil vars namn finns i parametern som vi här kallar filename. Vi utgår från att filen innehåller ett ord per rad. Scanner scan = null; try { scan = new Scanner(new File(fileName));

16 16 Laboration 3 catch(filenotfoundexception e) { System.err.println("Couldn t open file: " + filename); System.exit(1); while (scan.hasnext()) { String w = scan.nextline();... Implementera också metoden adjacentto i klassen. D2. När alla ord lagts in in som nycklar i mappen kan bågarna läggas till enligt följande mönster: för varje nyckel w1 i graph för varje nyckel w2 i graph om w2 uppfyller kriteriet för att vara granne till w1 lägg in w2 i den mängd som associeras till w1 i mappen För att kunna variera kriteriet för grannskap mellan noder kan vi använda designmönstret Strategy. Vi inför därför ett interface som innehåller den metod som behövs för att ta reda på om två ord är grannar: public interface GraphStrategy { public boolean adjacent(string word1, String word2); Interfacet finns i laborationens projektkatalog. Låt konstruktorn i den klass vi håller på att implementera få ytterligare en parameter av typen GraphStrategy. Användare kan därmed föra över önskad strategi till klassen. Använd parametern för att komplettera konstruktorn med kod för att lägga till bågar enligt ovan. D3. Inför en klass OneLetterDifference som implementerar interfacet GraphStrategy. Den strategi som skall användas är att ord som skiljer sig åt på precis en bokstav är grannar. Det är viktigt att du använder det föreslagna namnet eftersom det finns färdigskrivna test som använder det. D4. Testa nu att konstruktorn som bygger grafen (mappen) fungerar korrekt genom att skriva ut resultatet. I projektkatalogen finns det några filer som skall användas i senare test. Två av dessa innehåller ordlistor. Den mindre av dessa words-7.txt kan användas för att testa konstruktorn. Använd strategin från föregående uppgift som parameter till konstruktorn. D5. I denna uppgift skall algoritmen för att bestämma kortaste väg mellan två ord implementeras. I projektet lab3 finns det en klass ShortestPath som innehåller följande metodrubrik: public class ShortestPath { public static int shortestpath(simplegraph g, String source, String dest)

17 Laboration 3 17 Implementera metoden med hjälp av den pseudokod som gavs ovan. Tips: Vi behöver kunna markera noder som besökta. Inför för detta ändamål en mängd i vilken noder läggs efterhand som de besöks. D6. I klassen Main finns följande metodrubrik: public static void processrequests(graphstrategy strategy, String wordfile, String infile) Metoden skall bygga en graf utgående från de ord som finns på filen wordfile (ett per rad). strategy skall användas som grannstrategi. Därefter skall kortaste väg mellan ord beräknas för de ordpar som finns på filen infile. Denna fil innehåller alltså ett antal rader med två ord per rad. Resultatet för varje ordpar skrivs ut med System.out.println(...). D7. I projektet lab3 finns det i paketet wordladdertests färdigskrivna JUnit-test i filen TestOneLetterStrategy. Kör dessa tester och korrigera din kod om så behövs. Testen använder sig av en liten ordfil (words-7.txt ) och en större (words-5757.txt). Den senare är den som användes av Donald Knuth. Ordpar läses från de båda filerna words-7-test.in respektive words-5757-test.in. processrequests anropas för alla ordpar och resultaten jämförs med korrekta svar, som finns på filerna words-7-test.out respektive words-5757-test.out. Jämförelse görs genom att utskrifter från programmet kopplas om till fil (mysolution-words-7.txt respektive mysolution- words-5757.txt) och dessa filer jämförs med respektive facitfil. Det är därför viktigt att det inte görs några utskrifter från dina klasser till System.out utöver resultaten från processrequests. Anm: Ibland syns inte filer som skapas under körning av ett program direkt i Eclipse (här: mysolution-words-7.txt och mysolution-words-5757.txt). Man kan då använda Refresh på menyn File. Man kan också gå in i Inställningar på menyn Eclipse och där välja General > Workspace och kryssa i boxen vid Refresh automatically. Vid redovisningen ska ni beskriva hur implementationen av bredden-först-genomgång av en graf skiljer sig respektive liknar implementationen av djupet-först-genomgång av en graf. Förklara också hur ni har implementerat strategy-mönstret.

18 18 Laboration 4 Laboration 4 Mål: Att behärska Dijkstras algoritm för att hitta kortaste väg mellan noder i en graf och att kunna implementera denna med generisk teknik. Läsanvisningar Läs avsnitt 10.6 i läroboken (avsnittet om Dijkstras algoritm). Läs också föreläsningsbilder från de föreläsningar, som behandlar motsvarande avsnitt. Dessa finns på kursens hemsida. Förberedelser Läs igenom den inledande texten under rubrikerna Datorarbete. Lös uppgift D1 och D2. Läs igenom de övriga uppgifterna och studera i Eclipse de klasser som finns färdigskrivna för uppgift D4. Datorarbete Uppgiften i denna laboration är att implementera Dijkstras algoritm för att hitta kortaste väg mellan noder i en graf. I algoritmen, som finns i läroboken och som även presenterats på föreläsning, beräknas kortaste väg från en given nod till alla noder som går att nå från denna. Man kan också utforma algoritmen så att den returnerar kortaste väg från en nod v till en nod u genom att bryta algoritmen när operationen som plockar ut element ur prioritetskön är målnoden u. I denna uppgift skall vi lösa problemet i denna senare form. Nedan finns pseudokod för algoritmen. I denna antar vi att vi i prioritetskön sätter in element som har två attribut: referens till en nod i grafen och denna nods avstånd till ursprungsnoden på den kortaste väg vi hittills hittat till noden. I koden används {nod, avstånd för denna typ av element. Dessa element förutsätts jämföras med avseende på avståndet. 1 markera alla noder i grafen som ej besökta 2 pq = en tom prioritetskö 3 pq.offer({v,0) 4 markera v som besökt 5 så länge pq inte är tom 6 {actvertex, dist = minsta elementet i pq // som tas ut ur pq 7 om actvertex == u 8 return dist 9 annars 10 för varje båge e från actvertex 11 w = e.destination() 12 newdist = dist + e.getvalue() 13 om w inte är besökt 14 markera w besökt 15 pq.offer({w,newdist) 16 annars 17 wdist = hittills kortaste avståndet från v till w 18 om newdist < wdist 19 uppdatera w:s avstånd i prioritetskön till newdist 20 return null // inträffar om u ej påträffas Kommentarer till koden ovan: På rad 12 adderas element av den typ som är knutna till bågarna i grafen. I pseudokoden använder vi +-operatorn. Men om bågarnas data är något mer komplicerat än t.ex. heltal eller double så måste vi uttrycka additionen på annat sätt.

19 Laboration 4 19 Prioritetsköklasser brukar inte innehålla någon metod för att söka upp ett visst element i kön, vilket vi behöver i samband med att koden på rad 17 skall utföras. Vi kan klara detta genom att ha en separat bokföring för vilka noder vi besökt och den hittills kortaste vägen till dessa. Det går bra med en map där nycklarna är noder och tillhörande värden är avstånd. I denna map sätter vi in uppgift om en nod första gången den påträffas och uppdaterar sedan eventuellt värdet för en nod om vi påträffar en kortare väg längre fram i algoritmen. Med denna teknik behöver vi inte längre markera noderna som besökta. Det räcker med att undersöka om en nod finns som nyckel i mappen när vi behöver ta reda på om den är besökt. Om en ny väg till en nod är kortare än den dittills kortaste behöver vi uppdatera nodens element i prioritetskön. Se rad 19. Dels kräver detta att vi har en referens till elementet som innehåller en viss nod i prioritetskön. Dels behöver vi göra en uppdatering av denna. och då behöver elementet flyttas i prioritetskön så att det hamnar på rätt plats med hänsyn till sin prioritet. Det finns ingen motsvarande operation i Javas klass för prioritetsköer. Vi kan lösa det sista problemet på följande sätt: Håll reda på noder som är helt klara d.v.s. sådana som kommit ut ur prioritetskön någon gång. Det kan vi t.ex. göra med hjälp av en mängd. Lägg in en nod i denna mängd när den hämtas ut ur prioritetskön. I fallet (rad 19) ovan där vi hittat en ny väg till en nod w som är kortare än den hittills kortaste sätter vi helt enkelt in ytterligare ett element i prioritetskön avseende w. Det kommer då att finnas mer än en uppgift om w i prioritetskön. Dels den nya (hittills kortaste) dels en eller flera gamla uppgifter motsvarande längre vägar till w som påträffats tidigare i algoritmen. Eftersom en prioritetskö tar ut det minsta elementet så kommer alltid det element som motsvarar den kortaste vägen till w att komma ut före de andra. Då markeras w som klar. Det enda vi sedan behöver göra är att då vi plockar ut ett element ur prioritetskön kontrollera att det inte avser en redan klar nod. I så fall så ignorerar vi bara elementet. Vi får då följande pseudokod för Dijkstras algoritm: pq = tom prioritetskö vertexmap = tom map (nod --> avstånd) done = en tom mängd pq.offer({v,0) vertexmap.put(v,0) så länge inte pq är tom {actvertex,dist = minsta elementet i pq // som tas ut ur kön om actvertex == målnoden u return dist om actvertex inte finns i done done.add(actvertex) for varje båge e från actvertex w = e.destination() newdist = dist + e.getvalue() om (!vertexmap.containskey(w)) (newdist < vertexmap.get(w)) pq.offer({w,newdist) vertexmap.put(w,newdist) return null Uppgiften i denna laboration är att skiva en metod som implementerar Dijkstras algoritm med ovanstående teknik. Vi kommer att använda vårt tidigare grafinterface vid implementeringen

20 20 Laboration 4 och implementationen DiGraph när vi bygger grafer för test. Implementationen skall vara så generell som möjligt. Vi skall därför inte förutsätta mer än nödvändigt för den typ E som knyts till grafens bågar, och som i pseudokoden ovan kallts för avstånd. E skulle kunna vara element som har flera attribut för att beskriva avståndet mellan noder t.ex. uppgifter om tidsåtgång (i minuter) och kostnad (i kronor) för att röra sig mellan de noder som bågen förbinder. Som kortaste väg skulle vi då kunna avse den som har minst kostnad och vid lika kostnad låta tidsåtgången avgöra. Om vi granskar pseudokoden ovan så ser vi att det är några saker vi måste kräva för typen E: Det måste gå att jämföra element av typen E. Den används ju som prioritet i de element som läggs in i prioritetskön. Det måste gå att addera element av typen E Vi måste få tillgång till ett element som motsvarar noll för typen E. Detta behöver vi i början av algoritmen då utgångsnoden sätts in i prioritetskön med denna prioritet. Det första kravet klaras lätt med hjälp av t.ex. Comparator-interfacet i Java: interface Comparator<E> { int compare(e x, E y) Vi kan låta metoden för Dijkstras algoritm ha en parameter av denna typ. Vid anrop för användare över ett objekt av en klass som implementerar interfacet och som alltså talar om hur jämförelse av de data som knyts till bågarna går till. För de båda andra kraven kan vi använda samma teknik, men här finns det inget färdigt interface i Java. I stället gör vi ett eget: interface Adder<E> { E add (E x, E y); E getzero(); Vi låter vår metod ha en parameter av denna typ. Användare implementerar det för den valda typen E och för över ett objekt av implementerande klass vid anrop av den metoden för Dijkstras algoritm. Vi kan nu ge metoden för algoritmen följande signatur: public E shortestpath(graph<v,e> g, Graph.Vertex<V,E> from, Graph.Vertex<V,E> to, Comparator<E> cmp, Adder<E> adder) Lägg till ovanstående metodrubrik i klassen Dijkstra i paketet dijkstra (i projektet lab4). D1. För att implementera metoden ovan måste vi införa en klass för de element som läggs in i priotritetskön. Öppna klassen Dijkstra i editorn i Eclipse och lägg till en inre privat klass PrioQueueEntry. Denna klass behöver inte ha några typparametrar om den inte deklareras static. Den kan då använda de typparmetrar <V,E> som finns i den yttre klassen. Klassen skall ha två attribut och en konstruktor. Det ena attributet refererar till

21 Laboration 4 21 en nod i grafen och det andra till avståndet på den hittills kortaste vägen till noden. Det andra attributet är alltså av typen E. D2. Vi behöver kunna jämföra element av typen PrioQueueEntry med varandra eftersom de skall läggas in i en prioritetskö. Lägg därför till ytterligare en inre klass i klassen Dijkstra. Den nya klassen skall implementera interfacet Comparator<PrioQueueEntry>. Jämförelse skall göras med avseende på avståndsattributet i elementen. Detta är av typen E. För jämförelse mellan element av typen E finns det Comparator-objekt som är parameter till metoden shortestpath. Denna parameter är dock inte tillgänglig i den nya klassen. Inför därför ett attribut i den omgivande klassen och se till att i början av metoden shortestpath lagra jämförelseobjektet i detta attribut. D3. Implementera nu metoden shortestpath. D4. Metoden skall nu testas. I paketet dijkstratest finns en påbörjad testklass TestDijkstra. Det finns också några små klasser som används för att testa metoden: TimeAndDistance är en klass med två heltalsattribut : tid och avstånd. I testklassen TestDijkstra skapas grafer av typen DiGraph<String,TimeAndDistance> TimeAndDistanceAdder är en klass som implementerar interfacet Adder<TimeAndDistance>. Ett objekt av denna klass förs i testen över till shortestpath. DistTimeComparator och TimeDistComparator. Båda implementerar interfacet Comparator<TimeAndDistance>. Den första utför jämförelse på distans i första hand och tid i andra hand. Den andra jämför på tid i första hand och distans i andra hand. Kör testen som finns i TestDijkstra. Korrigera eventuellt din kod i klassen Dijkstra tills alla test går igenom.

22 22 Laboration 5 Laboration 5 Mål: Att behärska och kunna implementera en algoritm för beräkning av maximalt flöde i ett nätverk. Läsanvisningar Denna algoritm finns inte i läroboken men har behandlats på föreläsning. Studera relevanta bilder från denna föreläsning på kursens hemsida. Förberedelser Läs igenom texten under rubriken Datorarbete. Lös uppgiften D1. Läs igenom och påbörja uppgift D2. Datorarbete Under denna laboration ska en algoritm för beräkning av maximalt flöde genom ett nätverk implementeras. Grafer används ofta för att representera nätverk. Om det t.ex. rör sig om pipelines för olja representerar noderna i grafen knutpunkter och bågarna representerar ledningar som förbinder vissa av dessa. Till varje båge är det knutet en viss kapacitet som anger maximal tillåtet flöde i den ledning som bågen representerar. I nätverket finns det en speciell nod (källan) där olja pumpas in i nätverket och en nod (sänkan) där den olja som pumpas genom nätverket absorberas. Generellt kan vi formulera problemet så här: Givet en riktad graf (g) med en icke-negativ kapacitet knuten till bågarna. I grafen finns det en speciell nod s (källan) som inte har några inkommande bågar och en speciell nod t (sänkan) som saknar utgående bågar. Sök ett maximalt flöde genom grafen. Ett flöde från s till t innebär att vi knyter ett visst flöde till varje båge. Flödet på en båge kan inte vara högre än bågens kapacitet. Vidare måste flöden in i en nod (summan av de flöden som knyts till inkommande bågar) vara lika med flödet ut ur noden (summan av de flöden som knyts till utgående bågar). Uppgiften är att knyta flöden till bågarna så att flödet in till t blir så stort som möjligt (vilket p.g.a. villkoren ovan är det samma som att maximera flödet ut från s). På föreläsning har Ford-Fulkersons algoritm för beräkning av maximalt flöde presenterats. Algoritmen ger efter ett ändligt antal steg det optimala flödet förutsatt att de kapaciteter som knyts till bågarna är heltal. I algoritmen brukar man förutsätta att noderna är numrerade från 0 och uppåt och att nätverket representeras av en heltalsmatris. I matrisen anger elementet på rad i och kolumn j kapaciteten för den båge som förbinder noderna i och j. Om det saknas bågar mellan vissa par av noder så är motsvarande element i matrisen 0. D1. I denna uppgift ska en matris som representerar ett nätverk utgående från en fil skapas. I projektet lab5 i kursens arbetsområde i Eclipse finns paketet maxflow. Inför i detta paket en klass MaxFlow med en konstruktor där nätverket läses in från en fil vars namn är parameter till konstruktorn. Den matris som representerar det inlästa nätverket skall vara attribut i klassen. Följande förutsättningar får göras för filen som läses: På första raden i filen finns ett heltal som anger antalet noder i grafen (n). Därefter följer en rad med ett heltal som anger antalet bågar i grafen (m) De m följande raderna har utformningen a b c där a och b är nodnummer (mellan 0 och n-1) och c är kapaciteten för bågen från a till b. Kapaciteterna är positiva heltal eller -1. Det senare anger att det inte finns någon övre gräns för kapaciteten på bågen. I matrisen kan man låta oändlig kapacitet representeras av ett (tillräckligt) stort tal.