for(; ;) - Schleife

Ok...danke..!

> for(;;) finde ich hässlich!

Ich nicht.

> while(1) ist hingegen logisch und völlig selbsterklärend!

Das sagt etwa aus: "Tue das Folgende, solange 1 nicht 0 ist). Die erste 
Variante sagt: "Tue das Folgende in einer Schleife, und zwar ohne 
Abbruchbedingung".

> Tue das Folgende, solange 1 nicht 0 ist)

Und wehe, ein Mathematiker beweist eines Tages, dass 1 gleich 0 ist.
Meine Programme mit for(;;) werden auch dann noch endlos weiterlaufen
:-)

Ich finde for(;;) sehr schön. Das sieht nämlich irgendwie nach
Däumchendrehen aus.

while(true) wäre für mich auch noch akzeptabel, aber bei while(1)
frage ich mich immer, warum nicht while(2) oder while(-1) oder
while(0.0745)?

...rage ich mich immer, warum nicht while(2) oder while(-1) oder
while(0.0745)?...


Geht auch...

I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in
Ada the typical infinite loop would normally be terminated by
detonation.  -- Larry Wall

Wer also richtige Endlosschleifen programmieren will, sollte
auf die Programmiersprache Ada umsteigen:

1

loop

2

   Do_Something;

3

end loop;

> ...rage ich mich immer, warum nicht while(2) oder while(-1) oder
> while(0.0745)?...
>
>
> Geht auch...

Eben. Weil mir die Entscheidung für eine bestimmte Zahl so schwer
fällt, finde ich es nicht besonders logisch, überhaupt eine Zahl als
Abbruchbedingung hinzuschreiben. Was zeichnet denn die 1 vor anderen
Zahlen aus? Dass sie das neutrale Element der Multiplikation ist? Aber
das hat doch mit Abbruchbedingungen nichts zu tun.

Anderer Vorschlag:

1

#define loop for(;;)

2

3

loop {

4

  // Code

5

}

Dann sieht's fast aus wie in Ada. Oder

1

#define loop for(;;) {

2

#define end_loop }

3

4

loop

5

  // Code

6

end_loop

Jetzt sieht's noch mehr nach Ada aus, dafür aber leider nicht mehr
nach C.

> Wer also richtige Endlosschleifen programmieren will, sollte
> auf die Programmiersprache Ada umsteigen:
> loop
>   Do_Something;
> end loop;

Und in C geht's auch ganz klassisch, wie es schon auf dem Homecomputer 
in BASIC gemacht wurde:

1

loop:

2

   do_something();

3

goto loop;

@Hagen:

Du siehst die for-Schleife nur als einfache Zählschleife, aber sie ist 
in C eben flexibler. Und for(;;) ist ein Konstrukt, der extra für 
Endlosschleifen vorgesehen ist. Bei while(1) mißbraucht man die 
Schleife, indem man für die Ausführung eine Bedingung einbaut, die immer 
wahr ist.
Wie yalu schon schrieb, stellt sich auch die Frage, was die 1 so 
besonders macht, daß man gerade die verwendet.

Nein.

> Das Define "TRUE" was man in gängigen C-Standardheadern findet,

... das da aber gar nicht stehen dürfte ...

> als auch "true" als boolescher Wert entsprechen (in der Regel) einer 1

Wenn man den boolschen Wert in einen Integer konvertiert, kommt 1 raus. 
In der while-Schleife benutzt man aber die umgekehrte Konvertierung, bei 
der außer 0 alle Werte dasselbe Ergebnis liefern.

>"pre-check-loop"
>"post-check-loop"

Früher hat soetwas noch kopf- bzw. fußgesteuerte Schleife geheißen.

MW

> Und es ist eben nur in C so das man for() so benutzen kann. Ich benutze
> dementsprechend for() wirklich nur als echte Zählschleife,

In python gibt es gar keine Zählschleifen, und trotzdem gibt's da for. 
Aber es ist dort dazu da, um eine Aktion für jedes Element in einem 
Container zu machen (in manchen Sprachen als for_each o.ä. bekannt).

> ja ich gebe sogar zu das ich mir nie die Frage gestellt habe warum
> while (1) oder ähnliches unlogisch wäre,

Ich behaupte nicht, es sei unlogisch. Ich behaupte nur, daß es mit 
for(;;) einen Konstrukt gibt, der besser paßt.

