ist eine rekursive Funktion schneller als vier schleifen ineinander?

gramboler

Hallo,....ich habe da mal eine Frage LOL

angenommen ich hätte vier for Schleifen ineinander geschrieben, also etwa so:

for (int i = 0; i<10000; i++)
{
   for (int j = 0; j<10000; j++)
   {
      for (int k = 0; k<10000; k++)
      {
         for (int l = 0; l<10000; l++)
         {
           //... hier steht irgendein Code
         }
      }
   }
}

dann könnte ich doch hingehen und für eine Schleife eine Funktion schreiben und diese dann viermal ineinander aufrufen.
Wäre dies dann schneller als der von mir geschriebene Code?

ciao und vielen Dank

PS: Ich habe es nicht ausprobioert weis also nicht ob es geht.

GPC

PS: Ich habe es nicht ausprobioert weis also nicht ob es geht.

und warum probierst du es dann nicht aus?

Im Übrigen frisst Rekursion fast immer deutlich mehr Speicher als ne Iteration, das solltest du auch bedenken.

MfG

GPC

Javaner

GPC schrieb:

Im Übrigen frisst Rekursion fast immer deutlich mehr Speicher als ne Iteration, das solltest du auch bedenken.

... und ein paar Nanosekunden deines wertvollen Lebens gehen durch den Overhead
der Funktionsaufrufe auch flöten.

Wenn du tatsächlich immer nur 4 ineinander verschachtelte Schleifen
hast, bleib' bei der iterativen Lösung.

Wenn die Anzahl deiner Schleifen aber variieren kann, ist Rekursion die
eleganteste und einfachste Lösung.

GPC

Javaner schrieb:

GPC schrieb:

Im Übrigen frisst Rekursion fast immer deutlich mehr Speicher als ne Iteration, das solltest du auch bedenken.

... und ein paar Nanosekunden deines wertvollen Lebens gehen durch den Overhead
der Funktionsaufrufe auch flöten.

das Leben ist hart.

Wenn die Anzahl deiner Schleifen aber variieren kann, ist Rekursion die
eleganteste und einfachste Lösung.

Mag sein, aber ich sehe auch, dass Rekursion deutlich überstrapaziert wird. Sie wird z.T. eingesetzt, wo eine iterative Lösung deutlich besser wäre. Ich denke einfach, man sollte zuerst versuchen, ein Problem iterativ zu lösen. Wenn sich die iterative Lösung aus irgendeinem Grund nicht bewährt, sollte man versuchen, sie zu verbessern. Gelingt dies nicht, kann eine rekursive Lösung durchaus sinnvoll sein.

Aber ich finde es nicht gut, wenn man sagt: "Hey, das könnte man auch rekursiv lösen. Also los geht's..."

MfG

GPC

Javaner

GPC schrieb:

Aber ich finde es nicht gut, wenn man sagt: "Hey, das könnte man auch rekursiv lösen. Also los geht's..."

Da gebe ich dir vollkommen Recht!

Aber

GPC schrieb:

Ich denke einfach, man sollte zuerst versuchen, ein Problem iterativ zu lösen.

Schön! Dann nehme ich dich beim Wort und habe da eine kleine Langeweile-Aufgabe:

Schreibe eine Funktion

schleifi(int n) die n for-Schleifen von 1 bis 2 generiert und im innersten
Schleifenkörper die aktuellen Werte der Laufvariablen ausgibt.

Bin gespannt auf deine iterative Lösung

GPC

Javaner schrieb:

GPC schrieb:

Ich denke einfach, man sollte zuerst versuchen, ein Problem iterativ zu lösen.

Schön! Dann nehme ich dich beim Wort und habe da eine kleine Langeweile-Aufgabe:

Sorry, aber mir ist nicht langweilig...

Schreibe eine Funktion

schleifi(int n) die n for-Schleifen von 1 bis 2 generiert und im innersten
Schleifenkörper die aktuellen Werte der Laufvariablen ausgibt.

Bin gespannt auf deine iterative Lösung

Schon gut, da dürfte iterativ... uh... schwierig werden. Hier ist ein rekursives Vorgehen sinnvoll/notwendig. Aber das entkräftet meinen obigen Satz trotzdem nicht. Ich hab die Aufgabe gelesen, festgestellt dass iterativ hier nicht wirklich taugt und bin zum rekursiven Ansatz gegangen. Dennoch überlegte ich zuerst, ob ich es nicht iterativ lösen kann. So what?

MfG

GPC

Javaner

Dann ist ja eigentlich alles klar.

Ich hatte es nur auf deine Aussage
Wenn sich die iterative Lösung aus irgendeinem Grund nicht bewährt, sollte man versuchen, sie zu verbessern. Gelingt dies nicht, kann eine rekursive Lösung durchaus sinnvoll sein.
abgesehen und wollte darauf hinaus, das es überhaupt erstmal eine iterative
Lösung geben muß, bevor man entscheidet ob sie sich bewährt.

