Seminarieövningar, Algoritmer och datastrukturer

Transkript

1 LUNDS TEKNISKA HÖGSKOLA Institutionen för datavetenskap Algoritmer och datastrukturer, EDA690 Seminarieövningar, Algoritmer och datastrukturer Seminarieövningarna i kursen Algoritmer och datastrukturer ger exempel på tillämpningar av det material som behandlas under kursen. För att seminarierna skall ge bäst utbyte måste du ha läst på uppgifterna i förväg och gärna försökt lösa dem. Du måste också läsa de avsnitt som anges under förberedelser efter rubriken på varje seminarium. Aktivt deltagande i form av frågor, synpunkter och förslag till lösningar välkomnas. Alla seminarier innehåller uppgifter att lösa. Uppgifterna, som ibland är svårare än de som behandlas på programmeringsövningarna, löses av lärare vid tavlan. En del seminarier innehåller dessutom en hel del text som utgör en sammanfattning av eller ett komplement till de avsnitt i läroboken som anges under rubriken Litteratur för respektive seminarium. I något enstaka fall behandlas material som inte finns i läroboken. Med läroboken avses Data Structures & Problem Solving Using Java av Mark Allen Weiss. Lösningsförslag delas ut i samband med seminarierna.

2

3 Seminarieövning 1 Mål Innehåll Litteratur Att ge förståelse för hur man beräknar tidskomplexiteten för enkla algoritmer och belysa sambandet mellan teoretisk tidskomplexitet och verklig tidsåtgång. Att introducera interface och ge insikt om hur dessa används. Seminariet består av två delar. Den första (uppgifterna 1-3) består av problem i anslutning till de första två föreläsningarna och handlar om tidskomplexitet. Den andra delen (uppgifterna 4-6) består av en text där interface i Java behandlas. Speciellt behandlas interfacet Comparable med flera exempel. Dessutom ges en introduktion till en del av nyheterna i Java 5.0. Tidskomplexitet behandlas i läroboken kap 5. Texten om interface i detta seminarium. Interface behandlas även i läroboken 4.4. OH-bilder om Java 5.0 finns på hemsidan. Uppgift 1 I en vektor a av typ int[] finns n heltal på platserna 0..n 1. Man vill ta bort alla dubbletter av det tal som finns på första platsen i vektorn. Följande algoritm används: int index = 1; int size = n; while (index < size) { if (a[index] == a[0]) { // dubblett funnen, skifta a[index+1]..a[size-1] ett steg vänster for (int i = index; i < size-1; i++) { a[i] = a[i+1]; size--;// antal platser i a med tal insatta har nu minskat med ett else { // ingen dubblett, gå vidare till nästa plats */ index++; När inträffar värsta fallet och vad blir tidskomplexiteten då för denna algoritm? Finns det något effektivare sätt att lösa problemet? Uppgift 2 Det tar 0.5 ms för en algoritm att beräkna lösningen till ett visst problem av storlek 100. Hur lång tid skulle det ta att lösa samma problem av storlek 500 om algoritmens tidskomplexitet är a) linjär b) O(n log n) c) kvadratisk d) kubisk Förutsätt i samtliga fall att lägre ordningens termer i det exakta uttrycket för tidskomplexiteten kan försummas. Uppgift 3 Följande metoder kan användas för att beräkna den geometriska summan 1 + a + a 2 + a a n public double computegeometricsum(double a, int n) { double sum = 1; for (int i = 1; i <= n ; i++) { sum += power(a,i); return sum;

4 private double power(double a, int n) { double pow = 1; for (int i = 1 ; i <= n; i++) { pow *= a; return pow; a) Vad blir tidskomplexiteten för ett anrop computegeometricsum(a,n)? b) Ge en förbättrad algoritm som utnyttjar att a n = a*a n-1. Vad blir tidskomplexiteten nu? Definition av interface (gränssnitt) i Java Ett interface i Java består uteslutande av abstrakta, publika metoder. Det får inte finnas några konstruktorer eller attribut i ett interface. Konstanter får finnas med. /** Ett interface med två metoder p och q. */ public interface SomeInterface { void p(); int q(int x); Notera att vi inte behöver (eller bör) specificera metoderna public eller abstract, de blir de ändå definitionsmässigt i ett interface. I Java finns också abstrakta klasser En klass är abstrakt om den innehåller en eller flera abstrakta metoder, dvs metoder som inte implementeras i klassen. Man kan inte heller skapa några objekt av en abstrakt klass. De metoder som är abstrakta måste implementeras i subklasser till den abstrakta klassen. En abstrakt klass skiljer sig från ett interface genom att den kan innehålla såväl abstrakta metoder som ickeabstrakta (implementerade) metoder samt attribut. Det är dock tillåtet att en abstrakt klass enbart innehåller abstrakta metoder. En klass som skall implementera metoder från en abstrakt klass utnyttjar ärvning: public class SomeClass extends SomeAbstractClass { // Här implementeras de metoder som är abstrakta // i SomeAbstractClass (och ev ytterligare metoder) En klass implementerar ett interface genom att deklarera detta i sin rubrik och genom att implementera alla metoderna i interfacet. Klassen innehåller ofta också flera egna metoder: public class SomeClass implements SomeInterface { public void p() { // implementation av metoden public int q(int x) { // implementation av metoden // eventuellt ytterligare metoder I klassen som implementerar interfacet måste interface-metoderna vara public och de måste ha samma signatur (samma namn och samma antal, typ och ordning på parametrarna) som i inter-facet. Det är tillåtet att en klass implementerar flera interface: public class SomeClass implements SomeInterface, SomeOtherInterface { // här måste alla metoder från SomeInterface och // SomeOtherInterface implementeras. En klass kan bara ärva från en klass och därmed bara vara subklass till en abstrakt klass men kan implementera flera interface. Det är även tillåtet för en klass att ärva från en klass och implementera ett eller flera interface: public class SomeClass extends SomeOtherClass implements SomeInterface {...

5 Även om klassen SomeOtherClass och interfacet SomeInterface båda har en metod p med samma signatur leder det inte till konflikter. Klassen SomeClass behöver då inte implementera p, den ärvs från SomeOtherClass. SomeClass kan emellertid fortfarande implementera p. Denna implementation omdefinierar i så fall den som finns i superklassen SomeOtherClass. En klass som ärver från en annan ärver också implementation av de metoder som finns i superklassen. Det är detta som kan leda till olika slags konflikter om man har multipel ärvning (vilket Java inte har). En klass som implementerar ett eller flera interface ärver inte någon implementation från dessa (eftersom ingen sådan finns). Det klassen ärver är ett protokoll eller gränssnitt (bestående av metodrubriker) från de interface den implementerar. Det är tillåtet att variabler och formella parametrar har en typ som är ett interface. Om vi deklarerar en variabel SomeInterface x; så får x referera till objekt av klasser som implementerar interfacet SomeInterface. I detta fall kan därför x referera till objekt av klasserna SomeClass och även till subklasser till denna. Följande tilldelning är alltså korrekt: x = new SomeClass(...); Om vi har en metod med någon formell parameter av typen SomeInterface: public void dowork(someinterface s); så kan vi anropa metoden med aktuell parameter vars typ är SomeInterface eller en klass som implementerar detta interface: SomeClass sc= new SomeClass(...); SomeInterface si = new SomeClass(...); dowork(sc); dowork(si); Användning av interface I Java har man förutsett att en del allmänna egenskaper kan behövas för alla klasser och placerat motsvarande metoder i klassen Object. Här finns exempelvis metoden tostring() som ger alla objekt egenskapen att kunna skrivas ut, metoden hashcode() som ger alla objekt egenskapen att kunna hashkodas och sättas in i hashtabeller (kommer vi till senare i kursen). När vi själv implementerar klasser skulle vi kunna göra på liknande sätt. För att t ex ge ett antal klasser egenskapen att kunna ritas kan man ge klasserna en gemensam abstrakt superklass med en metod draw(). Därmed skapar man dock mycket märkliga ärvningshierarkier för klasser som ur modelleringssynpunkt inte har något med varandra att göra Oftast väljer man att använda interface i stället för abstrakta klasser när man vill beskriva en egenskap som kan innehas av många olika klasser inom olika ärvningshierarkier. I vårt exempel ovan skulle vi alltså kunna införa ett interface som innehåller en metod draw() och sedan låta alla klasser vars objekt skall ha egenskapen att kunna ritas implementera detta interface. Det finns en rad interface i Javas standardbibliotek, speciellt i grafikpaketen, där allmänna egenskaper såsom att kunna lyssna på mushändelser modelleras som interface. Man kan naturligtvis också själv definiera nya interface vid behov. Vi kommer här att behandla en viktig egenskap som utmärkt låter sig beskrivas med hjälp av interface, nämligen egenskapen att kunna jämföras med andra objekt av samma typ. Antag t ex att vi vill implementera en metod som söker upp största element i en vektor a med n element (n>=1). Algoritmskiss: maxelement = a[0]; for (int i = 1; i < a.length; i++) om a[i] är större än maxelement maxelement = a[i];

6 Ingenting i logiken i denna metod begränsar den till en viss slags element. Den går att använda på heltal, flyttal, strängar etc. För att återspegla denna generella karaktär skulle ett första förslag till metodrubrik kunna vara: public Object findmax(object[] a); Försöker vi nu implementera metoden råkar vi ut för en svårighet. Det finns ingen större-än-operation för objekt av klassen Object. Vi måste för att kunna implementera algoritmen ha en sådan metod och måste inskränka vår metod till att arbeta med en vektor av denna typ. I Java har man redan förutsett behovet av att kunna utöka klasser med denna egenskap genom att införa ett interface Comparable i java.lang. Detta behandlas i nästa avsnitt. Interfacet Comparable I Java 5.0 har man infört s.k. generiska klasser och interface. Mer om detta finns att läsa på kursens hemsida. Vi skall här inskränka oss till att nämna lite om generiska interface, speciellt interfacet Comparable. Ett generiskt interface kan ha en eller flera typparametrar. Ex: public interface Comparable<E> {... Typparametrar (i detta fall E) anges inom tecknen < och >. Typparametern kan användas i interfacet för att ange typ på inparametrar till metoder och för att ange typ för vad metodernas eventuellt returnerar. Ex: public interface Comparable<E> { public int compareto(e rhs); Antag att vi har ett program där vi gör statistik på förekomster av ord ur texter där följande klass förekommer: public class WordCount { private String theword; private int count;... // ordet // antal förekomster För att objekt av typen WordCount skall kunna jämföras med varandra med avseende på antalet förekomster kan vi låta klassen implementera interfacet Comparable enligt: public class WordCount implements Comparable<WordCount> { private String theword; // ordet private int count; // antal förekomster public int compareto(wordcount rhs) { return count - rhs.count;... Flera av Javas standardklasser implementerar redan det generiska interfacet Comparable<E>, t ex implementeras Comparable<Integer> av klassen Integer och Comparable<String> av klassen String. Detta utnyttjas i följande exempel där vi inför en klass Person som beskriver en person och vill att jämförelse skall avse alfabetisk ordning av personernas namn: public class Person implements Comparable<Person> { private String name; // övriga attribut public int compareto(person rhs) { return name.compareto(rhs.name); // övriga metoder i klassen Här har vi i implementationen av metoden compareto delegerat jämförelsen till att utföras av motsvarande operation i klassen String. Vi har alltså utnyttjat att klassen String har en metod med signaturen int compareto(string rhs). Metoden equals Det är viktigt att känna till att det finns en operation för jämförelse avseende likhet i klassen Object: public boolean equals(object rhs);

7 Metoden är implementerad så att resultatet av ett anrop x.equals(y) blir true enbart om x == y, d.v.s. om x och y refererar till samma objekt. Meningen är att man vid behov omdefinierar metoden i egna klasser. Det är speciellt viktigt för klasser som implementerar interfacet Comparable. Här implementeras ju metoden compareto så att resultatet blir 0 då man anser att två objekt av den aktuella typen är lika. För våra klasser i föregående avsnitt skulle detta innebära att två objekt av klassen WordCount anses lika om de har samma frekvens och att två personer anses lika om de har samma namn. Om man emellertid utför följande: får man utskriften: Person p1 = new Person("Kalle"); // Vi antar det finns en sådan konstruktor Person p2 = new Person("Kalle"); if (p1.compareto(p2) == 0) { System.out.println("Equal!") else { System.out.println("Not equal!"); if (p1.equals(p2)) { System.out.println("Equal!"); else { System.out.println("Not equal!"); Equal! Not equal! Resultatet beror på att metoden equals, som ju är definierad i superkalssen Object, jämför om objekten p1 och p2 är identiska. Det är en mycket stark rekommendation att varje klass som implementerar interfacet Comparable också omdefinierar metoden equals så att equals ger resultatet true precis när compareto ger reslutatet 0. För våra två klasser skulle det se ut så här (vi visar nu bara metoden equals): public class WordCount implements Comparable<WordCount>{ // allt som fanns förut public boolean equals(object rhs) { return compareto((wordcount) rhs) == 0; public class Person implements Comparable<Person>{ // allt som fanns förut public boolean equals(object rhs) { return compareto((person) rhs) == 0; Lägg märke till att equals har samma signatur som i klassen Object, annars skulle det inte bli omdefinition av metoden utan överlagring. Lägg också märke till hur implementationen av equals använder sig av compareto och därmed uttrycker det samband som skall råda mellan de båda metoderna. Notera dock att vi i anropet måste göra en typomvandling eftersom parametern till compareto måste vara av typ WordCount respektive Person.

8 Uppgift 4 Vad tror du anledningen är att det anses viktigt att metoderna compareto och equals är konsistenta? Uppgift 5 Vår implementation av equals ovan är egentligen för enkel. Det kontrakt för metoden equals som finns i Java innebär att: Om x inte är null skall x.equals(x) returnera true. Om x och y är objekt av olika klasser skall x.equals(y) returnera false. Om x inte är null skall x.equals(null) returnera false. Vilka av dessa regler bryter vår implementation emot? Korrigera implementationen så att vi uppfyller alla regler. Ledning: Man kan ta reda på vilken klass x är ett objekt av (runttime-type) genom anropet x.getclass(). Uppgift 6 Antag att vi i klassen Person har två namnattribut, ett för efternamn och ett för förnamn enligt följande: public class Person implements Comparable<Person> { private String familyname; private String firstname; public int compareto(person rhs) {... public boolean equals(object rhs) {... Implementera compareto och equals så att jämförelse innebär alfabetisk ordning på i första hand efternamn och i andra hand förnamn. Dvs om två personer har samma efternamn är det förnamnen som avgör vem som kommer alfabetiskt först. Generiska metoder Låt oss återgå till problemet som tidigare behandlats under seminariet: att skriva en metod findmax som tar reda på största elementet i en vektor. Vi har kontaterat att vi inte kan utforma metoden så att den har en vektor av Object som inparameter eftersom vi måste förutsätta att objekten i vektorn går att jämföra med varandra. Med utnyttjande av interfacet Comparable kan vi utforma metoden på följande sätt i Java 5.0: public static <E extends Comparable<E>> E findmax(e[] a) {... Metoden är ett exempel på en av nyheterna i Java 5.0 en s.k. generisk metod. Inparametern är en vektor där elementen är av typen E och metoden returnerar ett element av denna typ. För att tala om att E skall uppfattas som en typparameter anges detta (före uppgiften om vad metoden returnerar) inom tecknen < och >. Man kan också ange s.k. övre eller undre gränser (eng: upper/lower bounds) för typparametrar. I detta fall anger vi Comparable<E> som övre gräns för E genom att skriva <E extends Comparable<E>>. Vi anger därmed att parametern E måste vara en typ som implementerar interfacet Comparable<E>. Man förväntar sig kanske att detta skulle anges genom att skriva E implements Comparable<E>. I Java 5.0 har man dock bestämt sig för att använda ordet extends i detta sammanhang. Implementation av den generiska metoden findmax:

9 public static <E extends Comparable<E>> E findmax(e[] a) { if (a.length == 0) { return null; E maxelement = a[0]; for (int i = 1; i < a.length; i++) { if (a[i].compareto(maxelement) > 0) { maxelement = a[i]; return maxelement; Metoden är nu generell och kan användas för att söka det största elementet i alla vektorer vars element är av en typ E som implementerar Comparable<E>, t ex Person eller WordCount: Person[] persons = new Person[10]; WordCount[] words = new WordCount[1000];... Person maxperson = findmax(persons); WordCount maxcount = findmax(words); Mera om användning av interface Under denna kurs kommer vi att presentera i datalogin vanligt förekommande abstrakta datatyper (ADT). En abstrakt datatyp är en abstrakt modell med ett antal metoder för att manipulera modellen. Ett exempel som finns redan i grundkursen är lista. En lista är en abstrakt modell. Den definieras som en ordnad följd av element. Med ordning avses inte att listan på något sätt är sorterad med avseende på elementens innehåll, utan att man kan identifiera första element, sista element, efterföljare och föregångare till element. Listan kan manipuleras med metoder för insättning av nya element och borttagning av element ur listan. Man behöver också metoder för att positionera sig i listan. När man har bestämt sig för vilka metoder som skall finnas i en ADT kan man skriva en specifikation bestående av alla metodrubriker med tillhörande kommentarer. Implementationen är sedan möjlig att genomföra på flera olika sätt. Det första valet gäller vilken datastruktur som skall representera modellen, i detta fall listan. Vektor eller olika slags länkade strukturer är möjliga kandidater. När datastruktur valts kan man implementera metoderna. Det kan ibland vara lämpligt att ge användare möjlighet att välja mellan flera olika implementationer. I Javas klassbibliotek, liksom i läroboken, väljer man i flera fall att först specificera en abstrakt datatyp som ett interface. Antag att man vill ha en ADT för hanteringeng av tid. Specifikationen ges av följande interface public interface Time { public void settime(int hours, int minutes); public void addtime(int hours, int minutes); public int gethours(); public int getminutes(); public Time timediff(time othertime);... Vi kan implementera interfacet på olika sätt t ex genom att ha två heltalsattribut för timmar respektive minuter: public class ConcreteTime1 implements Time { int hours; int minutes;... konstruktor och impl av alla metoder i interfacet Time... Ett annat alternativ är att låta tid representeras av enbart antal minuter:

10 public class ConcreteTime2 implements Time { int minutes;... konstruktor och impl av alla metoder i interfacet Time... En programmerare som behöver hantera tider i ett program gör klokt i att i sina deklarationer använda interfacet Time enligt följande mönster: Time t1 = new ConcreteTime1(); t1.settime(3,58); Time t2 = new ConcretTime1(); t2.settime(2,45); Time t3 = t1.timediff(t2);... Genom att man deklarerat alla tider med typnamnet Time så kan man bara använda de operationer som finns i interfacet Time, inte eventuella ytterligare operationer som kan finnas i olika implementationer som ConcretTime1 eller ConcretTime2. Om man skulle ångra sig och vilja använda den andra implementationen är det bara på de ställen där man skapar tidsobjekt man behöver göra ändringar.. En fördel med att specificera abstrakta datatyper som interface är alltså att de då kan manipuleras i program utan att man binder sig till en speciell implementation. Om man vill skriva en metod som har en tid som inparameter gör man också klokt i att deklarera att parameterna är av typ Time, t ex public void printtime(time t) { int hours = t.gethours(); int minutes = t.getminutes(); System.out.println(hours + ":" + minutes); Därmed kan man som aktuell parameter överföra objekt av alla klasser som implementerar detta interface. Uppgift 7 Om man ur modelleringssynpunkt tycker att det kan vara lämpligt att införa ett interface med flera olika metoder kan det ibland av andra skäl vara motiverat att i stället välja en abstrakt klass. Kan du tänka ut något sådant skäl? Tips: ett interface får inte innehålla någon kod men en abstrakt klass kan innehålla både abstrakta metoder och metoder med implementation.

11 Seminarieövning 2 Mål Innehåll Litteratur Att ge förståelse för behov, utformning och användning av iteratorer för samlingar av objekt (collections). Att ge kunskaper om olika sätt att utforma listhanteringspaket. Interfacet Iterator i Java. Genomgång av de väsentliga delarna av klassen LinkedList i Java. Interfacet ListIterator. Läroboken , 6.5. Dokumentation av LinkedList och Iterator på nätet. För jämförelse med andra sätt att utforma/implementera listor och iteratorer finns avsnitten och Interfacet Iterator För klasser som representerar samlingar av element behöver man oftast något sätt att gå igenom (traversera, iterera över) alla element i samlingen. Det kan t ex röra sig om att man vill söka sig fram till en viss position i en lista som innehåller ett visst element för att sedan där sätta in ett ytterligare element. Eller det kan röra sig om att man vill gå igenom hela samlingen för att skriva ut någon uppgift om de ingående elementen. Denna egenskap, att kunna traverseras, är så allmän att man infört ett speciellt interface för detta i Java. Interfacet heter Iterator och har följande specifikation: public interface Iterator<E> { /** Return true if there are more items in this iteration */ boolean hasnext(); /** Returns a reference to the next object not yet seen by this iterator. The object becomes seen, and thus advances the iterator. */ E next(); /** Removes the last item viewed by the operation next. This method can be called only once between calls to next. Optional operation. */ void remove(); Kommentarer: Metoden remove anges vara optional d.v.s man skall inte behöva implementera den. Naturligtvis måste den finnas med i alla klasser som anger att de implementerar interfacet Iterator, annars skulle kompilatorn klaga. Vill man inte stödja operationen så implementerar man den så att den alltid genererar UnsupportedOperationException. Metoden next skall generera NoSuchElementException om det inte finns fler element. Varken UnsupportedOperationException eller NoSuchElementException behöver fångas. Alla klasser i Javas klassbibliotek som beskriver samlingar (implementerar interfacet Collection) har en metod med följande signatur: /** Returns an iterator over the elements in this collection. */ public Iterator<E> iterator(); Metoden returnerar ett objekt av en klass som implementerar interfacet Iterator<E>. Genom att anropa metoden får alltså en användare möjlighet att iterera över samlingen enligt följande mönster, där vi antar att SomeCollection<E> är en klass som implementerar interfacet Collection<E> och därmed har metoden iterator(): SomeCollection<Person> sc = new SomeCollection<Person>(); // Här sätts Person-objekt in i samlingen.... Iterator<Person> itr = sc.iterator(); while (itr.hasnext()) { Person actperson = itr.next(); // behandla actperson Märk att vi aldrig riskerar att få en NoSuchElementException när vi itererar på detta sätt. Vi kontrollerar ju först med hasnext att det är korrekt att ytterligare en gång anropa next.

12 Ett alternativt (och enklare) sätt att iterera genom samlingen är att använda den nya for-satsen i Java 5.0 enligt följande mönster: for (Person actperson: sc) { // behandla actperson Denna typ av for-sats kan användas för klasser som implementerar interfacet Iterable. Detta interface har följande specifikation: public interface Iterable<E> { public Iterator<E> iterator(); Det har alltså en enda metod vilken returnerar en iterator för en mängd objekt av typen E. Interfacet Collection ärver från interfacet Iterable: public interface Collection<E> extends Iterable<E> {... Klasser som implementerar interfacet Collection<E> måste alltså ha en metod iterator med den signatur som anges i interfacet Iterable. Det blir därmed möjligt att använda den nya for-satsen för alla sådana klasser. Uppgift 1 I stället för att låta klassen SomeCollection implementera Iterable skulle man kunna låta den implementera Iterator: public class SomeCollection<E> implements Iterator<E> { // impl av alla metoder för samlingen + alla metoder i Iterator Vad är nackdelen med denna utformning jämfört med den tidigare där klassen implementerade interfacet Iterable<E>? Implementation av iteratorer De flesta typer av samlingar finns redan färdigimplementerade i Java. Ibland kan man dock behöva skriva en egen klass (ADT) som beskriver en samling element och då behöver man antagligen också ha en operation som returnerar en iterator. Låt oss anta att vi implementerar en egen klass MySet enligt följande public class MySet<E> implements Iterable<E> { E[] elements = (E[]) new Object[..]; // Insatta element finns i denna // vektor som initialt ges en viss storlek. int size; // Antal element i mängden. // Elementen finns på platserna 0..size-1 i vektorn elements. /** Sätt in x i mängden om det inte redan finns. Returnera false om x redan fanns, annars true. */ public boolean add(e x) {... /** Undersök om x finns i mängden. */ public boolean contains(e x) {... /** Tag bort x ur mängden om det finns med */ public void remove(e x) {... /** Skapa och returnera en iterator för mängden. */ public Iterator<E> iterator() {... För att implementera den sista metoden måste vi kunna skapa objekt av en klass som beskriver en iterator för en mängd av typen MySet. Vi måste alltså först skriva en klass som implementerar interfacet Iterator<E>. Förutom metoderna hasnext, next och remove måste vi ha en konstruktor så att vi kan skapa objekt av klassen: public class MySetIterator<E> implements Iterator<E> { public MySetIterator(MySet<E> s) {... public boolean hasnext() {... public E next() {... public void remove() {...

13 Konstruktorn har som parameter den mängd till vilken iteratorn skall knytas. För att hålla reda på aktuell position för iteratorn är det i detta fall enklast att införa ett heltalsattribut index som anger platsen för det element som skall returneras vid nästa anrop av metoden next. Dessutom måste vi ha ett attribut som refererar till mängden över vilken vi itererar. Den fullständiga implementationen blir därför: public class MySetIterator<E> implements Iterator<E> { private int index; private MySet<E> theset; public MySetIterator(MySet<E> s) { theset = s; index = 0; public boolean hasnext() { return index < theset.size; public E next() { if (index >= theset.size) { throw new NoSuchElementException(); return theset.elements[index++]; public void remove() { throw new UnsupportedOperationException(); Vi har här valt att låta remove alltid generera en exception. Operationen iterator() i klassen MySet<E> får nu följande enkla implementation: public Iterator<E> iterator() { return new MySetIterator<E>(this); Uppgift 2 a) Attributen elements och size i MySet är inte privata utan saknar skyddskod, vilket innebär att de kan nås med punktnotation i klasser i samma paket. Har vi utnyttjat detta i ovanstående implementation? Skulle vi kunna göra dem privata? b) Skulle man kunna sätta index = 1 initialt i stället för 0? Vilka ändringar måste i så fall göras i metoderna? Uppgift 3 Antag att MySet<E> i stället för en vektor använde sig av en enkellänkad lista för att lagra elementen enligt följande: class ListNode<E> { E element; ListNode<E> next; //... konstruktor // Innehållet i listnoden. // Referens till efterföljande listnod. public class MySet<E> implements Iterable<E> { ListNode<E> first; // Referens till första noden, null om tom. //... metoder som ovan Implementera en ny iteratorklass för denna representation av mängden.

14 Ett citat från dokumentationen av Iterator på nätet, närmare bestämt i anslutning till metoden remove: The behavior of an iterator is unspecified if the underlying collection is modified while the iteration is in progress in any way other than by calling this method. Iteratorer kräver i allmänhet en stabil samling element att iterera över för att inte riskera att ge konstiga resultat om man utifrån tar bort eller lägger till något i den position iteratorn befinner sig. Det är oftast svårt att implementera en iteratorklass för en samling så att den ger vettiga resultat även i sådana fall. I Javas implementationer av Iterator-interfacet har man intagit en ännu striktare hållning. Man gör det omöjligt att fortsätta använda en iterator på en mängd som förändras. Det som händer är att man får ett exekveringsfel nästa gång man anropar iteratorns hasnext, next eller remove. Man brukar i dokumentationen av iteratormetoden i collection-klasserna använda ett namn på detta fenomen: iteratorn är fail-fast. Det är en stark rekommendation att vi när vi implementerar iteratorer för egna klasser gör på samma sätt. Åtminstone bör man annars klart och tydligt i specifikationen ange att man inte kan garantera att resutatet av en iteration blir det en användare förväntar sig om man modifierar mängden av element under iterationens gång. Förklaringen till att iteratorinterfacet innehåller en metod remove är just att man intagit en så strikt ståndpunkt avseende förändringar utifrån. Antag t ex att vi skulle vilja iterera oss igenom en lista för att ta bort alla element som uppfyller något visst villkor. Vi använder en iterator och rör oss framåt tills vi hittar det första elementet som skall tas bort. Därefter anropar vi listans remove-metod (vi antar att det finns en sådan som tar bort elementet i en viss position). Nu kan vi inte längre använda vår iterator eftersom mängden förändrats. Vi får skapa en ny och börja röra oss från början av listan fram till en position där vi eventuellt hittar ett nytt element som skall bort o.s.v. Detta blir klart ineffektivt. Genom att införa en remove-operation i iteratorinterfacet och ha ett strikt protokoll för denna kan man tillåta borttagningar under iterationens gång. Protokollet för remove i interfacet Iterator är: Removes from the underlying collection the last element returned by the iterator (optional operation). This method can be called only once per call to next. D.v.s. efter ett anrop av remove måste det komma minst ett anrop av next innan det är tillåtet att göra en ny borttagning. Om vi granskar den iteratorklass MySetIterator<E> som vi implementerade tidigare ser vi att denna inte uppfyller de krav som nämnts ovan. Det finns ingen som helst kontroll av om mängden förändrats sedan föregående metodanrop. Den teknik som brukar användas för att kunna göra dessa kontroller är följande: Inför i den collection-klass vi skall iterera över (i vårt fall MySet<E>) ett heltalsattribut modcount, som initialt när ett objekt av klassen skapas är 0 och som ökas varje gång en metod som förändrar mängden anropas. När man skapar ett iterator-objekt (i vårt fall ett objekt av typen MySetIterator<E>) ser man till att överföra värdet av modcount till iteratorobjektet. I metoderna hasnext och next kontrollerar man sedan att mängdens modcount-värde överensstämmer med det värde det hade när iteratorn skapades. Den förbättrade implementationen blir då: public class MySet<E> implements Iterable<E> { E[] elements = (E[]) new Object[..]; / int size; int modcount = 0; // Ökas varje gång mängden förändras. /** Sätt in x i mängden om det inte redan finns. Returnera false om x redan fanns, annars true. */ public boolean add(e x) {.. om x sätts in så utför modcount++.. /** Undersök om x finns i mängden. */ public boolean contains(object x) {...

15 /** Tag bort x ur mängden om det finns med */ public void remove(object x) {.. om x tas bort så utför modcount++.. /** Skapa och returnera en iterator för mängden. */ public Iterator<E> iterator() { return new MySetIterator<E>(this); public class MySetIterator<E> implements Iterator<E> { private int index; private MySet<E> theset; private int expectedmodcount; // Används för att kontrollera om mängden // förändrats sedan denna iterator skapades. public MySetIterator(MySet<E> s) { theset = s; index = 0; expectedmodcount = s.modcount; public boolean hasnext() { if (expectedmodcount!= theset.modcount) { throw new ConcurrentModificationException(); return index < theset.size; public E next() { if (!hasnext()) { // Observera att i hasnext kontrolleras // värdet på modcount. throw new NoSuchElementException(); return theset.elements[index++]; public void remove() { throw new UnsupportedOperationException(); Skulle man vilja implementera även remove och uppfylla dess protokoll så får man införa flera kontrollattribut i iteratorklassen. Se t ex läroboken figurerna och Uppgift 4 Skulle det kunna bli några problem med den första iteratorimplementationen för MySet<E>, d.v.s den som saknar kontroll på om modifieringar av mängden gjorts? Vilka problem blir det i så fall och i vilka situationer? Listor Bland Javas standardklasser finns det två implementationer av lista, ArrayList<E> och LinkedList<E>. (Det finns också kvar en äldre variant Vector som liknar ArrayList). ArrayList<E> använder en vektorimplementation vilket gör att vissa operationer blir kostsamma. T ex finns det en operation add(int index, E element) som lägger in element på plats index i listan. Det element som låg på plats index och alla som fanns på platser med högre indexnummer måste då skiftas ett steg åt höger i vektorn. Vi koncentrerar oss här på klassen LinkedList<E>, som använder en dubbellänkad struktur för att representera listan. Varje nod i listan innehåller alltså referenser till föregående och efterföljande nod. Noderna innehåller också en referens till ett objekt som satts in i listan. Denna referens är av typen E. Vi kan göra oss följande schematiska bild av en sådan lista med 4 element insatta:

16 Listan och dess noder Insatta objekt Några av metoderna i klassen är: /** Appends the specified element to the end of the list. Returns true. */ public boolean add(e o); /** Inserts the specified element at the specified position in this list */ public void add(int index, E element); /** Returns true if this list contains the specified element. public boolen contains(object o); /** Returns the index in this list of the first occurrence of the specified element, or -1 if the list does not contain this element. */ public int indexof(object o); /** Removes the first occurrence of the specified element in this list. Returns true if the list contained the specified element. */ boolean remove(object o); /** Returns the number of elements in this list */ public int size(); Det finns betydligt flera metoder. Titta på den fullständiga specifikationen som finns i den dokumentation av Javas standardklasser vilken du enkelt når från kursens hemsida. Kommentar : Den första add-operationen är en funktion som här alltid returnerar true, vilket kan synas egendomligt. Det hänger samman med att alla klasser i Java som representerar samlingar av något slag (eng: collections) är inordnade i en hierarki av abstrakta klasser och interface. Operationen add är specificerad i ett interface Collection<E> (som implementeras av klasssen LinkedList<E>) där man utformat den så att den via sitt returvärde informerar om insättningen lyckades. I vissa klasser som beskriver samlingar vill man nämligen förbjuda dubbletter. Då vill man att add-operationen returnerar false om man försöker sätta in ett likadant objekt som redan finns i listan. I klassen LinkedList<E> tillåts dock dubbletter och add returnerar därför alltid true d.v.s. man behöver egentligen inte bry sig om returvärdet. Uppgift 5 Skriv programsatser som givet en lista av typen LinkedList<Integer> tar bort alla objekt ur listan som innehåller talet 0 och till sist tar reda på listans storlek. Listiteratorer I en lista har man ofta behov av att röra sig både framåt och bakåt och då är interfacet Iterator<E> otillräckligt. Därför har följande utvidgade interface ListIterator<E> införts i Java:

17 public interface ListIterator<E> extends Iterator<E> { /** Inserts element into the list. Optional operation. The element is inserted immediately before the next element that would be returned by next(), if any and after the next element that would be returned by previous(). The new element is inserted before the implicit cursor; a subsequent call to next() would be unaffected, and a subsequent call to previous() would return the new element. */ void add(e x); /** Returns true if this iterator has more elements in forward direction. */ boolean hasnext(); /** Returns true if this iterator has more elements in reverse direction. */ boolean hasprevious(); /** Returns next element in list. */ E next(); /** Returns previous element in list. */ E previous(); /** Removes from list the last element returned by next or previous. Optional operation. */ void remove(); /** Replaces the last element returned by next or previous with the specified element. Optional operation. */ void set(e x); Det finns ytterligare ett par metoder som vi inte tar upp här. Tre av metoderna, add, remove och set, är valfria att implementera (optional). Om man inte vill implementera dem låter man lämpligen metoderna alltid generera UnsupportedOperationException Både next och previous skall generera NoSuchElementException om det inte finns fler element vid en framåt- respektive bakåtiteration i listan. Observera att de metoder som sätter in, tar bort eller ändrar element noga specificerar var detta sker. Man uttrycker sig här i termer av vad föregående eller nästa anrop av next() ger och undviker på detta sätt att införa begreppet aktuellt element. I stället inför man för att underlätta beskrivningen av operationerna en s.k. cursor position. Låt oss för enkelhets skull kalla detta för aktuell position eller enbart position på svenska. Positionen för en listiterator anses vara mellan det element som skulle returneras av ett anrop av previous och ett anrop av next. Om en lista har n element insatta finns det därför n+1 positioner som vi kan numrera 0..n enligt nedanstående figur. Listan och dess noder Insatta objekt Objektens nummer n-1 Positioner ^ 0 ^ 1 ^ 2 ^ n-1 ^ n Mot bakgrund av denna bild är det också enklare att beskriva resultaten av anrop av metoderna hasnext(), hasprevious(), next() och previous(). hasnext() repektive hasprevious() ger true om och endast om det finns minst ett element till höger om respektive till vänster om aktuell position. Ett anrop av next() flyttar aktuell position ett steg åt höger och returnerar det element som därvid passeras. previous() flyttar positionen ett steg åt vänster och returnerar mellanliggande element. Klassen LinkedList i Java har följande två operationer för att skapa listiteratorer: public ListIterator<E> listiterator();// ärvd från AbstractList

18 public ListIterator<E> listiterator(int index); Den första skapar en listiterator med position 0. Den andra skapar en listiterator med den position som anges av parametern. Ett anrop listiterator() är alltså ekvivalent med ett anrop listiterator(0). De listiteratorer som returneras innehåller meningsfulla implementationer även av metoderna add, remove och set. Egenskaperna hos den returnerade listiteratorn kommenteras på följande sätt i dess dokumentation på nätet: The iterators returned by the this class's iterator and listiterator methods are fail-fast: if the list is structurally modified at any time after the iterator is created, in any way except through the Iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future. Uppgift 6 Antag att vi har en lista mylist av typen LinkedList<Integer>. Skriv programsatser som utför följande a) Ändrar innehållet i alla element med tal större än 10 så att de innehåller talet 10. b) Söker upp första negativa tal. Om det finns läggs ett nytt element innehållande motsvarande positiva tal in omedelbart efter. c) Tar bort alla dubbletter ut listan.

19 Seminarieövning 3 Mål Innehåll Att ge träning i rekursiv utformning av algoritmer med implementation i Java. Att ge kunskap om hur man beräknar rekursiva algoritmers effektivitet. Övningar på att formulera, implementera rekursiva lösningar. Evaluering och analys av förslag till rekursiva algoritmer. Binära träd används i några av uppgifterna. Litteratur Rekursion behandlas i läroboken Binära träd i kap 18. Uppgift 1 I denna uppgift behandlas problemet att beräkna största talet i en vektor med n heltal (n >=1 ). Följande implementation av en algoritm för detta problem är väldigt ineffektiv: /** Tag reda på vilket av de n första elementen i v som är störst */ public int findmax(int[] v, int n) { if (n==1) { return v[0]; else if (v[n-1] > findmax(v,n-1)) { return v[n-1]; else { return findmax(v,n-1); Vad blir tidskomplexiteten i värsta fall för ett anrop findmax(v,n)? Ställ först upp den rekursionsformel som gäller för tidskomplexiteten och lös den sedan exakt med återsubstitution. Det går att göra en väsentligt effektivare implementation genom en enkel ändring. Utför ändringen och beräkna sedan tidskomplexiteten. Uppgift 2 Exemplen i denna uppgift är hämtade ur en studie gjord av Bruria Haberman och Haim Averbuch 1. Genom att samla in studenters rekursiva lösningar på olika problem försökte man göra sig en bild av vilka misstag som var vanligast. Inte bara felaktiga lösningar var i detta sammanhang intressanta utan också sådana som är onödigt komplicerade. I en del av studien lät man också andra studenter titta på lösningarna för att evaluera dem. Låt oss knyta an till detta genom att studera nedanstående rekursiva lösningsförslag till några problem. Försök i första hand för varje lösning avgöra om den är korrekt eller ej. För lösningar som du anser korrekta kan du sedan gå vidare och ge ytterligare synpunkter t ex om de kan förenklas eller göras elegantare. Försök till sist utgående från de misstag och olämpligheter som du upptäckt formulera ett antal regler/goda råd som bör följas vid utformning av rekursiva algoritmer. Observera att lösningarna är schematiskt skrivna och inte i korrekt Java-kod. a) Fyra förslag till att beräkna n!: fac(n) om n == 0 return 1 annars return n*fac(n-1) fac(n) om n==0 return 1 annars om n == 1 return 1 annars return n*fac(n-1) fac(n) om n==1 return 1 1. The Case of Base Cases: Why are They so Difficult to Recognize? Student Difficulties with Recursion. Proceedings of The 7th Annual Conference on Innovation and Technology in Computer Science Education Aarhus, Denmark June 2002.

20 annars return n*fac(n-1) fac(n) return n*fac(n-1) b) Två förslag att lösa problemet finns det en udda siffra i ett icke-negativt tal rekursivt: hasodddigit(num) om num == 0 return false annars om num % 2 == 1 return true annars return hasodddigit(num/10) hasodddigit(num) om num <= 9 om num % 2 == 1 return true annars return false annars om num % 2 == 1 return true annars return hasodddigit(num/10) c) Två förslag till till att undersöka om elementet x ingår i en lista (list.tail() används för att beteckna den lista som består av alla element utom det första i list): ismember(x,list) om list är tom return false annars om x == första elementet i list return true annars return ismember(x,list.tail()) ismember(x,list) om x == första elementet i list return true annars return ismember(x,list.tail()) d) Två förslag att räkna antal noder i ett binärt träd med roten n: count(n) om n == null return 0 annars om n.left == null && n.right == null return 1 annars om n.left == null return 1 + count(n.right) annars om n.right == null return 1 + count(n.left) annars return 1 + count(n.left) + count(n.right) count(n) om n == null return 0 annars return 1 + count(n.left) + count(n.right)

21 I uppgifterna 3-4 hanteras binära träd som byggs upp med hjälp av av följande två klasser. Klasserna finns i samma paket. Man kan då i BinaryTree använda attributen i BinaryNode genom att utnyttja punktnotation. public class BinaryNode<E> { E element; // nodens innehåll BinaryNode<E> left; // refererar till vänster barn BinaryNode<E> right; // refererar till höger barn /** Konstruktor. Ger noden innehållet x, left och right blir null */ BinaryNode(E x) { element = x; left = right = null; // metoder public class BinaryTree<E> { protected BinaryNode<E> root;// refererar till rotnoden // metoder Uppgift 3 Skriv i klassen BinaryTree en metod som med rekursiv teknik beräknar trädets höjd. Uppgift 4 Ett binärt träd sägs vara höjdbalanserat (eller ibland bara balanserat) om det för varje nod i trädet gäller att höjden av dess vänstra och högra underträd skiljer sig på högst ett. Ex: Balanserat Ej balanserat Skriv i klassen BinaryTree en operation som med rekursiv teknik undersöker om trädet är balanserat.

22 Seminarieövning 4 Mål Innehåll Att visa hur interfacet Comparator<E> för jämförelseoperationer kan användas. Att ge övning i att utforma rekursiva metoder på träd samt att introducera designmönstret Template. Exempel på utformning av en ADT för en sorterad samling element med hjälp av interfacet Comparator<E>. Exempel på rekursiva implementationer av metoder för träd. Introduktion av begreppet designmönster speciellt the Template pattern. Litteratur Läroboken 6.4, 3.7 Interfacet Comparator Vissa abstrakta modeller för samlingar av objekt bygger på att objekten går att jämföra med varandra. Detta gäller t ex prioritetskö där vi har operationer som sök upp minsta, tag bort minsta. Modellen lexikon (dictionary) med operationerna insert, find och delete förutsätter bara att vi kan jämföra objekten avseende likhet. När vi t ex använder en hashtabell för att implementera ett lexikon utnyttjar vi enbart equals-metoden. Andra implementationsalternativ bygger emellertid på att elementen är ordnade. Det gäller för binära sökträd och flera andra typer av sökträd. När vi utnyttjar dessa för implementation av lexikon öppnar sig därför också möjligheten att lägga till operationer såsom sök minsta, sök största och räkna upp (iterera) i storleksordning. Vi har hittills i dessa sammanhang utgått från att de objekt vi hanterar implementerar interfacet Comparable. Detta innebär emellertid vissa begränsningar. Antag att vi skall implementera en ADT där vi behöver kunna göra jämförelser mellan de ingående objekten och att vi utformar den enligt följande skiss: public class SomeSortedCollection<E extends Comparable<? super E>> { /** Konstruktor. Skapa en tom samling. */ public SomeSortedCollection() {... /** Sätt in x i samlingen. */ public void insert(e x) {... /** Sök upp ett objekt som matchar x i samlingen. */ public E find(e x) { övriga operationer Antag nu att vi skall använda klassen för en samling Person-objekt och att jämförelseoperationen för dessa använder personens namn (String) enligt: public class Person implements Comparable<Person> { private String name; private int phonenbr; public Person(String name, int phonenbr) { this.name = name; this.phonenbr = phonenbr; public int compareto(person rhs) { return name.compareto(rhs.name); public boolean equals(object rhs) { return compareto((person) rhs) == 0; public int getphonenbr() { return phonenbr; public String getname() { return name;

23 Om vi använder SomeSortedCollection<Person> som en telefonkatalog för ett antal personer verkar det vettigt att samlingen är sorterad efter namn. Sökoperationen man vill utföra är nog oftast av typen givet ett namn, sök upp motsvarande person i katalogen, vilket nu kan utföras med följande satser: SomeSortedCollection<Person> mycollection = new SomeSortedCollection<Person>();... här sätter vi in ett antal element... Person tofind = new Person("Kalle",0); Person found = mycollection.find(tofind); if (found!= null) { System.out.print("Kalle has phone number: " + found.getphonenbr()); Vi har här förutsatt att det finns metoder getname() och getphonenbr() för att nå attributen name och phonenbr i klassen Person. Antag nu att man önskar att även snabbt kunna söka upp en person vars telefonnummer man känner till. Om klassen SomeSortedCollection har en iterator-operation kan man naturligtvis använda sig av denna och iterera sig fram element för element tills man hittar en person med rätt nummer. Detta blir dock ineffektivt. Man skulle kunna få effektivare sökning med avseende på telefonnummer om man sätter in personerna i två olika objekt av typen SomeSortedCollection, en som är sorterad efter namn och en som är sorterad efter telefonnummer. Problemet är att med den nuvarande utformningen är detta inte genomförbart. Klassen Person skulle ju då behöva ha två olika implementationer av metoden compareto; den vi redan implementerat ovan och ytterligare en som jämför på telefonnummer. För att lösa problemet kan man i stället införa klasser som enbart innehåller jämförelseoperationer. Objekt av sådana klasser (s.k. funktionsobjekt) kan sedan överföras till aktuell collection-klass, som använder dem för att göra jämförelser. Nedan beskrivs närmare hur detta går till. I Javas standardbibliotek (paketet java.util) finns ett interface Comparator<E> som innehåller en metod för att jämföra två objekt med varandra: public interface Comparator<E> { /** Returnera resultatet av jämförelse mellan lhs och rhs. Resultatet är: <0 om lhs är mindre än rhs >0 om lhs är större än rhs =0 om lhs och rhs är lika */ int compare(e lhs, E rhs); Man kan låta en eller flera klasser implementera detta interface. Om vi vill jämföra våra Person-objekt på dels namn dels på telefonnummer kan vi införa följande båda klasser: public class NameComparator implements Comparator<Person> { public int compare(person lhs, Person rhs) { return lhs.getname().compareto(rhs.getname()); public class NbrComparator implements Comparator<Person> { public int compare(person lhs, Person rhs) { return lhs.getphonenbr() - rhs.getphonenbr(); Uppgift 1 Vi har tidigare poängterat att man när man inför jämförelseoperationer för en klass också bör omdefiniera metoden equals så att operationerna är konsistenta. När vi använder interfacet Comparable ser vi därför normalt till att equals ger resultatet true precis när compareto ger reultatet 0. Hur går det med detta krav nu när jämförelse för en viss klass kan definieras på flera olika sätt? Läs gärna om interfacen Comparable och Comparator i dokumentationen av Javas standardklasser för att se vad som sägs där. Vi behöver nu inte längre kräva att de objekt som sätts in i en samling SomeSortedCollection nödvändigtvis implementerar interfacet Comparable. Vi ger därför vår klass en ny rubrik: public class SomeSortedCollection<E>