> Anders ausgedrückt, jede Sprache hat ihre "Ungereimtheiten",

Endlosschleifen sind in C allerdings keine davon, denn gerade für die 
wurde extra die Möglichkeit eingebaut, bei for() die Bedingung ganz 
wegzulassen. Wenn du stattdessen while(1) schreibst und dann als 
"Ungereimtheit" ansieht, daß du da gezwungen bist, eine immer wahre 
Bedingung anzugeben, ist das nicht die Schuld der Sprache.

Daß wir uns nicht falsch verstehen: Ich bekomme jetzt nicht gleich einen 
Anfall, wenn ich ein while(1) irgendwo sehe. Nur wenn jemand es als 
"logischer" oder "eleganter" als ein for(;;) ansieht, bin ich eben 
anderer Meinung.

> Für mich ist die Programmiersprache nur ein Mittel zum Zweck, also
> ärgere ich mich nicht darüber das es Ungereimtheiten gibt, denke
> darüber nicht weiter nach, sondern löse mein Softwareproblem.

Wenn das bei mir nicht der Fall wäre, würde ich bestimmt kein C 
programmieren. ;-)

> Und wehe, ein Mathematiker beweist eines Tages, dass 1 gleich 0 ist.
Meine Programme mit for(;;) werden auch dann noch endlos weiterlaufen
:-)

Dann mache eben

1

while(!0)

2

{

3

}

Bleibt dann auch gültig, und die Frage warum 1 und nicht 2 erübrigt sich 
;-)

1

while(!0)

2

{

3

}

>>Bleibt dann auch gültig

Nein. Weil 0 gleich 1 ist, also steht da praktisch while(!1), also wird 
auch dieses nicht funktionieren xD

Zur Not halt einfach:

1

#include <stdio.h>

2

3

#define forever for(;;)

4

5

int main()

6

{

7

    forever

8

    {

9

        puts("Hello, World");

10

    }

11

    return 0;

12

}

Wobei man da auch wieder darüber streiten könnte, ob im #define ein 
for(;;) oder ein while(1) steht ;-)

Ich biete noch an:

1

#define all ;

2

#define eternity ;

3

4

for (all eternity)

5

{

6

    ...

7

}

1

#define as

2

#define long for // wer braucht schohn den Datentyp?

3

#define the (

4

#defie world ;

5

#define is ;

6

#define still ;

7

#define spinning )

8

9

as long as the world is still spinning

10

{

11

    ...

12

}

Die spinnen, die Programmierer!

1

#define as

2

#define long for // wer braucht schohn den Datentyp?

3

#define the (

4

#defie world ;

5

#define is ;

6

#define still ;

7

#define spinning )

8

9

as long as the world is still spinning

10

{

11

    ...

12

}

Ich wollte gerade auf diese innovative Schreibweise umsteigen. Allein
die Aussicht, sich nie mehr zwischen int und long entscheiden zu
müssen, rechtfertigt den Umstieg. C-Programme sehen nun fast wie Cobol
aus, das ist so einfach, dass sogar 70-Jährige (oder vielleicht nur
diese?) darin programmieren können.

Dann musste ich aber entsetzt feststellen, dass da noch zwei Bugs drin
sind. Also aus der Traum, aber vielleicht funktioniert's im nächsten
Release :-)

zwei? ich habe im Moment des Auf-Absenden-Drückens einen gesehen. Oder 
meinst du meinen Tippfehler im Kommentar?

#defie
for(;;;)

... aber warum diskutieren wir überhaupt darüber, ob nun for(;;) oder
while(1) die logischere Endlosschleife ist?

Viel logischer ist es doch, Schleifen ganz wegzulassen. Denn:

1. Schleifen sind schlechter Programmierstil. Das lernt jeder
   Lisp-Anfänger.

2. Die visuelle Analyse von Programmschleifen am Bildschirm
   schädigt die Augenmuskulatur und verschleißt Mausräder.

3. Schleifen (vor allem, wenn mehrere Schleifentypen angeboten werden)
   führen zu ressourcenfressenden Diskussionen wie dieser.

4. Schleifenkonstrukte werden mittelfristig sowieso aus den
   Programmiersprachen verschwinden, ähnlich dem Goto. Einige neuere
   Programmiersprachen wie z. B. Haskell haben schon den Anfang
   gemacht:

     http://www.haskell.org/~pairwise/intro/section4.html#part1

