Bug im FPC? (bei rekursiven Funktionen)

[pluto]

Code: Alles auswählen

function nocrash(n:integer):real;
var
  test:Real;
begin
  case n of
  0:    Result:=0;
  1..100: begin
      test:=nocrash(n-1);
      Result:=test+test;
    end;
  end;
end

Ich weiß nicht ob das geht, bin gerade an einem Rechner ohne Lazarus(leider).
Aber Theo hat schon Recht damit das es nicht gerade sinvoll ist, 2 mal eine Funktion in einer Rekusion aufzurufen. ich könnte mir vorstellen das mein Beispiel klappen könnte..... Im Prinzip machst du ja nix anders..... oder teusche ich mich jetzt ?

[Euklid]

Ich weiß nicht ob das geht, bin gerade an einem Rechner ohne Lazarus(leider).

Ja, das geht. Dann tritt der Bug nicht mehr auf.

Aber Theo hat schon Recht damit das es nicht gerade sinvoll ist, 2 mal eine Funktion in einer Rekusion aufzurufen.

Naja, der Bug tritt auch in den Routinen von unserem CAS-Programm auf. Da finde ich ihn nicht so doll...

[pluto]

Wobei es bedeutet ja auch Speed Verlust bei der Ausführung der Funktion.... ich weiß zwar nicht genau was du da berechnest, aber ich könnte mir vorstellen das es längern dauert wenn man zweimal das gleiche macht.....

oder ?

[monta]

ne...die Rekursion wird ja nen Sinn haben und denn erfüllen.

Ich denk mal, Euklid macht das nicht, um nur zweimal das selbe zu machen

[pluto]

Das sah für mich aber so aus....

[Euklid]

Das sah für mich aber so aus....

Nun, die crash-Funktionen habe ich nur gepostet, weil hier der Bug offensichtlich wird.
Die Originalfunktion habe ich weiter oben gepostet, die nennt sich Funkwert_NM. Dort kannst du sehen, dass ich nicht zweimal dasselbe ausführe.

[Euklid]

Meint ihr, es ist in Ordnung, wenn ich im FPC-Bugtracker einfach das Lazarus-Projekt poste?

Habe nämlich keine Ahnung, wie man eine "Methode" mit dem FP-Editor programmiert (eine "normale" Funktion bekomm ich noch hin). Habe das eben mal probiert, mit fehlendem Erfolg.

[monta]

ich denk, das passt schon.

Kannst es ja dazu schreiben bzw. den relevanten Code nochmal direkt in die Nachricht posten.

[Euklid]

So. Hier ist der Report:

http://www.freepascal.org/mantis/view.php?id=9919" onclick="window.open(this.href);return false;

[schnullerbacke]

Von der Logik her führt er die erste Rekursion solange aus, bis diese abbricht. Erst dann würde der zweite Aufruf rekursiv ausgeführt. Das sieht also nicht nur "abenteuerlich" aus, das macht auch irgendwie nicht wirklich Sinn.

Der additive Anteil wird erst dann ermittelt, wenn die erste Rekursion vollständig ist. Das bedeutet dann aber auch, das alle Aufrufe der ersten wieder abgebaut sind. Damit kann dann aber die Addition nicht mehr wirklich klappen, weil die erste Rekursion bereits den Endwert erreicht hat. Die werden also nicht genau nacheinander ausgeführt.

Ergibt dann also:

Arg:= Endwert(Rekursion1) + Rekursion2;

Das bedeutet Rekursion1 ist gestorben bevor Rekursion2 startet, der Ergebnispointer ist also weg. Ich würde das eher für einen Fehler halten wenn es geht.

Ob du das wirklich so gemeint hast?

[Euklid]

Von der Logik her führt er die erste Rekursion solange aus, bis diese abbricht. Erst dann würde der zweite Aufruf rekursiv ausgeführt. Das sieht also nicht nur "abenteuerlich" aus, das macht auch irgendwie nicht wirklich Sinn.

Wie schon oft erwähnt: Ja, es macht so keinen Sinn. Dies ist NICHT die Original-Funktion, bei der der Bug aufgetreten ist..

Das bedeutet Rekursion1 ist gestorben bevor Rekursion2 startet, der Ergebnispointer ist also weg.

Ja, das ist aber auch so, wenn du die Rekursion durch beliebige andere Funktionen ersetzt. Etwa sin(n) und cos(n). Bevor die eine aufgerufen wird ist die andere natürlich fertig - vielleicht wird das mit den Multicore-CPUs einmal anders, in der sin(n) und cos(n) parallel gerechnet werden könnten. In einer Single-Thread-Anwendung gilt dein Satz aber für alle Funktionen und nicht unbedingt nur für die Rekursion.

Ich würde das eher für einen Fehler halten wenn es geht.

Es gibt definitiv Anwendungsfälle. An einem arbeite ich gerade. Simples Beispiel: Mathematische Funktionen/Terme können beliebig verschachtelt auftreten: (((sin(x^2))))+(((sin(x^2)))) hier kannst du beliebig viele Klammern noch hinzufügen - die mathematische Funktion ist trotzdem korrekt und ein Parser muss diesen Umstand auflösen können. Dies kann nur über Rekursion geschehen, da die beiden Summanden beliebig aussehen können, beliebig verschachtelt sein können und nicht unbedingt gleich sein müssen.

[pluto]

http://www.delphipraxis.net/topic109566 ... v+funktion" onclick="window.open(this.href);return false;
da wird es auch so angewendet wie du es in deinen beispiel gemacht hast....

[schnullerbacke]

@Euklid

Kann aber sein, das Rekursionen sich etwas anders verhalten. Der jeweilige Aufruf wird ja auf dem Stack registriert und bei beenden der Rekursion vom Stack wieder gelöscht. Bei Aufruf der nächsten Rekursion baut er dann möglicherweise den letzten Eintrag ab und verwirft dabei das Zwischenergebnis. Das führt dann natürlich zum Pointer-Fehler.

Das würde auch erklären warum es geht, wenn man des Ergebnis von Rekursion 1 zwischenspeichert und erst dann Rekursion 2 aufruft.

[Euklid]

Ja, Rekursive Funktionen können komplexe Muster bilden. Aber meiner Meinung nach sollte ein Kompiler soetwas durchaus unterstützen. Fast alle naturwissenschaftliche Programme beinhalten teils komplexe Rekursionen, wäre ja ein Dinge, wenn soetwas in einer Sprache nicht vergesehen wäre.


PS: Der Bug wurde offenbar schon "gefixt".