© Anders Broberg, Lena Kallin Westin, 2007 Datastrukturer och algoritmer Föreläsning 4.

En presentation över ämnet: "© Anders Broberg, Lena Kallin Westin, 2007 Datastrukturer och algoritmer Föreläsning 4."— Presentationens avskrift:

1 © Anders Broberg, Lena Kallin Westin, 2007 Datastrukturer och algoritmer Föreläsning 4

2 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 2 Innehåll  Stack, Kö  Tillämpningar  Konstruktion  Dubbeländad kö  Genomgång av Routeruppgiften  Att läsa: Kapitel 7-8

3 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 3 Stack  Modell  Papperstrave  Kommer bara åt det översta arket  Kan bara lägga till nytt överst  Linjärt ordnad struktur  Före /efter relation  Specialisering av Lista oÄnnu fler begränsningar på operationer än Riktad lista

4 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 4 Stack  Andra namn på Stack är ”Pushdown list” och ”LIFO list”  LIFO – Last In First Out  Insättning, borttagning, avläsning i toppen av stacken  I listan behövdes en position, detta behövs inte här (eftersom vi bara håller oss till toppen)

5 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 5 Gränsyta till Stack abstract datatype Stack(val) Empty () → Stack(val) Push (v:val,s:Stack(val)) → Stack(val) Top (s:Stack(val)) → val Pop (s:Stack(val)) → Stack(val) Isempty (s:Stack(val)) → Bool  Empty och Push är konstruktorer  Alla objekt kan byggas med först Empty och sedan en sekvens av Push

6 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 6 Informell specifikation till Stack  Empty – konstruerar tom stack  Push(v,s) – lägger (ett element med värdet) v överst på stacken  Top(s) – är värdet av det översta elementet på stacken (förutsatt att inte stacken är tom)  Pop(s) – avlägsnar det översta elementet från stacken (förutsatt att inte stacken är tom)  Isempty(s) – testar om stacken är tom

7 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 7 Formell specifikation till Stack Ax 1: Isempty(Empty) Ax 2: ¬Isempty(Push(v,s)) Ax 3: Pop(Push(v,s)) = s Ax 4: Top(Push(v,s)) = v Ax 5: ¬Isempty(s) => Push(Top(s), Pop(s)) = s

8 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 8 Stack konstruerad som Lista  Uteslutningar och specialiseringar av operationer  Empty konstrueras som List-Empty  IsEmpty(s) konstrueras som List-IsEmpty(s)  Top(s) konstrueras som List-Inspect(s, List-First(s))  Pop(s) konstrueras som List-Remove(s, List-First(s))  Push(v, s) konstrueras som List-Insert(s, v, List-First(s))  Relativ komplexitet:  Tittar bara på ”ytan” hur många list-operationer som behövs per stack-operation  Antalet listoperationer är inte beroende av antalet element i stacken

9 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 9 Stack konstruerad som Lista  Absolut komplexitet:  Multiplicerar alla relativa komplexiteter ned till fysiska datatyper.  Dvs tittar även på hur listan är konstruerad.  Lista som fält  Tidskomplexiteten ökar (måste flytta stacken fram och tillbaka)  Push och Pop förväntas vara oberoende av stackens storlek  Toppen av stacken obörjan eller slutet av listan?

10 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 10 Stack  Egen struktur konstruerad mha fält  Botten i slutet oStacken läggs i slutet av fältet –Push och Pop  (1) –Inga stora dataomflyttningar  Botten i början  Två stackar i samma fält

11 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 11 Stack-interface i Java public interface Stack { public boolean isEmpty(); public Object top(); public void push(Object v); public Object pop(); }