Also,versucht mal, die Schleifen dort zu lassen, wo sie hingehören,
nämlich an Weihnachtsgeschenken und Brautjungfern. Der Verzicht fällt
am Anfang schwer, aber manche haben sich sogar schon das Rauchen
abgewöhnt.

>> zwei?
>
> Innerhalb des for() dürfen nur zwei Semikolons sein, nicht drei.

Das war der, den ich gleich beim Abschicken gesehen habe. ;-)
Das #defie hatte ich übersehen. Fazit: Mit copy/paste wäre das nicht 
passiert.

> Schleifen gehören zum Programmieren, wie Luft zum Atmen !

Das Atmen wird völlig überbewertet. Luft ist nur eine Droge, deren 
Entzugserscheindungen sehr schnell einsetzen.

> Ich habe kein einziges Programm ohne Schleifen.

Ironiedetektor kaputt?

> Wie würde man z.B. dieses praktische Beispiel ohne Schleife machen ?

1

void spi_out2(unsigned char dat, unsigned char i)

2

{

3

    if (!i)

4

        return;

5

6

    SPI_PORT &= ~(1<<SPI_DOUT);

7

    if( dat & 1 )

8

      SPI_PORT |= 1<<SPI_DOUT;

9

    dat >>= 1;

10

    SPI_PORT |= 1<<SPI_SCK;

11

    SPI_PORT &= ~(1<<SPI_SCK);

12

13

    spi_out2(dat, --i);

14

}

15

16

void spi_out( unsigned char dat )

17

{

18

    spi_out2(dat, 8);

19

}

> Rekursionen sind Teufelszeug, braucht man wie das Ozon zum Atmen.

Wie yalu festgestellt hat, gibt es Programmiersprachen, die für 
Rekursion gut geeignet sind, und Programmiersprachen, die dafür weniger 
geeignet sind. C und C++ fallen definitiv in die zweite Kategorie, 
Sprachen wie Haskell und Lisp dagegen in die erste.

Wie man an deiner Aussage sieht, ist es schwierig Rekursion mit C++ zu 
verteidigen.

> C und C++ fallen definitiv in die zweite Kategorie, Sprachen wie
> Haskell und Lisp dagegen in die erste.

C++ würde ich nur teilweise dazuzählen. Mit Template Metaprogramming 
kann man in C++ ganze Algorithmen schreiben, die komplett zur 
Compilezeit ausgeführt werden. Da gibt's aber keine Schleifen.

@Peter Dannegger:

> Rekursionen sind Teufelszeug, braucht man wie das Ozon zum Atmen.

Eins vorweg, damit nicht der Eindruck entsteht, ich sei so ein
abgespaceter Programmierhippie: Ich programmiere, wie die meisten
anderen auch, das hauptsächlich in C/C++, und setze Rekursionen
ziemlich selten ein.

Trotzdem würde ich die Rekursion nicht verteufeln. Es ist eines von
vielen Programmierkonzepten, das - mit Verstand eingesetzt - das Leben
durchaus leichter machen kann.

> Sie verschlechtern die Lesbarkeit ...

Nicht generell. Schau dir z. B. mal zwei Quicksortroutinen in C an,
einmal mit Rekursion und einmal ohne Rekursion programmiert. Das
rekursive Programm ist etwa halb so lang und man erkennt auf den
ersten Blick das Funktionsprinzip, wohingegen die nichtrekursive
Version praktisch nur mit zusätzlicher Dokumentation zu verstehen ist.
Und diese hat mit ziemlicher Sicherheit ihrerseits einen rekursiven
Aufbau ;-)

Dasselbe gilt natürlich auch für alle anderen Algorithmen, die nach
dem Divide-and-Conquer-Prinzip arbeiten. Dieses Prinzip ist von Natur
aus rekursiv und wird auch im Kopf der meisten Leute rekursiv
dargestellt.

In einer Funktionalsprache wie Haskell sind solche Algorithmen noch
ein Stück kürzer und selbsterkärender.

> und machen dem Compiler das Leben schwer.

So soll es ja auch sein. Der Compiler für eine Programmiersprache ist
der Vermittler zwischen den unterschiedlichen Denk- und Arbeitsweisen
von Programmierer und dem Prozessor. Will man sich als Mensch nicht an
den Prozessor anpassen (d. h. anfangen, in Opcodes und Sprungadressen
zu denken), muss eben der Compiler die Umsetzungsarbeit übernehmen,
was unter Umständen in Schwerstarbeit ausartet. Das ist mir aber recht
so, wenn ich dadurch selber Arbeit sparen kann :-)

