Rekursion. L. Piepmeyer: Funktionale Programmierung - Rekursion

Transkript

1 Rekursion 1

2 Iterative und rekursive Methoden Summe von 1 bis n berechnen: iterativ rekursiv public int sum(int n){ int result = 0; for(int i=1; i<=n; i++){ result += i; return result; public int sum(int n){ return n<=0? 0 : n + sum(n-1) ; 2

3 Zutaten zur Rekursion Abbruchkriterium Selbstaufruf 3

4 Komplexität Laufzeit sum - iterativ: O(n) sum - rekursiv: O(n) Speicherbedarf? 4

5 Der Stack-Frame sum(3) sum(2)+3 (sum(1)+2)+3 ((sum(0)+1)+2)+3 ((0+1)+2)+3 (1+2) Mit jedem Rekursionsschritt werden Daten, die nach der Rückkehr benötigt werden, auf dem Stack zwischengelagert. 5

6 Komplexität Speicherbedarf : sum - iterativ O(1) sum - rekursiv O(n) 6

7 Wie verarbeitet Java die Rekursion? public int sum(int n){ final Stack<Integer> stack = new Stack<Integer>(); while(n>0){ stack.push(n); int result=0; n--; while(!stack.empty()){ result += stack.pop(); return result; So ähnlich verarbeitet die VM die rekursive Variante von sum 7

8 Bytecode der rekursiven Variante public int sum(int); Code: 0:iload_1 1:ifne 8 4:iconst_0 5:goto 17 8:iload_1 9:aload_0 10: iload_1 11: iconst_1 12: isub 13: invokevirtual #18; //Method sum:(i)i 16: iadd 17: ireturn 8

9 Endrekursive Summenbildung private int sum(int n, int accu){ if (n<=0) return accu; return sum(n-1, n+accu); public int sum(int n){ return sum(n,0); Macht der Compiler daraus iterativen Code mit konstantem Speicherbedarf? 9

10 Endrekursion Keiner der getesten Java-Compiler erzeugt iterativen Code Dafür gibt es auch Gründe (JIT-Kompilation des Bytecodes) Erzeugt der JIT-Compiler aus dem Bytecode iterativen nativen Code? 10

11 Welche JIT-Compiler erkennen Endrekursion? Apple? Nein Sun? Nein IBM JA! Aber: Wird der Code nur geringfügig geändert hier mit? : wird die Endrekursion nicht mehr erkannt. return n<=0? 0 : sum(n-1, n+result); 11

12 Endrekursion Java: Kein Verlass auf Java-Compiler und JIT- Compiler Funktionale Sprachen: Viele Formen der Endrekursion werden vom Compiler verlangt dies. Das Ergebnis der Übersetzung ist eine speicherfreundliche iterative Variante. 12

13 Der rekursive GAU Unbedachte Rekursion kann dramatische Folgen haben public int fib(int n){ return n<=1? n : fib(n-1)+fib(n-2); Man kann nachweisen, dass Laufzeit und Speicherbedarf von fib exponentiell wachsen! 13

14 Eine freundliche Variante private int[] fibworker(int n){ if(n==0) return new int[]{0,1; else{int[] result=fibworker(n-1); return new int[]{result[1], result[1]+result[0]; public int fib(int n){ return fibworker(n)[0]; Lineare Laufzeit und linearer Speicherbedarf 14

15 Eine freundliche, endrekursive Variante private int fib(int n, int i, int f1, int f2 ){ if(0==n) return 0; if(i==n) return f2; return fib(n, i+1, f2, f1+f2); public int fib(int n){ return fib(n,1,0,1); 15

16 Vorsicht mit Vorurteilen Rekursive Funktionen müssen nicht langsam sein: Bei sum ist der Anteil für die Verwaltung des Stacks sehr groß, da wenig gerechnet wird. Unterbricht man beide Varianten bei jedem Schritt um 1 Millisekunde ist kein Unterscheid messbar!! 16

17 Pro Rekursion Rekursive Funktionen sind fast immer (!) klarer. Bsp: Quicksort Ackermann-Funktion Iterative Varianten dieser Verfahren benötigen einen eigenen Stack! Die rekursiven Varianten sind oft schneller als die iterativen Varianten. 17

18 Alles klar? Rekursive Funktionen können langsam und hungrig auf Speicherplatz sein, da bei ihrer Ausfuhrung teilweise viele Daten auf dem Stack abgelegt werden. Rekursive Funktionen kann man teilweise als endrekursive Funktionen schreiben. Einige Compiler erkennen und eliminieren die Endrekursion und erzeugen Code, der iterativ ausgeführt wird. 18

19 Alles klar? Die iterativen Varianten von rekursiven Funktionen benötigen auch oft einen Stack und haben ähnliche Laufzeiten wie ihre rekursiven Varianten. Rekursiv formulierte Funktionen sind meistens besser lesbar als iterative. 19