Hallo,
für eine Zahlenspielerei, den Pi-Code www.cadaeic.net/picode.htm, versuche ich möglichst viele Dezimalstellen eines Bruchs, hier konkret der Näherung von Pi, in das 26ziger System umzuwandeln.
Während die Transformation einer natürlichen Zahl natürlich kein Problem ist, stoße ich hier an meine Grenzen.

Habe ich die Dezimalzifferfolge 0,abcde... gegeben, so multipliziere ich den ganzen Bruch mit der Zielbasis 26 durch. Der entstehende ganzzahlige Anteil ist meine nächste Ziffer. Mit dem gebrochenen Anteil verfahre ich wieder so usw.
Und da liegt das Problem.

In meinem Beispielprogramm benötigt mein Rechner für 10000 Ziffern 0,3 s, bei 100000 Ziffern schon 30,3 s; alles ohne Ausgabe. Rechne ich das auf mein eigentliches Ziel von mehr als 1 Milliarde Ziffern um, so dürfte die Sonne schon ein Weißer Zwerg sein, bevor ich zum Ziel kommen würde. Nun nicht ganz. Es wäre "nur" etwa 100 Jahre Rechenzeit!

Kennt jemand ein schnelleres Verfahren, die Dezimalziffern eines Bruchs in ein beliebiges Positionssystem zu transformieren? Die Behandlung der Kommastellen als riesengroße natürliche Zahl bringt nichts, da z.B. 0,14159 im 26er Sytem die Zeichenfolge [0,3HIF60...]26 besitzt, 14159 dagegen [KOF]26.

Dem Programm liegt noch eine Datei pi.000 bei, die 1 Million Nachkommaziffern von Pi enthält. Deshalb ist der Anhang auch relativ groß. Jedes Mal Pi erst ausrechnen, war mir zu aufwendig.

Vielen Dank für Hinweise und beste Grüße
Mathematiker

Rev 1: Die Ziffern werden nicht mehr nur mit der Basis, sondern mit Basis^Exponent berechnet. Der Exponent wird so gewählt, dass kein Arithmetiküberlauf entsteht.
Außerdem habe ich einen schweren Fehler entfernt. Das Programm berechnete nur die ersten Stellen korrekt.
Rev 2: Int64 wieder auf Integer geändert. Berechnung läuft schneller ab.
Rev 3: Integer gegen Cardinal getauscht, da bei kleinen Basen "Blödsinn" berechnet wurde.
Rev 4/5: zusätzlich mit Demonstration des PI-Codes.
Rev 6: deutliche Beschleunigung der Umwandlung und weitere Ergänzungen.
Rev 7: zusätzlich mit Umwandlung in PI-Code 27.

Als erstes würde mir einfallen, nicht nur eine Ziffer zu extrahieren sondern gleich mehrere auf einmal. Ist vielleicht auch langsamer aber einen Versuch wäre es Wert.
==> Nicht mit 26 multiplizieren sondern mit 26^2 oder gar 26^3 und dann aus dem Ganzzahlanteil direkt bis zu 3 Ziffern errechnen.

Steffen,

ich weiß nicht, wie Du es Dir vorstellst, aber leider ist ja das Problem, dass jede Dezimalziffer einen Bruchteil in dem jeweiligen Ziffernsystem darstellt:

im Zehnersystem:

0,01 = 1/10^2 = 1/100
0,0005 = 5/10^4 = 5/10000

das Gleiche im 26er:

0,01 = 1/26^2 = 1/676
0,0005 = 5/26^4 = 1/456976

wenn Du z.B. also eine (!!) x-beliebige Ziffer (im Nachkommabereich) des 10er in das 26er-System umwandeln willst, erhältst du (da 26 und 10 ja nicht nur gemeinsame Teiler haben) einen rationalen (vereinfacht, periodischen) Bruch mit mehreren Ziffern als Ergebnis. Also bei der Genauigkeit von 1 Millionen Ziffern ebenfalls eine Millionen Ziffern.

Demhingehend ist die Umwandlung der Ziffern vor dem Dezimalkomma einfacher, da es zwar auch mehrere Ziffern aus einer werden, aber die "Bruchfolge" endet bei der ersten Vorkommastelle, als Rest der Bruchrechnung:

3000 im Zehner: 3000:676 = 4 Rest 296; 296:26 = 11 Rest 10 somit ergibt sich : 3000(10) = 4BA(26)