> Generell abzuraten ist von Rekursionen, die sich mehrfach aufrufen, da
> dann der Rechenzeitbedarf exponentiell ansteigt (z.B. Fibonacci).

Du rätst also von Quicksort ab, weil es exponentiellen Rechenzeitbedarf 
hat?

Bei Fibonacci oder auch Fakultät ruft sich eine Funktion nicht mit den 
selben Parametern wieder auf. Vielmehr benötigen verschiedene Pfade die 
selben Ergebnisse, so dass es vorkommt, dass die selben Parameter 
übergeben werden. Allerdings nicht direkt in Folge.

> Bei Fibonacci oder auch Fakultät ruft sich eine Funktion nicht mit den
> selben Parametern wieder auf. Vielmehr benötigen verschiedene Pfade die
> selben Ergebnisse, so dass es vorkommt, dass die selben Parameter
> übergeben werden.

Dieses Laufzeitproblem kann sich mit Memoizing beheben lassen. Oder mit 
geschickterer Wahl des Rückgabewerts. In Haskell könnte man die 
Rekursion etwa so implementieren, um lineare Laufzeit und konstanten 
Speicherbedarf zu erhalten:

1

fib n = fst (fib' n)

2

  where fib' 0 = (0, 1)

3

        fib' n = let (a, b) = fib' (n - 1) in (b, a + b)

In C++ könnte man dieselbe Idee so umsetzen:

1

int fib(int n) {

2

  return fib_helper(n).first;

3

}

4

pair<int, int> fib_helper(int n) {

5

  if(n == 0)

6

    return make_pair(0, 1);

7

  pair<int, int> x = fib_helper(n - 1);

8

  return make_pair(x.second, x.first + x.second);

9

}

Diese Rekursion wird ein guter Compiler mittels tail call optimization 
komplett wegoptimieren. Ein Teil der Unübersichtlichkeit des Codes kommt 
natürlich daher, dass C++ keine built-in Tuples kennt wie andere 
Sprachen.

Interessanterweise hat eine naive iterative Lösung in C++ genausoviele 
Zeilen wie die obige rekursive Variante:

1

int fib(int n) {

2

  int last = 0, current = 1;

3

  for(int i = 0; i < n; ++i) {

4

    int temp = last + current;

5

    last     = current;

6

    current  = temp;

7

  }

8

  return last;

9

}

Ich würde aber zustimmen, dass in C++ die iterative Variante trotz 
identischer Code-Länge einfacher zu verstehen ist als die rekursive. In 
rein funktionalen Sprachen wie Haskell dagegen kann man eine iterative 
Version wie in C++ gar nicht hinschreiben aufgrund des Fehlens von 
veränderbaren Variablen. Dennoch ist es in Haskell möglich eine sehr 
kompakte Variante des rekursiven fib-Algorithmus zu schreiben, der in 
linearer Zeit läuft:

1

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

fibs ist dann die (unendliche) Liste der Fibonacci-Zahlen. Die Funktion 
fib ist also nur noch ein Elementzugriff dieser Liste:

1

fib n = fibs !! n

Wir haben also gelernt:

- Schleifen sind, egal wie man sie schreibt, unlogisch.

- Rekursion ist Teufelszeug.

Also bleibt für die Fibonacci-Berechnung nur noch folgendes übrig:

1

long fibonacci(n) {

2

  return lround((pow(((1+sqrt(5))/2),n)-pow(((1-sqrt(5))/2),n))/sqrt(5));

3

}

Chris schrieb:

> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Das ist genau das, was ich an Funktionalsprachen so cool finde *. Man
kann mal eben in einer Zeile eine unendliche Liste mit nichttrivialem
Inhalt hinschreiben. Und die Ausführungszeit dafür ist trotzdem
endlich, sie dürfte sogar verschwindend gering sein.

Und der Code ist absolut selbsterklärend, selbst für einen Nicht-
Haskellianer wie mich. Ich glaube, ich muss mir demnächst doch mal ein
Haskell-Tutorial reinziehen.

*) ... und weswegen ich Peters Argument falsch finde, ein Compiler
dürfte kein schweres Leben haben ;-)