12 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 12 ArrayStack.java public class ArrayStack implements Stack { public static final int CAPACITY = 1000; private int capacity; private Object S[]; private int top = -1; public ArrayStack() { this(CAPACITY); } public ArrayStack(int cap) { capacity = cap; S = new Object[capacity]; }

13 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 13 ArrayStack.java public boolean isEmpty() { return (top < 0); } public void push(Object obj) { if ((top+1) < capacity) { top = top + 1; S[top] = obj; } public Object top() { return S[top]; }

14 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 14 ArrayStack.java public Object pop() { Object elem; elem = S[top]; S[top] = null; top = top – 1; return elem; }

15 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 15 ArrayStack i C  Kod från Weiss bok finns på sidan  http://www.cs.fiu.edu/~weiss/dsaa_c2e/files.html http://www.cs.fiu.edu/~weiss/dsaa_c2e/files.html  Där finns en ArrayStack som är väldigt lik vår java-implementation.

16 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 16 Stack  Egen struktur konstruerad mha fält  Botten i början  Botten i slutet oStacken läggs i slutet av fältet –Push och Pop  (1) –Inga stora dataomflyttningar  Två stackar i samma fält  Egen struktur mha av länkade celler oHärma riktad lista mha 1-celler oO(1) för push och pop

17 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 17 Stack  Tillämpningar  Avbryter bearbetning som senare kanske återupptas  Återspårning (backtracking) oTill senaste gjorda valet  Hjälpstruktur för att traversera i grafer och träd

18 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 18 Stack  Tillämpningar  Rekursion  Fakultet n! ofactorial(n) –if (n<=1) then return 1; –else return n*factorial(n-1);  Evaluering av uttryck

19 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 19 Kö  Modell  Kö  Specialisering av Lista  Begränsningar på operationer  Insättning görs bara i en ände (slutet, rear),  Borttagning görs i andra änden (början, front),  Avläsning: oftast bara intresserad av läsa av det första elementet i kön  Pos behövs inte eftersom man bara är intresserad av vad som händer i början och slutet av kön  Linjärt ordnad struktur

20 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 20 Kö  FIFO – First In First Out abstract datatype Queue(val) Empty () → Queue(val) Enqueue (v:val,q:Queue(val)) → Queue(val) Front (q:Queue(val)) → val Dequeue (q:Queue(val)) → Queue(val) Isempty (q:Queue(val)) → Bool

21 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 21 Kö - konstruktion  Lista  Fronten på kön = början av listan  Listan som Fält oMåste flytta hela listan vid insättning eller borttagning beroende på om köns början är i fältets början eller slut  Riktad lista med 1-celler o Första köelementet länkar till det andra osv oHuvud som pekar ut början och slutet av kön FrontRear

22 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 22 Kö – Konstruktion  Cirkulär struktur med 1-celler  Länken i slutet av kön pekar på fronten FrontRear

23 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 23 Kö – Konstruktion  Cirkulär vektor (”ringbuffert”)  Indexen cirkulärt ordnade. I en vektor med n element är indexmängden {0,1,..., n-1}  Next(x) = (x+1) mod n  Prev(x) = (x-1) mod n + Inga omflyttningar - Maximal storlek - Outnyttjat utrymme - Problem skilja tom kö ifrån en full Bild från sidan 165 i Janlert L-E., Wiberg T., Datatyper och algoritmer, Studentlitteratur, 2000

24 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 24 Kö  Tillämpningar  Buffert o Routrar oSkrivarkö  Bredden-först-traversering oEx. Alla websidor man kan nå med 10 klick från en given sida...

25 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 25 Modell för datatypens byggande  Specifikatören – utformar specifikationen  Vet inget om implementatören och dennes resurser.  Har fått reda på vad användaren tror sig behöva.  Vill ge en spec som ”håller” i evighet => kanske inte överensstämmer med det användaren vill ha  Implementatören – implementerar specen  Går enbart efter specifikationen  Användaren – använder implementationen  Vet inget om implementationen, känner endast till specifikationen, får hålla till godo med det som erbjuds

26 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 26 Felhantering  Specifikationen bestämmer implementationens spelrum  Ska styra så lite som möjligt  Ex. Ej specat vad som händer om man gör Front eller Dequeue på en tom kö.  Implementatören  ska uppfylla specifikationen... och inte mer!  Användaren  bör inte konstruera algoritmer som beror på ospecifierade förhållanden  dvs ska aldrig göra Front på en tom kö...

27 DoA VT -07 © Anders Broberg, Lena Kallin Westin, 2007 27 Robusthet och effektivitet  Robusthet  Användaren kan begå misstag utan att det leder till katastrof  Effektivitet  specifierar felhantering => robust lösning men mindre effektiv  Tex att alltid kolla indexgränser i en array...  En del felhantering blir implementationsberoende  Det kan man inte ha med i en specifikation som ska vara oberoende.  Tex i Lista/Stack/Kö som Fält finns risk för overflow  Om inte felhantering är specificerad får användaren göra avvägningarna mellan robusthet och effektivitet