Im Übrigen gibt es für meine Aufgabenstellung durchaus eine iterative
Lösung. Es ist nur so, daß in solchen Fällen eine rekursive Lösung
einfach von Haus aus naheliegender ist und man nicht unbedingt
immer zuerst nach iterativen Lösungswegen Ausschau halten soll.

Michael E.

GPC: Ich finds leicht übertrieben, wie du hier Rekursion darstellst.

Im Übrigen frisst Rekursion fast immer deutlich mehr Speicher als ne Iteration, das solltest du auch bedenken.

Das "deutlich mehr" sind ein paar Byte für den Funktionsaufruf und der wird oft (wie in diesem Fall) sowieso wegoptimiert.

Sag mir mal bitte die Vorteile von Iteration gegenüber Rekursion. Ich mach mal den Anfang:
- unter Umständen übersichtlicher

Moh

Das "deutlich mehr" sind ein paar Byte für den Funktionsaufruf und der wird oft (wie in diesem Fall) sowieso wegoptimiert.

wenn bei jedem funktionsaufruf eine variablenkopie gemacht wird ist das dann schon ganz anders...

zu den vorteilen:
ich finde rekursive funktionen immer sehr kryptisch, und muss diese immer erst entschluesseln... iterative loesung -> einfacher zu lesen

Javaner

Moh schrieb:

ich finde rekursive funktionen immer sehr kryptisch, und muss diese immer erst entschluesseln

Da würde ich mal raten daß du nicht rekursiv denkst, sondern zu imperativ.

Bei imperativen Programmen hat man immer alles unter Kontrolle und
steuert jede Einzelheit selbst.

Gute rekursive Funktionen delegieren. Da kann man einfach denken:

Vorausgesetzt die rekursiven Aufrufe erledigen ihren Teilbereich.
Dann liefer deren Lösungen, kombiniert mit den restlichen Anweisungen
der Methode, die Gesamtlösung.

Also behaupte ich mal das Gegenteil:

(Gute) rekursive Funktionen sind leichter zu lesen und einfacher zu
verstehen, da sie des ganzen Ballasts der Steuerung entbehren.

GPC

Michael E. schrieb:

GPC: Ich finds leicht übertrieben, wie du hier Rekursion darstellst.

Im Übrigen frisst Rekursion fast immer deutlich mehr Speicher als ne Iteration, das solltest du auch bedenken.

Das "deutlich mehr" sind ein paar Byte für den Funktionsaufruf und der wird oft (wie in diesem Fall) sowieso wegoptimiert.

Da du nicht genau weißt, wie viel sich dein rekursives Programm vom Stack abschneidet, wäre ich mit dieser Aussage vorsichtig. Bedenke: Lokale Variablen werden bei jedem Aufruf angelegt. Hier ist es oft eh sinnvoller, einiges über den Heap zu regeln.

Sag mir mal bitte die Vorteile von Iteration gegenüber Rekursion. Ich mach mal den Anfang:
- unter Umständen übersichtlicher

Weniger Ärger mit evtl. zyklischen Abhängigkeiten (A ruft B auf, B ruft C auf, C ruft wieder A auf...), obwohl sich diese auch wieder in eine große Routine umwandeln lassen, die dann aber mehrere Aufgaben erledigt und damit gegen die Regel "Eine Routine soll eine Aufgabe erledigen" verstösst.

Ich denke, dass es einige wenige Probleme gibt, bei denen es mit einer Rekursion wunderbar elegante und simple Lösungen gibt, dann gibt's noch ein paar mehr Probleme für die's immer noch einfache und simple, jedoch etwas unverständliche (bzw. nicht sinnvolle, siehe Fibonacci-zahlen) Lösungen gibt. Für die meisten Probleme führt Rekursion meiner Erfahrung nach zu komplizierten Lösungen, die keinem helfen.

Wie viele Informatik-Bücher (nicht nur die Einsteiger-Bücher, auch Literator zu Datenstrukturen & Algorithmen) erklären die Rekursion an der Fakultät oder den Fibonacci-Zahlen? Was für ein Schwachsinn! Hier ist man mit iterativen Lösungen viel besser dran. Ich sage ja nicht, dass Rekursion kein mächtiges Werkzeug ist, aber gerade aus diesem Grund muss man es imho äußerst umsichtig einsetzen.

MfG

GPC

c.rackwitz

*klick*

*klack*

net 0

Javaner schrieb:

Schreibe eine Funktion
schleifi(int n) die n for-Schleifen von 1 bis 2 generiert und im innersten
Schleifenkörper die aktuellen Werte der Laufvariablen ausgibt.

void schleifi (int n)
{
   while (n--)
   {
      printf ("int s;\n");
      printf ("for (s=1; s<3; s++)\n");
      printf ("{\n\tprintf (\"%%d\", s);\n}\n\n");
   }
}