@Hagen Re:

Deinen Fibonacci-Algorithmus finde ich ebenfalls cool. Er ist zwar
nicht ganz selbsterklärend ;-), scheint aber in logarithmischer Zeit
zu laufen (unter der Annahme, dass die Einzeloperationen in konstanter
Zeit laufen) und benötigt im Gegensatz zu obiger Lösung nur
Integer-Operationen.

@Peter Dannegger:

> yalu wrote:
>
>>> fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
>
>> Und der Code ist absolut selbsterklärend, selbst für einen Nicht-
>> Haskellianer wie mich.
>
> Das ist schön für Dich.
>
> Aber für mich wäre er in Chinesich geschrieben genau gleich gut zu
> verstehen (also wie das Uhrwerk fürn Schwein).

Naja, ich geb zu, die Syntax ist schon etwas kryptisch, aber wer C
kann, sollte durch kryptische Syntaxen nicht mehr abgeschreckt werden
können :-)

> + in Klammern finde ich schonmal lustig, muß also was völlig anderes
> sein als + ohne Klammern, aber was ?

Chris mag mich korrigieren, wenn ich jetzt Krampf erzähle. Wie schon
geschrieben, kann ich kein Haskell.

Aber ich schätze mal, ein + in Klammern notiert die Additionsfunktion
als solche, die als Argument (ähnlich einem Funktionspointer in C) an
die Funktion zipWith übergeben wird. Ohne die Klammern würde
wahrscheinlich versucht, zipWith mit fibs zu addieren, was wenig Sinn
ergibt.

> "zipWith" und "tail" sind das reservierte Wörter in Haskell oder
> Biblitoheken oder eigene Funktionen, was machen die ?
>
> Was machen die : ?

Es sind Funktionen. Ob die bereits in der Sprache definiert sind und
damit Schlüsselwortcharakter haben, oder ob es Bibliotheksfunktionen
sind, weiß ich nicht, ist zum Verständnis aber unerheblich.

  tail <liste>

liefert als Ergebnis alle Elemente der Liste außer dem ersten (Vom
Namen her könnte es auch sein, dass sie nur das letzte Element
liefert, aber wie soll das bei einer unendlich langen Liste gehen?).

  zipWith <funktion> <liste1> <liste2>

bildet aus den Elementen der beiden Listen Paare (zip ==
Reißverschluss *) und lässt auf jedes dieser Paare die Funktion los.

Die Doppelpunkte sind wohl die Trennzeichen der Elemente einer Liste.

In dem Beispiel wird also rekursiv eine Liste fibs gebildet, deren
erste Elemente 0 und 1 sind, und deren restliche Elemente sich aus der
paarweisen Addition der Ergebnisliste fibs mit der Ergebnisliste ohne
das erste Element (tail fibs) ergeben:

  fibs      = 0 1 1 2 3 5 ... (Ergebnis vorweg genommen)
  tail fibs = 1 1 2 3 5 ...   (Ergebnis ohne die 0)
  ------------------------------------------------------
  Summe     = 1 2 3 5 8

Diese Summenliste wird an die beiden Anfangselemente 0 und 1
angehängt:

  fibs      = 0 1 1 2 3 5 8 ...

fertig.

> Wie würde denn mein SPI-Beispiel in Haskell aussehen ?

Weiß ich nicht. Zum Schreiben von Programmen braucht's etwas mehr
Kenntnisse als zum Lesen. Vielleicht hat Chris einen Vorschlag.
Und wenn ich irgendwann ein Haskell-Tutorial durchgelesen habe, werde
ich die Lösung hier posten (falls man in Haskell wirklich alles machen
kann und das Tutorial von guter Qualität ist ;-)).

> Ich komme leider aus der Hardwareentwicklung, d.h. ich denke in
> Abläufen, also was passiert wann.

Leider? Ich mache auch etwas Hardwareentwicklung, habe es aber bisher
nicht bereut. Oft denke ich bei der Hardwareentwicklung auch in
Abläufen. Aber bei einem gegengekoppelten Verstärker (wo du weiter
unten das Thema Rückkopplung ansprichst) denke ich eher in Richtung
Fixpunktbestimmung einer Funktion.

> Timingdiagramme liebe ich, da versteht man sofort, was wie passiert.
> Für mich ist nicht wichtig, was passiert, sondern wann es passiert.

