Datastrukturer och algoritmer

En presentation över ämnet: "Datastrukturer och algoritmer"— Presentationens avskrift:

1 Datastrukturer och algoritmer
Föreläsning 7

2 Innehåll Stack, Kö Tillämpningar Konstruktion Att läsa: Kapitel 7-8

3 Stack Modell Linjärt ordnad struktur 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 Ännu fler begränsningar på operationer än Riktad lista Ordningen definieras av en före / efter relation Tillämpningar ex rekursion mha stack Web browser: lagra webadresser som nyligen besökts Back => plockar från stacken Texteditors Undokommando

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 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 Visa gränsytan Empty, Push, Isempty, top, pop Empty. Push : Konstuktorer – Objekt kan byggas mha en sekvens av först Empty och sedan Push Finns bara en sekvens som konstruerar ett objekt, jmf lista och fält där det inte spelar ngn roll i vilken ordning vi man lägger till element. Exempel på hur stack fungerar

6 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 Ax 1: En tom stack är verkligen tom Ax 2: En stack som man precis lagt ett element på är inte tom Ax 3: Om man lägger ett värde på stacken och tar bort det på en gång får man tillbaka den gamla stacken Ax 4: Om vi lägger ett värde på stacken så är det detta värde som ligger överst på stacken Ax 5: Förutsättning: Stacken är inte tom. Om man tar det översta elementet från en stack och lägger tillbaka det på resten av stacken så får man tillbaka den stack man startade med. Om en konstruktion av Stack uppfyller axiomen har man bevisat riktigheten i konstruktionen, dvs konstruktionen uppfyller den formella specifikationen Ex. Hypotes: Om man har en tom stack och lägger till (pushar) 3 element och sedan tar bort (poppar) 2 st ska det första elementet man pushade vara överst i stacken

7 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

8 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 början eller slutet av listan? Relativ komplexitet: Absolut komplexitet: sammanlagda Multiplicerar de relativa komplexiteterna ända ner till den fysiska datatypen En lösning kan vara att låta sista elementet i listan vara toppen av stacken (fig 7.3) Beror på hur listan är implementerad. Om listans sista element = fältets sista: blir fel med ovanstående [3 2 1 _ _ _] kan bli [_ _ _ 3 2 1] (1 högst upp på stacken)

9 Stack Egen struktur konstruerad mha fält Botten i slutet
Stacken läggs i slutet av fältet Push och Pop (1) Inga stora dataomflyttningar Botten i början Två stackar i samma fält Stack: 1 2 3 I fältet: [3 2 1 _ _ _] eller [_ _ _ 1 2 3]

10 Stack-interface i Java
public interface Stack { public boolean isEmpty(); public Object top(); public void push(Object v); public Object pop(); }

11 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];

12 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];

13 ArrayStack.java public Object pop() { Object elem; if(! isEmpty()) {
elem = S[top]; S[top] = null; top = top – 1; } return elem; Borde egentligen kasta ett exception om listan är tom...

14 Stack Tillämpningar Avbryter bearbetning som senare kanske återupptas
Återspårning (backtracking) Till senaste gjorda valet Hjälpstruktur för att traversera i grafer och träd Ofta använd datatyp Avbryter bearbetning (frivilligt eller ofrivilligt) som senare kanske återupptas Exempel schackbräde : placera 8 drottningar på schackbräde s a ingen hotar någon annan Systematiskt prova sig fram väljer en placering för den 1:a drottiningen väljer en placering för den 2:a drottiningen Varje val pushas på stacken … tills vi lyckas eller hamnar i en återvändsgränd (gjort alla möjliga val) Återspårar till senast gjorda valet: Poppar stacken och tittar på top-värdet poppar tills vi kan ta ett nytt val När stacken är tom har vi inga fler valmöjligheter Gäller att valpunkterna är ordnade så man kan hålla reda på nästa oprövade alternativ

15 Kö Modell Specialisering av Lista Linjärt ordnad struktur Kö
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 Vanligaste tillämpningen är som buffert mellan produktions- och konsumtionsled.

16 Kö FIFO – First In First Out Empty () → Queue(val)
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 Empty. Enqueue : Konstuktorer – Objekt kan byggas mha en sekvens av först Empty och sedan Enqueue Precis som med stack så Finns det bara en sekvens som konstruerar ett objekt : Kö är en fri typ (även Stack är det) Enqueue sätter in ett element sist i kön Dequeue tar bort första elementet i kön, förutsatt att kön inte är tom Front värdet av första elementet i kön Exempel på hur kö fungerar (jmf ex s 156) eller som i andra boken Ibland vill man veta längden på kön en lösning med grundoperationer (inte så effektiv metod) specificera i gränsytan men vill hålla den så ”liten” som möjligt definiera Length i termer av gränsytans operationer – konstruktionsberoende , men då kan man ha koll på vad som händer

17 Kö - konstruktion Lista Fronten på kön = början av listan
Listan som Fält Måste flytta hela listan vid insättning eller borttagning beroende på om köns början är i fältets början eller slut (Komplexitet O(n)) Riktad lista med 1-celler Första köelementet länkar till det andra osv Huvud som pekar ut början och slutet av kön Resonera kring problem med Kö som Fält fösa stora sjok fram och tillbaka komplex (n) Rörliga köändar men till slut slår man i väggen (fältets slut) Riktad lista med 1-celler Första ->Andra -> -- sista Pilarna pekar inte i näsans riktning Effektiviteten blir bäst så Huvud som pekar ut början och slutet av kön Visa kod Front Rear

18 Kö – Konstruktion Cirkulär vektor (”ringbuffert”) Inga omflyttningar
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 Kan använda oss av fragmentering När ett blivit för litet flytta över till ett större Bygga upp med ett antal mindre objekt en konstruktion i i stf som (t ex Lista b celler) Front = rear i både en tom kö och en full Aldrig fylla kön till sista plats (fig 8.7) Bild från sidan 165 i Janlert L-E., Wiberg T., Datatyper och algoritmer, Studentlitteratur, 2000

19 Kö Tillämpningar Buffert Bredden-först-traversering Routrar Skrivarkö
Ex. Alla websidor man kan nå med 10 klick från en given sida... Buffert mellan produktionsled och konsumentled där man vill bevara tidsföljden ha en garanti att inga produkter får ligga för länge Om man kan skilja på konsument och producent Producent: kan bara lägga data i kön Konsument: kan bara ta data från kön Har en inström och en utström

20 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

21 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ö... Specifikationen ska bestämma så lite av implementationen som möjligt Ex Front eller Dequeue på en tom kö, inte specat vad som ska hända när man gör detta Det som är ospecat kan implementeras på olika sätt

22 Robusthet och effektivitet
Användaren ska kunna 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