Ich hoffe, mich verständlich gemacht zu haben.

Hallo,

wie esjfheins vorschlägt , habe ich es auch bei www.entwickler-ecke....ewtopic.php?p=457804 gemacht.
Die Nachkommastellen mit 1e5 multiplizieren und die entstehenden Vorkommastellen ausgeben.
Wobei Format die Umwandlung zu Basis 10 macht.

Bei 200000 Stellen funktionierte das einwandfrei.
Man kann also mit 26^3= 17576 als Faktor arbeiten und so immer 3 neue Stellen bestimmen.
Ich hatte aber die Zahl als Binärzahl, wodurch der Einsatz von Assembler für die Multiplikation leicht möglich war ohne die aufwendigen DIV/MOD Rechnereien, um bei der Basis 1e6 zu bleiben.
Es gibt aber auch subquadratische Basisumwandlungen, aber wo ?
gmplib.org/manual/Binary-to-Radix.html

Gruß Horst

Hallo,
vielen Dank für Eure Hinweise.

Das Multplizieren mit mehr als der Basis ist eine sehr gute Idee.
In der Revision 1 multipliziere ich jetzt mit Basis^Exponent, wobei der Exponent so gewählt wird, dass kein Arithmetiküberlauf entsteht. Für die 26 ist es 26^6, für die Basis 2 sogar 2^29.

Leider hat sich herausgestellt, dass meine Lösung einen extremen Fehler hatte. Da ich zuwenig PI-Ziffern eingelesen habe, wurden nur die ersten Stellen korrekt berechnet.
Aufgefallen ist es mir, als ich als Basis 10 wählte und viele, viele Nullen bekam.

Schlimm ist nur, dass jetzt 10000 Stellen schon 4,1 s benötigen, 100000 Ziffern sogar 7 Minuten, d.h. es ist noch viel schlechter als vorher, trotz des größeres Faktors.

Beste Grüße
Mathematiker

Horst_H hat folgendes geschrieben :

Es gibt aber auch subquadratische Basisumwandlungen, aber wo ? gmplib.org/manual/Binary-to-Radix.html

MPArith hat auch schon seit mehr als einem Jahr eine subquadratische mp_radix_astr-Routine, basierend auf dem FastIntegerOutput-Algorithmus in Brent/Zimmermann's Buch Modern Computer Arithmetic (PDF vom Author über maths-people.anu.edu...rent/pub/pub226.html) und halt GMP.

Hallo,

@Gammatester:
dann müsste man dies wie testen?
Stellenzahl S_10 von pi als String einlesen( die 3 zu Beginn weglassen) und zu einem mpint wandeln als rationalen Bruch RZ durch 10^S_10 teilen.
Dieses RZ mit neueBasis^neueStellenzahl multiplizieren -> RZ und den ganzzahligen Anteil GZ von RZ bestimmen.
Dieses GZ dann zur Basis neueBasis zu einem String konvertieren.

@Mathematiker zu Revision1:
Int64 ist auch wesentlich langsamer als mit 32-bit integer zu rechnen.
Muss der Übertrag nicht von unten ( groesse-1) nach oben ( 1) gerechnet werden?


Gruß Horst

Das Problem bei der umwandlung von pi() vom Zehner in ein anderes System sind die dazu notwendigen Operatuionen mit einer Genauigkeit von 1 Millionen Stellen!!!!! Das kann man nicht durch einfaches Dividieren zweier Zahlen oder Multiplizieren derselben erreichen, weil die Genauigkeit dieses Ergebnisses bestenfalls 29 Stellen oder ähnliches beträgt. Hier muss sozusagen jede einzelne Stelle in eine Ziffernfolge des anderen Systems überführt werden. Und dann die einzelnen Ergebnisse der Überführung der einzelnen Stellen Addiert werden. Was dann wieder zu Verschiebungen einzelner Ziffen wegen Überlaufes führen kann. Aber das kann am Ende der ganzen Operation sozusagen von hinten nach vorne abgearbeitet werden. Was will ich mit letztem sagen: Angenommen man erhielte durch Addition folgende "Ziffernfolgen" im 26er System:

0, 23, 3, 56, 8, 5, 45, 5, 0, 9, 98

dann wäre die Abfolge der Bereinigungsoperation:

0, 23, 3, 56, 8, 5, 45, 5, 0, 12, 20
0, 23, 3, 56, 8, 5, 45, 5, 0, 12, 20
0, 23, 3, 56, 8, 5, 45, 5, 0, 12, 20
0, 23, 3, 56, 8, 5, 45, 5, 0, 12, 20
0, 23, 3, 56, 8, 6, 19, 5, 0, 12, 20
0, 23, 3, 56, 8, 6, 19, 5, 0, 12, 20
0, 23, 3, 56, 8, 6, 19, 5, 0, 12, 20
0, 23, 5, 4, 8, 6, 19, 5, 0, 12, 20
0, 23, 5, 4, 8, 6, 19, 5, 0, 12, 20

Endergebnis:

0, 23, 5, 4, 8, 6, 19, 5, 0, 12, 20

(Anmerkung: Durch dieAbarbeitung von Hinten nach Vorne benötigt man nur genau x Operationen für x Stellen, da ja automatisch jede Ziffer auf den Bereich 0..n-1 normiert wird. (n = Basiszahl des Zahlensystems)

Aber - wie gesagt, die Ziffern müssen - soweit ich weiß - für jede Ziffer des alten Zahlensystems im neuen Zahlensystem belegt werden. Und das kann logischerweise bei 1 Millionen Ziffern etwas dauern. Einen Vorteil hat das Ganze jedoch. Die Belegung der Ziffern des neuen Zahlensystems sollte immer eine periodische Folge ergeben, so dass man nur einmal die Periode ermitteln muss, und dann kann man einfach die Periode in die folgenden Positionen kopieren.

Aus:de.wikipedia.org/wik...imalbruchentwicklung

Jede reelle Zahl lässt sich einer Dezimalbruchentwicklung zuordnen. Bemerkenswerterweise besitzt jede rationale Zahl eine periodische Dezimalbruchentwicklung, jede irrationale Zahl dagegen eine nichtperiodische (beachte: eine endlich abbrechende Dezimalbruchentwicklung ist ein Spezialfall der periodischen Dezimalbruchentwicklung, bei der sich nach der endlichen Ziffernfolge die Dezimalziffer 0 oder 9 periodisch wiederholt).

Der sich wiederholende Teil wird mit einem Überstrich kenntlich gemacht.

Beispiele sind:
1/3 = 0,3 = 0,33333… = [0,01]2
9/7 = 1,285714 = 1,285714 285714… = [1,010]2
1/2 = 0,50 = 0,50000… = [0,10]2
1 = 1/1 = 1,0 = 0,9 = 1,00000… = 0,99999… = [1,0]2 = [0,1]2

In den eckigen Klammern sind die entsprechenden Entwicklungen im Dualsystem angegeben. Mehrstellige Perioden sind hier jeweils durch Leerzeichen abgetrennt.
Auch die b-adischen Bruchentwicklungen zu anderen ganzzahligen Zahlenbasen b <> 10 sind für alle rationalen Zahlen periodisch und für alle irrationalen Zahlen nichtperiodisch

Hallo Horst_H,

Horst_H hat folgendes geschrieben :

Int64 ist auch wesentlich langsamer als mit 32-bit integer zu rechnen.

Danke für den Hinweis. Ich habe es wieder auf integer (Rev 2) geändert und nun läuft es wieder schneller: 1 s für 10000 Ziffern, 98 s für 100000.

Horst_H hat folgendes geschrieben :

Muss der Übertrag nicht von unten ( groesse-1) nach oben ( 1) gerechnet werden?

Hier nicht, da die ersten Ziffern nach dem Komma im 1.Glied des Feldes stehen.

Hallo Tranx,
Dein Hinweis klingt sehr interessant. Es wird aber etwas dauern, bis ich das richtig verstanden habe.

Beste Grüße
Mathematiker

Ich versuche das mal in einer Excel-Datei zu veranschaulichen. Aber irgendwie habe ich da einen Kn oten im Kopf. Bei Bruchzahlen klappt das, doch bei Ganzzahlen habe ich da noch Probleme.

Hallo,
damit es vielleicht besser klar wird, was ich eigentlich bezwecke, habe ich in Revision 4/5 die PI-Codesuche ergänzt.
Dabei wird in der Buchstabenfolge (26er System) von PI nach dem Auftreten von sinnvollen deutschen Wörtern gesucht. Im rechten Teil kann dazu die Wortlänge von 3 bis 8 festgelegt werden. Bei der Suche wird aus einer Liste von 13500 Wörtern etwas Brauchbares ermittelt.
3- und 4buchstabige Wörter findet man schnell, ein 5-buchstabiges bis 15000 Stellen nicht, dagegen OXYGEN (deutsch?) ab Stelle 11602. 7buchstabige oder längere deutsche Wörter sind, meines Wissens nach, noch nicht gefunden worden.
Natürlich ist das alles nur Spielerei, aber interessant doch irgendwie.

Und außerdem:
Wenn die Kreiszahl eine normale, irrationale Zahl ist, so müssen alle möglichen Buchstabenkombinationen irgendwann einmal in der Ziffernfolge auftauchen. Auch wenn es kaum vorstellbar ist, so muss man ab einer noch so fernen Stelle auch den Text dieses Beitrages finden, ebenso jedes irgendwann einmal von einem Menschen geschriebene Buch und alle die in Zukunft noch geschrieben werden! D.h., PI enthält das ganze schon erworbene und jemals erwerbbare Wissen! Unvorstellbar!

Von mathematischer Seite aus ist die Umwandlung von transzendenten Zahlen in andere Positionssysteme ohnehin interessant.

Beste Grüße
Mathematiker

Hallo,

ist die Suche nach Texten nicht eher eine statistische Analyse.
Man stellt sich doch dann eine irrationale Zahl als perfekte Zufallsbuchstabenfolge vor.
Wie groß ist die Länge dieser Folge, um zum Beispiel einen Satz wie "was ist denn das fuer ein sinnfreies zeug" mit einer Wahrscheinlichkeit von 50% zu finden.
Oder die Fragestellung, ab wieviel Stellen habe ich alle 7-buchtstabigen Zeichenfolgen gefunden.
Im Grunde läuft es darauf hinaus, das wir wahrscheinlich nie soviel Stellen von Pi berechnen können, um einen sinnhaften längeren Text zu finden.

Gruß Horst

Mathematiker hat folgendes geschrieben :

D.h., PI enthält das ganze schon erworbene und jemals erwerbbare Wissen! Unvorstellbar!

Ich denke, daß ist zu vereinfacht ausgedrückt! So enthält (die Dezimalentwicklung von) Pi ja noch nicht einmal die Dezimalentwicklung von 1/7 ganz zu Schweigen von anderen wie zB 2Pi.

Hallo Horst_H,

Horst_H hat folgendes geschrieben :

Wie groß ist die Länge dieser Folge, um zum Beispiel einen Satz wie "was ist denn das fuer ein sinnfreies zeug" mit einer Wahrscheinlichkeit von 50% zu finden.

Für 50% Wahrscheinlichkeit brauchst Du bei diesem Satz etwa 10^53 Stellen von PI. Also wird man ihn mit großer Wahrscheinlichkeit nicht finden.
Würde jedes Atom im sichtbaren Weltall (etwa 10^85) eine Stelle von PI speichern, dann sind gerade mal 60buchstabige Folgen mit 50% zu finden.
Natürlich ist das alles nur theoretisch. Faszinierend finde ich die Vorstellung von einem PI mit allen möglichen Zeichenfolgen doch.

Horst_H hat folgendes geschrieben :

Im Grunde läuft es darauf hinaus, das wir wahrscheinlich nie soviel Stellen von Pi berechnen können, um einen sinnhaften längeren Text zu finden.

Ja, leider.

Hallo Gammatester,

Gammatester hat folgendes geschrieben :

Ich denke, daß ist zu vereinfacht ausgedrückt! So enthält (die Dezimalentwicklung von) Pi ja noch nicht einmal die Dezimalentwicklung von 1/7 ...

Vollkommen klar. Ich habe mich falsch ausgedrückt. Besser wäre: "Jede Zeichenfolge (Gespräch, Artikel, Buch, ...), die ein Mensch bisher oder in Zukunft von sich gibt."
Da dies endlich ist, stimmt's wieder.
Andererseits. Wenn PI im mathematischen Sinne eine normale Zahl ist (de.wikipedia.org/wiki/Normale_Zahl), dann gibt es in ihr jede beliebige Näherung von 2PI.
Die unendliche Folge von 2PI kann ein Mensch ja ohnehin nicht erfassen.
Ich weiß, dass ist jetzt schon ziemlich "philosophisch".

Dennoch, noch einmal. Das ist alles nur eine kleine Spielerei.
In seinem genialen Buch "Contact" hat Carl Sagan über eine im Dualsystem in PI verschlüsselte Botschaft spekuliert.
Im Buch enthält die Binärdarstellung von PI bei einer unvorstellbar hohen Stellenzahl dieses Muster:

Zitat:

000000000000000000000000000000000000000 000000000000000000100000000000000000000 000000000000000100000001000000000000000 000000000000100000000000001000000000000 000000000100000000000000000001000000000 000000010000000000000000000000010000000 000001000000000000000000000000000100000 000010000000000000_00000000000000010000 000100000000000000000000000000000001000 001000000000000000000000000000000000100 010000000000000000000000000000000000010 100000000000000000000000000000000000001 100000000000000000000000000000000000001 010000000000000000000000000000000000010 001000000000000000000000000000000000100 000100000000000000000000000000000001000 000001000000000000000000000000000100000 000000010000000000000000000000010000000 000000000100000000000000000001000000000 000000000000100000000000001000000000000 000000000000000100000001000000000000000 000000000000000000100000000000000000000 000000000000000000000000000000000000000

Viele interpretierten, Sagan hätte einen transzendenten Schöpfer gemeint. Er war aber glühender Atheist (wie ich auch) und fand die ganze Sache nur interessant.

Beste Grüße
Mathematiker

Hallo
von Horst_H habe ich eine deutlich verbesserte Umwandlungsroutine erhalten, die ich in Revision 6 eingebaut habe. 100000 Stellen im 26er-System werden jetzt in nur 10 Sekunden ermittelt.

Die Hauptidee von Horst_H war, die Anzahl der Multiplikationen der Feldglieder mit fortlaufender Berechnung sinnvoll zu verkürzen. Dafür besonderen Dank.
Eine weitere Idee von Horst_H die Multplikation mit ASM zu beschleunigen, muss ich erst noch richtig verstehen.

Weiterhin habe ich ein paar kleinere Änderungen vorgenommen. Die Ausgabe kann nun direkt in eine Datei picode.26 erfolgen, was natürlich schneller ist.
Bei der Suche nach Wörtern kann nun auch rückwärts gesucht werden.

Heute habe ich mit der neuen, schnellen Methode 2 Millionen Stellen im 26er-System in rund 2 Stunden ermittelt. Unter diesen konnte ich noch kein 7buchstabiges Wort finden. Bei der Rückwärtssuche entsteht aber schon relativ zeitig ALPHORN.
Am Wochenende will ich 5 Millionen Stellen erreichen. Aufhören werde ich wohl erst, wenn das erste sinnvolle Wort mit 7 Buchstaben gefunden ist.

Beste Grüße
Mathematiker

Hallo,

bei mir brauchen 100000 Stellen mit Deiner exe 11,7 Sek, mit Lazarus 1.0.2 ( welches TabWidth für Listbox nicht kennt ) kompiliert, sind es 2,69 Sek. Es hat sich also doch etwas getan.
Der Löwenanteil der schlechten Rechenzeit geht aber auf die Verarbeitung des Strings t. Deine Revision5 brauchte bei mir für 100000 Stellen sage und schreibe 218 Sekunden.
Aber es ändert nichts an der Tatsache, das diese Vorgehensweise durch ihr quadratisches Laufzeitverhalen nicht zu schnellen Zeiten führt.

Gruß Horst

Eine sinnvolle Ergänzung wäre es, die Verteilung der einzelnen Buchstaben mit auszuwerten. Außerdem könnte das Ganze ja auf ein 29er System erweitert werden. Dann müsste als Buchstaben 26 - 28 die Buchstaben "Ä", "Ö" und "Ü" genommen werden.

Ich nehme mal an, dass die Verteilung der "Buchstaben" annähernd gleichverteilt ist, was ja der "normalen" Verteilung in einem Text widerspricht. "E" ist in vielen Texten sehr viel häufiger als z.B. "L" oder gar "Q", "X".

Hallo,

Horst_H hat folgendes geschrieben :

Aber es ändert nichts an der Tatsache, das diese Vorgehensweise durch ihr quadratisches Laufzeitverhalen nicht zu schnellen Zeiten führt.

Ja, leider. Ich habe jetzt eine "Dauertransformation" gestartet, 10 Millionen Zeichen. Nach der ersten Schätzung wird es etwa 40-45 Stunden dauern.
Ich überlege schon, ob es eine elegante Lösung gibt, schon vorhandene berechnete 26er-Ziffern um weitere zu ergänzen, ohne alle noch einmal zu berechnen. Im Moment habe ich noch keine Idee.

Tranx hat folgendes geschrieben :

Eine sinnvolle Ergänzung wäre es, die Verteilung der einzelnen Buchstaben mit auszuwerten. Außerdem könnte das Ganze ja auf ein 29er System erweitert werden. Dann müsste als Buchstaben 26 - 28 die Buchstaben "Ä", "Ö" und "Ü" genommen werden.

Wird auch gemacht. Eine Variante ist, das Leerzeichen aufzunehmen, d.h. also ein 27er-System. Nur dann treten Wörter noch seltener auf.

Tranx hat folgendes geschrieben :

Ich nehme mal an, dass die Verteilung der "Buchstaben" annähernd gleichverteilt ist, was ja der "normalen" Verteilung in einem Text widerspricht. "E" ist in vielen Texten sehr viel häufiger als z.B. "L" oder gar "Q", "X".

Das ist ein wichtiger Grund, weshalb normale Wörter eben nicht so schnell auftreten. Eigentlich müsste z.B. ein E 18mal häufiger als ein Z auftreten, usw.
Aber wie soll man das umsetzen?

Beste Grüße
Mathematiker

Oha, schon wieder so ein Performance-Wettbewerb über ein total sinnloses Problem. Und das ausgerechnet jetzt, wo ich eigentlich ganz was anderes arbeiten müsste.

ich kann leider nicht widerstehen, daher anbei mein Programm, das noch relativ spartanisch ist. Aber es kann die Dezimalversion von PI in Basis 26 umrechnen. Es erzeugt immer 7 (basis26) Ziffern auf einmal und speichert 9 Dezimalziffern in einem Arrayelement.

Das Programm macht viel gebraucht von 64bit Zwischensummen, daher ist eine 64bit CPU im Vorteil: Die 32bit Ausführung benötigt ca. 40% mehr Zeit.
Auf meinem Rechner ist die 32bit Variante etwas schneller wie Revision 6, die 64bit Variante braucht nur ca. die halbe Zeit.

Im Anhang ist die AnyCPU Binary, d.h. es läuft auf beiden Betriebssystemen und jeweils in der "höchstbittigen" Variante. Mit dabei sind 10M Stellen von Pi.

Weitere Optimierungsfelder:
- Ich glaube da kann man noch ne Menge mit Parallelisierung machen. Das ganze ist eigentlich gut trennbar ... mal gucken.
- Wenn die Zahl PI nicht als Dezimal sondern als Binärbruch gespeichert wird, sollte das ganze nochmal schneller werden. Weil dann kann ein zeitaufwändiger Schritt (berechnen des Übertrags und der neuen ziffer) statt als Division einfach als bitweiser shift ausgeführt werden.

Ach ja, und das hat jetzt ca. 5h Zeit gebraucht geklaut.

Hallo,

jfheins hat folgendes geschrieben :

Oha, schon wieder so ein Performance-Wettbewerb über ein total sinnloses Problem.

Ja, so ist das. Der Spruch ist zwar steinalt, aber er stimmt: "Ein Computer löst die Probleme, die wir ohne ihn nicht hätten."

jfheins hat folgendes geschrieben :

ich kann leider nicht widerstehen

Geht mir auch immer so. Sehe ich irgendwo so eine, wenn auch sinnfreie, Aufgabe, muss ich es versuchen. Sind wir süchtig?

jfheins hat folgendes geschrieben :

Das Programm macht viel gebraucht von 64bit Zwischensummen, daher ist eine 64bit CPU im Vorteil: Die 32bit Ausführung benötigt ca. 40% mehr Zeit. Auf meinem Rechner ist die 32bit Variante etwas schneller wie Revision 6, die 64bit Variante braucht nur ca. die halbe Zeit.

Auf meinem alten Rechner läuft Deine Lösung ein klein wenig schneller als Revision 6. Die 64bit-Variante kann ich erst am Dienstag testen. Ich bin schon sehr gespannt.

Bei der Suche nach einem noch schnelleren Programm zur PI-Berechnung als "pifast", bin ich auf "qpi" von Steve Pagliarulo gestoßen. members.shaw.ca/francislyster/pi/pi.html
Das ist superschnell!

In der Revision 7 habe ich noch die Umwandlung in PI-Code 27 ergänzt, d.h. 0=Leerzeichen, 1..27=A..Z.

Beste Grüße
Mathematiker