Dass dir völlig egal ist, was in deiner Schaltung passiert, kann ich
eigentlich nicht ganz glauben.

> Da sieht man immer wieder schöne Ablauffehler, wenn man sich
> Quelltexte von reinen Softwareentwicklern ansieht.
>
> In der Hardware ist nicht das Ergebnis allein wichtig, sondern
> stimmt auch der Weg bis dahin.

Klar. Aber es muss halt beides stimmen: Der korrekte zeitliche Ablauf,
aber auch die Rechenergebnisse, die irgendwelche Algorithmen
ausspucken. Falsche Ergebnisse zum richtigen Zeitpunkt sind mindestens
genauso schlecht wie richtige Ergebnisse zum falschen Zeitpunkt.

> Z.B. muß ich einen Kondensator über einen Widerstand laden, dann
> braucht das eine bestimmte Zeit und eine bestimmte Spannung. Der
> Softwerker würde einfach die Zeit verkürzen und die Spannung erhöhen
> (z.B 10000V).

Wenn's der Kondensator und die Platine mitmachen, warum nicht? Zeit
ist Geld :-) und warten tut keiner gerne.

> Schleifen sind das direkte Äquivalent zur Rückkopplung, praktisch
> keine Schaltung funktioniert ohne Rückkopplung. Daher sind Schleifen
> für Hardwerker super einfach zu verstehen.

Hmm, wenn ich mir die Übertragungsfunktion, z. B.

  y = f(x1, x2, x3, 0)

einer offenen (also nicht rückgekoppelten) Schaltung anschaue und
schließe nun den Rückkopplungspfad

  y = f(x1, x2, x3, y)

dann sieht das für eher nach einer Rekursion als nach einer Schleife
aus.

In der Schaltung ist die Rückkopplung natürlich als Draht- oder
Leiterbahnschleife realisiert, aber diese Sorte Schleife hat ja nun
wirklich nicht viel mit einer Softwareschleife zu tun.

*) Beim Erraten der Funktion von zipWith hatte ich zugegebenermaßen
den Vorteil, dass ich hin und wieder etwas in Python mache. Dort gibt
es eine Funktion zip, die die Elemente von n Listen zu n-Tupeln
zusammenfasst. Die dem zipWith entsprechende Funktion heißt in Python
allerdings map.

@Hagen Re:

Funktioniert hat der Algorithmus bei mir aber trotzdem nicht. F ist am
Anfang 1, wird etliche Male quadriert und am Schluss als Ergebnis
zurückgegeben. Kann es sein dass da beim Kopieren irgendwo eine Zeile
verloren gegangen ist?

Ich habe mal versucht, etwas nach dem gleichen Prinzip in C aufzubauen:

1

unsigned long fib(n) {

2

  unsigned long a=1, b=n, m=0, tmp;

3

4

  do {            // äquivalent zu

5

    m = b;        //   m = (int)floor(log2(n));

6

    b = m & m-1;  //   b = 0;

7

  } while(b);     //

8

9

  while(m) {

10

    tmp = a*a + b*b;

11

    b = 2*a*b + b*b;

12

    a = tmp;

13

    if(n & m) {

14

      tmp = b;

15

      b = a+b;

16

      a = tmp;

17

    }

18

    m /= 2;

19

  }

20

  return b;

21

}

So scheint's zu gehen.

> Man hat also 3 Quadrierungen wenn man's bischen umschreibt.

Klar kann man das Ganze noch optimieren, wobei das für normale
32-Bit-Integers der Compiler schon tut. Der Unterschied zwischen der
Multiplikation verschiedener Zahlen und der Quadrierung kommt hier
auch nicht zum Tragen und die Multiplikation mit zwei geht sowieso
fix.

Aber du hast schon recht, wenn man das Ganze mit großen Zahlen
rechnet, muss man etwas umdenken.

> PS: falls du weitergehendes Interesse hast schick mir ne PN, ich
> will ungern diesen Thread kapern

Vielen Dank für das Angebot. Aber im für's Erste ist mein Durst nach
Fibonacci-Zahlen gelöscht. Ich beschäftige mich normalerweise mit
anderen Dingen, trotzdem war es eine sehr interessante Diskussion.

Was mich höchstens noch interessieren würde: Wozu brauchst du diese
Monster-Fibonacci-Zahlen? Hat das etwas mit Kryptographie zu tun?