Könnte es wohl möglich sein, irgendwie die Zahl 9^9^9 zu berechnen. Ich weiß, das ist eine verdammt große Zahl und das lässt sich nicht so einfach in Excel lösen, müsste deswegen programmiert werden. Kann man das vielleicht in Assembler machen?
Der wohl einfachste Weg: Start->Programme->Zubehör->Rechner: Ergebnis: 1,9662705047555291361807590852691e+77
Ja, aber das ...e+77 bedeutet doch, dass die Zahl 10^77 weitere Stellen hat, oder nicht? Und kann man das GENAU berechnen also bis auf die letzte Stelle?
@Roland Schmidt Wie hast Du das berechnet? Welches Programm? Das Ergebnis müsste wirklich viel, viel mehr Stellen haben.
So eine Zahl kann man nicht brauchen. Die Frage ist nur, wie kann man sie genau berechnen?
Hab schnell n C Programm geschrieben:
1 | #include <stdio.h> |
2 | |
3 | int main(int argc, char *argv[]) |
4 | {
|
5 | printf("%d\n", 9^9^9); |
6 | return 0; |
7 | }
|
Ausprobiert hab ichs nicht, aber das Dingens müsste 9 ausgeben, seh ich schon vom Schiff aus. Also nix mit 10 hoch 77 stellen :D
Hi Rolands Ergebnis sieht gar nicht mal so schlecht aus. Der TI 92plus spuckt bei mir das selbe aus. Man darf nur nicht 9^9^9 eintippen sondern muss das ganze auf 2 mal machen. mfg Schoasch
Dann geht wohl Dein Programm net ;-) Also 9^9 = 387420489 Dann ist 9^9^9 das selbe wie 9^387420489 und das ist sehr groß!
Ohne Klammern ist der Ausdruck aber nicht definiert. Denn die Potenzfunktion ist nich assoziativ, i.A. gilt: a^(b^c)!=(a^b)^c Wenn du solche Zahlen genau berechnen willst dann nimm am besten ein CAS (Computer Algebra System) wie Maple, Mathcad, Mathematica oder so. Auch mit Matlab kannst du das berechnen. Wenn du so etwas in einem Programm benötigst würde ich fertige Libraries wie zB die GNU multiple Precision Library verwenden, dann ist das ganze nämlich auch schon schön optimiert. Aber in Assembler würd ich sowas eher nicht versuchen ausser du benötigst das gut opimiert auch einem µC.
Nein, das ist nicht egal. (9^9)^9 = 196627050475552913618075908526912116283103450944214766927315415537966391 196809 9^(9^9) ist hingegen deutlich größer. Das exakt auszurechnen dürfte schwierig werden. Der Zehner-Logarithmus von 9^(9^9) ist etwa 3.6969309963157034*10^8, also hat diese Zahl fast 370 Millionen Stellen.
Mich hat einfach nur interessiert, ob die Zahl generell zu berechnen ist und ob so etwas auf einem schnellen Rechner (A64 3800 Dual Core) überhaupt in diesem Leben möglich ist und wie man das am besten anstellen könnte. Ich denke ein uC ist wohl dazu zu langsam.
Ricardo S. wrote: > @Bartli > > Und schon ein Ergebnis mit Deinem tollen C Programm? Oh. Das C Programm ist korrekt und da kommt 9 raus. Aber in C bedeutet ^ auch 'Exusiv Oder' und nicht Exponentation. > Ja, aber das ...e+77 bedeutet doch, dass die Zahl 10^77 weitere Stellen > hat, oder nicht? Nein. Es bedeutet das die Zahl 77 Stellen hat. Genauso wie 2E3 ( = 2000 ) aus 4 (1 + 3) Stellen besteht.
Es ist eine einfache Fleisaufgabe bei der Dir der Computer nur begrenzt weiterhelfen kann, wenn Du ihn wie einen Computer nutzt und ihm die Zahl als Zahl zu fressen gibst. Einfacher und recht schnell kommst Du aber zu Deinem Ergebnis, wenn Du dem Computer beibiegst, dass Ergebnis als Zeichenkette zu behandeln. Dann ist es nur noch eine kleine Fleissaufgabe, die Zahl so zu berechnen, wie Du es mal in der 4. oder 5.Klasse gelernt hast. Je nach persönlcher Fähigkeit, kannst Du dann einfach 387420489 mal mit 9 multiplizieren, oder 129140163 mal mit 729 ... was dann aber den Nachteil hat, dass sich über die Länge Dein Übertrag schnell über den Geltungsbereich Deiner Int hinaussummiert. Bei der Multiplikation mit 9 kann er nicht mehr 19, also 1 werden.
387420489 Multiplikationen mit 9 sollte ein Superduperdoppelvierfachpentibumm ja wohl in unter einer Stunde schaffen.
a^(b^c)!=(a^b)^c Ok, gibt also zwei Ergebnisse. Eines kurz mit 77 Stellen und das andere lang mit 370 Mio. Stellen. Wäre es nun möglich die lange Zahl mit einem modernen Rechner bis auf die letzte Stelle auszurechnen?
9*9=81
81*9
1*9 = 9
8*9 = 72
_________
729
729*9
9*9 = 81
2*9 = 18
7*9 = 63
_________1_
6561
Ricardo S. wrote: > a^(b^c)!=(a^b)^c > > Ok, gibt also zwei Ergebnisse. Eines kurz mit 77 Stellen und das andere > lang mit 370 Mio. Stellen. > > Wäre es nun möglich die lange Zahl mit einem modernen Rechner bis auf > die letzte Stelle auszurechnen? Ja wäre es. Wenn wir mal davon ausgehen, dass der Rechner eine Multiplikation pro Sekunde schafft (immerhin sind das ja riesige Zahlen), dann dauert es etwas über 12 Jahre bis er 387420489 mal mit 9 multiplizert hat. Aber ich denke schon, dass mehr als 1 Multiplikation pro Sekunde drinnen ist.
> Wäre es nun möglich die lange Zahl mit einem modernen Rechner bis auf > die letzte Stelle auszurechnen? Problemlos. Sind ja im Prinzip nur 370 Millionen Multiplikationen. Prinzipiell sollte das also in 370 Millionen Takten machbar sein, das dauert auf den schnellsten Pentium 4 gerade mal eine Zehntelsekunde. Ok, die Sache hat einen kleinen und einen grossen Haken. Der kleine: Da kommt noch ziemlich Overhead dazu, weil ja auch umkopiert werden muss. Verschlimmert die Laufzeit aber wohl nur um einen linearen Faktor. Der grosse: So eine Zahl passt in keinen Datentyp mehr rein, sondern muss irgendwie anders codiert werden. Natürlich kann der Computer damit dann nur noch sehr langsam Rechnen, weil er keine Maschinenbefehle dafür hat. Wenn man die Zahl als BCD speichert, so braucht man rund 190 Megabytes. Pro Multiplikation mit 9 muss diese ganze Zahl einmal mit 9 multipliziert werden sowie die Überträge addiert. Gibt also bei einem gleichmässigen Wachstum der Zahl zuerst 1 Multiplikation und schlussendlich 370 Millionen. Und das alles 370 Millionen mal...
>Sind ja im Prinzip nur 370 Millionen Multiplikationen.
Dröhnkram. Wer seinen Grips einschaltet kommt schnell darauf, dass 36
Multiplikationen ausreichen.
Das Programm:
(1) Lade x mit dem Wert 9.
(2) Führe 18 mal die Anweisung "x = x x x" aus.
(3) Gib x aus.
Warum x bei Schritt (3) den Wert 9^(9^9) hat, möge sich der geneigte
Leser bitte selbst klarmachen.
9^9^9 = 9^(9*9) = 9^81 Ist nicht dein ernst, oder? 9^9 != 9*9 9^9 = 9*9*9*9*9*9*9*9*9 = 387420489
> > Wäre es nun möglich die lange Zahl mit einem modernen Rechner bis auf > die letzte Stelle auszurechnen? möglich ist mit den heutigen rechnern wohl noch vieles, ist nur die Frage wieviel sinn ,dass das hier macht!! und falls Ihr es noch nicht bemerkt habt, genau für dieses Problem hat man die Exponentialschreibweise erfunden!
katzeklo wrote: >>9^9^9 = 9^(9*9) = 9^81 > >>Ist nicht dein ernst, oder? > > Das ist völlig korrekt: > 9^9^9 =(9^9)^9 =81^9 9^9^9 != 9^(9^9)= 9^81 oder nicht?
> (9^9)^9 = 9^(9*9)
Das glaub ich nicht.
Einer der mehr von Mathe versteht als ich, mein TI-92,
liefert bei 9^9^9 als Ergebnis ein freundliches Unendlich(*),
während er bei 9^(9*9) eine Zahl ausspuckt
(*) OK. das das nicht Unendlich sein kann ist mir schon
klar. Aber ich werte das mal als 'Zahl, größer als dass ich
sie darstellen könnte'. Auf jeden Fall sind beide Ergebnisse
nicht identisch. Und das war ja die Behauptung.
Logarithmieren wir doch mal um die Zahlen kleiner zu kriegen.
(9^9)^9 = 9^(9*9)
9 ln( 9^9 ) = 81 ln( 9 )
9 ln( 9^9 ) = 162 ln(3) = 177.975
81 ln( 9 ) = 177.975
Also doch.
Ich nehm alles zurück
Fall 1) 9^9^9 -Annahme-> (9^9)^9 -> 196627050475552913618075908526912116283103450944214766927315415537966391 196809 Fall 2) 9^9^9 -Annahme-> 9^(9^9) = 9^387420489 -> gigantisch groß! Florian, Deine URL entspricht Fall 1, demnach hat der Fragensteller für die "nichtgrafische" Darstellung der Aufgabe die Klammern vergessen - da er ja das gigantische Ergebnis möchte... Gruß 8^8^8 ;-)
>Einer der mehr von Mathe versteht als ich, mein TI-92, >liefert bei 9^9^9 als Ergebnis ein freundliches Unendlich Wie geil, was kostet (bzw. hat gekostet) der TI-92 nochmal? Mein 5 Euro Billigrechner liefert ein völlig korrektes Ergebnis. Diese Mathe lernt man glaube ich in der 8., oder? Sind einfachste Potenzesetze, was gibt es denn da zu diskutieren?
Jupp wrote: >>Einer der mehr von Mathe versteht als ich, mein TI-92, >>liefert bei 9^9^9 als Ergebnis ein freundliches Unendlich > > Wie geil, was kostet (bzw. hat gekostet) der TI-92 nochmal? Kann ich nicht sagen. Hab den geerbt :-) Zu seiner Ehrenrettung: Er rechnet 9^9^9 anscheinend als 9^(9^9) und nicht als (9^9)^9 Ich dürfte mich also beim Eintippen verhaut haben :-) (Bäääääh, ich will meinen HP41 wiederhaben) mea culpa
9^9^9 = 9^(9^9) = 9^387420489
Das könnte man eigentlich ganz einfach programmieren. Nur dumm, dass da
offenbar ein "Overflow" produziert wird.
#include <stdio.h>
#include <math.h>
int main(int argc, char* argv[])
{
long double resultat;
resultat=pow(9.0,387420489.0);
printf("%lG",resultat);
getchar();
return 0;
}
>9^9^9 = 9^(9^9) = 9^387420489
Könntest du bitte mal das erste Gleichheitszeichen entfernen? Die ist
hier unzulässig...
3^3^3 = (3^3)^3 = (27)^3 = (3*3*3)*(3*3*3)*(3*3*3) (9mal "3x") (mit 27 = 3*3*3 & diese Klammer können hier weg) oder 3^3^3 = 3^(3^3) = 3^27 = 3*3*3*3*3*3*3.... (27mal: "3x") Das Gleichheitszeichen ist halt nicht immer richtig! Und was ist bei 2^2^2 ;-)
> Und was ist bei 2^2^2 ;-)
Ist doch Wurscht...es ging um 9^9^9 und um nichts anderes.
Wahrscheinlich kommt jetz 2^2^2 = 9^9^9.
> 9^(9^9) = 9^387420489 >Das könnte man eigentlich ganz einfach programmieren. Nur dumm, dass da >offenbar ein "Overflow" produziert wird. Wenn Du vorher den ungefähren Wert von 9^(9^9) ausgerechnet hättest, wäre Dir klar geworden, warum man da mit naiver Programmierung nicht weit kommt. Es gilt: 9 ^ n = 10 ^ (log(9^n)) = 10 ^ (n log(9)) = 10 ^ (n * 0.95424250943932487459) Mit n = 9^9 = 387420489 folgt daraus: 9^(9^9) = 10 ^ (387420489 * 0.95424250943932487459) = 10 ^ 369693099.63157 = 10^0.63157 * 10^369693099 = 4.281 * 10^369693099 -------------------- Ergebnis: 9^(9^9) ist eine 369693099-stellige Dezimalzahl. Der maximale Wert, den eine vorzeichenlose 32-Bit-Integer-Zahl annehmen kann, ist dagegen mit 2^32 -1 = 4294967295 gerade mal eine 10-stellige Dezimalzahl. Mit Floats im "Double-Format" kann man bis ca. 10^308 rechnen, also mit höchstens 308-stelligen Dezimalzahlen. Auch das reicht jedoch für 9^(9^9) bei weitem nicht aus - man bräuchte "ungefähr eine Million mal leistungsfähigere" Floats.
> Weil 9^9^9 eben nicht 9^(9^9) ist. http://de.wikipedia.org/wiki/Tetration http://de.wikipedia.org/wiki/Potenzturm
Jupp wrote: > Eben, 9^9^9 ist nicht 9^(9^9). In der Wikipedia aber anders dargestellt: http://de.wikipedia.org/wiki/Grahams_Zahl "Der klammerfrei notierte Ausdruck m^m^...m^m ist deshalb mehrdeutig; in diesem Fall ist er - wie unter Mathematikern bei Weglassen der Klammern als Konvention üblich - von rechts nach links abzuarbeiten, d. h. beispielsweise ist m^m^m=m^(m^m) zu lesen. Diese Abarbeitungsreihenfolge ist auch gerade diejenige, bei der die größten Endergebnisse hervorgebracht werden."
Float im double Format kann vielleicht mit Zahlen bis etwa 10^300 rechnen, aber deswegen ist es leider noch nicht auf 300 Stellen genau und das muss es aber sein um das Ergebnis (ein 300 stelliges) exakt berechnen zu können. Also mit nativen Datentypen geht sowas mal sicher nicht, denn mit einem 64 Bit Datentyp kann man maximal auf 19 Stellen genau rechnen. Man beötigt also spezielle Libs wie zB GNU Multiple Precision Arithmetic Library dazu.
>Float im double Format kann vielleicht mit Zahlen bis etwa 10^300 >rechnen, aber deswegen ist es leider noch nicht auf 300 Stellen genau >und das muss es aber sein um das Ergebnis (ein 300 stelliges) exakt >berechnen zu können. Absolut richtig. Diesen Zusatz hätte ich eigentlich nicht vergessen dürfen. >Also mit nativen Datentypen geht sowas mal sicher nicht, Nein. >Man beötigt also spezielle Libs wie zB GNU Multiple Precision Arithmetic >Library dazu. Not at all. Es reicht aus, wenn Du folgende beiden Operationen beherrschst: (1) Eine beliebig große Dezimalzahl (z. B. "874853045898028309283748273008417857456736047856") zu einer anderen zu addieren: "x = x + y". (2) Eine beliebig große Dezimalzahl zu halbieren (!): "x = x DIV 2". Das "halbieren" mag überraschen, aber man benötigt es - ebenso wie die Addition - zur Implementierung der Multiplikationsroutine gemäß dem Algorithmus der schnellen ägyptischen Multiplikation. Das Verdoppeln einer beliebig großen Dezimalzahl, das man darin außerdem noch durchführen muss, ist mit (1) schon erledigt, denn das Doppelte von x kann man ja durch "x + x" erhalten. Aus programmiertechnischer Sicht ist sowohl (1) als auch (2) keine sehr anspruchsvolle Sache. Bei (1) muss man die Stellen der Zahl von "rechts nach links" abklappern, bei (2) von links nach rechts. Bei der Behandlung jeder Stelle entsteht ein Übertrag, der man bei der nachfolgenden Stelle korrekt verrechnen muss. Das ist im Wesentlichen schon alles. Als Datentyp zur Speicherung der Dezimalzahlen könnte man einfach ein Byte-Array nehmen (jedes Byte kodiert eine Dezimalstelle). Das Ergebnis würde in dem Fall mit 370 MByte allerdings schon relativ viel RAM belegen.
>wie kann man sie genau berechnen?
mit Papier und Bleistift und Hirnschmalz, ist zwar alt und dauert etwas
länger, funktioniert aber hervorragend. ;-)
2^2^2 = (2^2)^2 = 4^2 = 16 2^2^2 = 2^(2^2) = 2^4 = 16 Das ist ein spez.-Fall, der sich anders verhält als das 3-er Beispiel. (Int, ggf. für das binäre Zahlensys.) Und wie ist es bei 1^1^1 :-) (ist auch nur eine ernstgemeinte Anm.) Ich dachte, dass das 3^3^3 schon eindeutig ist - wegen der Disk. über das "=". Die obigen Hinweise auf Wiki. und folgendes waren offensichtl. hilfreicher.
Schon klar das man es mit diesen Methoden realisieren kann, aber auch nichts anderes machen die angesprochenen Libs. Schließlich können die die Bitbreite des Prozessors auch nicht erhöhen. Ich meinte also eigentlich eher das die in den gängigen Programmiersprachen bereitgestellten Methoden für so etwas nicht geeignet sind und man noch ganz schön viel Gehirnschamlz investieren muss um solche optimierte mathematische Methoden zu erstellen.
Ein pow(pow(9,9),9) sollte eigentlich noch jeder hinbekommen, oder? Und die ganz harten dürfen auch mal pow(9,pow(9,9)) austesten. Dauert mir im Moment aber etwas zu lange ;) pow(9,100000) dauert schon einige Sekunden und spuckt das aus: ...Mist zu lang zum posten... dann als Anhang... Gängige Programmiersprache mit eingebauter Unterstützung für lange Integer.
> pow(9,100000) dauert schon einige Sekunden und spuckt das aus: ...Mist > zu lang zum posten... dann als Anhang... > Gängige Programmiersprache mit eingebauter Unterstützung für lange > Integer. Mit ein bisschen Mathematik wird die Berechnung von 9^(9^9) um etliche Größenordnungen einfacher, wie AVRFan schon viel weiter oben festgestellt hat.
@ Mathematiker: ich freue mich schon, wenn du uns das resultat präsentierst ;) ...ist nicht so einfach, wie es scheint; selbst mit math. vereinfachungen
Es wird, so wie es AVR Fan beschrieben hat vielleicht etwas einfacher. Aber dieser Trick bringt nur so lange etwas, so lange die Länge des Ergebnisses unterhalb der Bitbreite der CPU ist. Denn wenn sie darüber ist muss man für eine Multilplikation auch wieder mehrere CPU Multiplikationen ausführen. Und über 19 Stellen (64Bit) ist man doch recht schnell. Und weil zuvor geschrieben wurde dass man das so einfach in einer Porgrammiersprache lösen kann, weil 9^100000 auch nur einige Sekunden dauert, dann sollte man nicht vergessen das die Rechenzeiten exponentiel steigt. Über 100000 ist dann also recht schnell Schluss.
ok, ich habe jetzt schnell ein progrämmchen geschrieben: der rechenaufwand steigt sehr(!) schnell. meine alte kiste (AMD 2500+ @ 2950+ und 32Bit) braucht für folgende bechenungen so lange: 9^100'000 19sec 9^250'000 1min 52sec ok, bei 64bit wäre mind. 4x schneller wäre und etwas optimierung würde sicherlich auch noch was bringen...
>ok, ich habe jetzt schnell ein progrämmchen geschrieben: der >rechenaufwand steigt sehr(!) schnell. meine alte kiste (AMD 2500+ @ >2950+ und 32Bit) braucht für folgende bechenungen so lange: > >9^100'000 >19sec > >9^250'000 >1min 52sec Wunderbar, die von mir gemessenen Zeiten sind damit praktisch identisch. :-) Dass der Rechenaufwand sehr schnell steigt, ist ja das Problem an der Sache. Deshalb darf man aus "9^100000 dauert ein paar Sekunden" keinesfalls den Schluss "9^(9^9)" ist locker in einer Stunde erledigt" ziehen! Die entsprechende sehr richtige Bemerkung von Thomas sollte man dreimal dick rot unterstreichen. >ok, bei 64bit wäre mind. 4x schneller wäre und etwas optimierung würde >sicherlich auch noch was bringen... Bei 64 Bit würde sich blos die Anzahl der Speicherzugriffe verringern, aber zu rechnen hätte die Kiste immer noch genausoviel. Der Gewinn würde nicht wirklich ins Gewicht fallen. Wenn man 9^(9^9) nach diesem Schema (1) Lade x mit dem Wert 9. (2) Führe 18 mal die Anweisung "x = x x x" aus. (3) Gib x aus. berechnen würde, würden dabei genau 18 "Zwischenwerte" anfallen - nach jeder Iteration einer. Diese Zwischenwerte sind: Iteration 1: 9^3 = 7.29000000000000E+0000 * 10^2 Iteration 2: 9^9 = 3.87420489000000E+0000 * 10^8 Iteration 3: 9^27 = 5.81497370030400E+0000 * 10^25 Iteration 4: 9^81 = 1.96627050475552E+0000 * 10^77 Iteration 5: 9^243 = 7.60203375682963E+0000 * 10^231 Iteration 6: 9^729 = 4.39328503696454E+0000 * 10^695 Iteration 7: 9^2187 = 8.47945898417348E+0000 * 10^2086 Iteration 8: 9^6561 = 6.09683485452607E+0000 * 10^6260 Iteration 9: 9^19683 = 2.26627858111106E+0000 * 10^18782 Iteration 10: 9^59049 = 1.16396489616914E+0000 * 10^56347 Iteration 11: 9^177147 = 1.57695626218303E+0000 * 10^169041 Iteration 12: 9^531441 = 3.92156072351406E+0000 * 10^507123 Iteration 13: 9^1594323 = 6.03082647549096E+0000 * 10^1521370 Iteration 14: 9^4782969 = 2.19346393535189E+0000 * 10^4564112 Iteration 15: 9^14348907 = 1.05533780150190E+0000 * 10^13692337 Iteration 16: 9^43046721 = 1.17536968074619E+0000 * 10^41077011 Iteration 17: 9^129140163 = 1.62376602823123E+0000 * 10^123231033 Iteration 18: 9^387420489 = 4.28124767611117E+0000 * 10^369693099 Füttere mal Dein Programm mit den Exponenten aus den Iterationen 9, 10, 11 und 12, also mit 19683, 59049, 177147 und 531441. Dann kannst Du verfolgen, wie die Rechenzeiten anwachsen. Du wirst feststellen, dass sie sich mit jeder Iteration ungefähr VERNEUNFACHEN. Damit liegt tatsächlich ein exponentielles Wachtum (von einer Iteration zur nächsten) vor. Mein Rechner ist mit 9^531441 (Iterationsstufe 12) nach 10 Minuten fertig. Damit fehlen bis zur Stufe 18 noch genau 6 Iterationsstufen. Das bedeutet aber nichts anderes, als dass man für die Zeit zur Berechnung von 9^(9^9) ganz grob 9^6 * 10 Minuten erwarten kann. Das sind 5.3 Millionen Minuten oder >>> 10 Jahre <<<. Fazit: Die Berechnung von 9^(9^9) durch "naives" 387420489-maliges Multiplizieren von 9 mit sich selbst mit einem zeitgemäßen PC ist möglich, aber man braucht Geduld dafür lach.
Weil es da offensichtlich noch gewaltige Meinungsverschiedenheiten gibt: Die Potenzoperation ist rechtsassoziativ, d. h.
Diese Konvention ist deswegen sinnvoll, da eine linksassoziative Potenzierung als einfache Potenz mit einem Produkt im Exponenten geschrieben werden kann und normalerweise auch wird:
Man hat also für beide Fälle eine Schreibweise, die ohne Klammern auskommt. Dies kann bspw. auch hier nachgelesen werden: http://en.wikipedia.org/wiki/Associative#More_examples > Einer der mehr von Mathe versteht als ich, mein TI-92, liefert bei > 9^9^9 als Ergebnis ein freundliches Unendlich(*), Das stimmt zwar nicht (weil bei den meisten Taschenrechnern der Wertebereich bei knapp unter 1e100 aufhört), aber der Rechner hat zumindest den richtigen Ansatz gewählt. > Mein 5 Euro Billigrechner liefert ein völlig korrektes Ergebnis. Ich wage zu bezweifeln, dass dein Rechner neunstellige Exponenten anzeigen kann. Mein Taschenrechner liefert 1.966270505e77, was natürlich falsch ist. Aber er ist von Aldi und hat sogar nur 3,48 Euro gekostet. Nachdem mein Taschenrechner also nichts taugt, habe ich meinen PC mit dem Term gefüttert. Nach 0,153 Sekunden lieferte er folgendes Ergebnis:
1 | 42812477317574704803698711593056352133905548224144 |
2 | 35141747537230535238874717350483531936652994320333 |
3 | 75060417533647631000780326139047338608320802060374 |
4 | 70612809165574132086446019861999614520310524428581 |
5 | 48959811514719493517677965593021593933850150239694 |
6 | 26231052967581656943333463147492553849485933778120 |
7 | 87624957216504195220601804571301517864051014594079 |
8 | 04194866332733667183065441076023482363342793388473 |
9 | 44917149071392838763670347073322161584263884702644 |
10 | 65058580355824823115778277866180114720994362906904 |
11 | 73438366488664695023381735331493288811517612485971 |
12 | 20153357564439876059956217339548503950536965544532 |
13 | 95547762183338179903753742986603617541076696090471 |
14 | 83399239331453425470226983330651282587035207362363 |
15 | 43330809161939992399143539951742626261922504449148 |
16 | 89355346296338764247108036190948328339353383268116 |
17 | 81684096752173716022712403864241094486312416733616 |
18 | 31602584738577273169933875567294188775379238762791 |
19 | 51815197169574861839692092170993607802644764408395 |
20 | 92643445485180078094839593328539827016475025109537 |
21 | ... |
22 | 369691100 Ziffern weggelassen |
23 | ... |
24 | 16437894757477844731142780767037267003263590250822 |
25 | 34292387746462391127975152902898840592704628596911 |
26 | 90014188420320154332647563918577185976492049122303 |
27 | 23811027210136918368494328574137376263796912584561 |
28 | 41237444060102002608592235410622770718702230402359 |
29 | 35641915129699628666846006630298351379027215796574 |
30 | 56534443278490334199454357557541697596627896410612 |
31 | 70387990256128353667950589936117172490285814571733 |
32 | 91518760228328138355866578899535027225395434516598 |
33 | 39173364275071543317493863779576502233071689586371 |
34 | 97192110578737857336943212457715521275513998317785 |
35 | 47671678591299645067296274837365302215234320507478 |
36 | 34092790565371273832640535909769963513435977537992 |
37 | 83680752817548382724478144536940979972304718417625 |
38 | 89447951540180726242836597614291883489679188153772 |
39 | 85476781074966161266185476266685323552900557188849 |
40 | 16798855470068473582685089739187008510754028188539 |
41 | 25349052912288203971972403223578700607328387735828 |
42 | 26170043150602250406601961656994397543610268552663 |
43 | 74036682906190174923494324178799359681422627177289 |
Noch Fragen? :-)
Ja, ich: Wie haben das nur die ganzen Genies damals gemacht? Euler, Gauss, Fibonacci, Kepler, Pascal..... ;-)
> Könnte bitte der Themen Titel geändert werden in: >9^(9^9) Jetz kann ich doch nicht widerstehen ... : Hier ein exaktes Ergebnis und eine Abschätzung unter Anwendung purer Potenzrechenregeln und ohne Logarithmus (also Mathe 9./10. KLasse ..) Zunächst den Exponenten berechnen: 9^9 = (3^2)^9= 3^(2*9) = 3^18 für den Expononenten. Eingesetzen und gleicher "Trick" für die Basis 9: 9^(9^9) = 9^(3^18) = (3^2)^(3^18)=3^(2*3^18)=3^774840978 (das letzte liefert mein alter Casio fx85 für 2*3^18 = 774840978) EXAKTE LÖSUNG: 3^774640978 ABSCHÄTZUNG (sehr grob)mit 2^x, da gilt: 1. 2^x < 3^x und 2. 2^10 = 1024 circa 1000, also 2^10 ca. 10^3 Dann gilt: 2^774840978 = 2^(10*77484097,8) = (2^10)^77484097,8 ca.(10^3)77484097,8 Ca. 10^232452293,4 Also ist 9^(9^9) > 10^232452293 !!! Da TR und PC üblicherweise nur bis 10^99 können (manchmal 10^300), ist klar, dass eine exakte Berechnung besondere Methoden und VIEL ZEIT erfordert ... Wer will, kann jetzt mal die Zeit mit den Werten von Mr.Snowman überschlagen ... MfG
>habe ich meinen PC mit dem Term gefüttert. Toll. >Noch Fragen? :-) Ja: Welcher Algorithmus ist in Deinem Programm am Werk? Für die Ziffernfolge selbst interessiert sich kein Mensch. aufDeineAntwortgespanntbin
@yalu, Dein Rechner schiebt 370MB in 0,1xxx Sekunden durch den Speicher? -> alle Achtung ;-)
Mathematische Ergänzung und Stoff zum Nachdenken über Rechenbedarf: 9^(9^9)=3^774840978 a) wird zur Ermittlung der dezimalen Stellenzahl auf die Basis 10 umgeschrieben mit der Beziehung 10^c=3, wobei c=lg3, das ergibt 3^774840978 = 10 ^ 369 693 099,6 b) wird zur Ermittlung der Registerbreite im Binärsystem auf die Basis 2 umgeschrieben, da 2^cx =3 mit c=ld3 (dyadischer Log.) ergibt sich 3^774840978 = 2^ 1 228 093 894, also 1 228 093 894 Bits. Die Registerbreite beträgt also 153 511 737 Byte. Um eine exakte Berechnung durchzuführen (darum ging es Ricardo ja, mit der Klarstellung der Reihenfolge), werden also mehr als 150MB für die Darstellung des Ergebnisses benötigt. Kleiner Überschlag der Bildschirmausgaben unter der Annahme 80 Zahlen pro Zeile und 50 Zeilen pro Bildschirm ergibt mehr als 92423 Bildschirme voll ... Den Rest überlasse ich wieder den Programmieren (falls Ihr noch Lust habt nach diesen Zahlen ...) MfG
@Yalu: Herlichen Glückwunsch! Dein Ergebnis ist in der Stellenzahl exakt so, wie ich es (ohne Ausführung einer konkreten Rechnung) ermittelt habe. Habe eben erst gelesen, was Du geschrieben hast. Jetzt bin ich aber auch neugierig, wie Dein Programm die Rechnung mit der Stellenzahl gelöst hat (immerhin im Speicher mehr als 150MB breit, oder denke ich da falsch?
@AVRFan: @Netbird: Danke für das Interesse :) @muckel: > @yalu, Dein Rechner schiebt 370MB in 0,1xxx Sekunden durch den > Speicher? -> alle Achtung ;-) Habe einfach einen Tiny11, für den ich sonst keine Verwendung mehr hatte, per Cobalt-60-Bestrahlung zum Quantencomputer umfunktioniert ;-) Nein, natürlich nicht. Ich hatte geschrieben > Nach 0,153 Sekunden lieferte er folgendes Ergebnis: Das stimmt exakt so, d. h. er hat jeweils die 1000 ersten und letzten Ziffern des Ergebnisses berechnet, mehr nicht. Das Programm mit ein paar erläuternden Kommentaren hängt an. Das Programm ist in Python und schlampig programmiert, also a****lahm. Um alle 369693100 Ziffern zu berechnen, bräuchte es auf meinem 3,2-GHz-Pentium hochgerechnet über 100 Jahre, da die Rechenzeit quadratisch mit der gewünschten Ziffernzahl wächst.
<< Wie haben das nur die ganzen Genies damals gemacht? >> Ich habe mal gehört, dass die Aufgaben in kleine Häppchen geteilt an Hausfrauen zum rechnen weiter gegeben wurden, weil die die Zeit und Geduld mitbrachten solche sinnlosen Zahlenkolonnen zu Fuss auszurechnen.
@yalu: Alles klar, danke. Zitat aus dem Quelltext Deines Programms: >Die Berechnung der letzten nziff Ziffern erfolgt in Modulo-10**nziff- >Arithmetik [...] Das also ist des Pudels Kern... und Du schämst Dich gar nicht für so einen faulen Zauber? lach
>Um alle 369693100 Ziffern zu berechnen
Du hast recht, das verdammte Ding hat 369693100 Ziffern, nicht
369693099.
10^3 = 1000 hat ja auch vier Ziffern, nicht drei.
Mein Fehler urgs.
@yalu und alle anderen Interessenten ... Vielen Dank, das Knobeln und die Auflösung am Schluss hat richtig Freude gemacht. Da musste programmmäßig ja getrickst worden sein, sonst wäre die schöne Logik defekt gewesen ... Übrigens: Alle, die so etwas für sinnlos halten, haben auf eine (aber auch nur eine Art) Recht, das Ergebnis ist zu nichts nütze. Hier ist -wie oft bei mathematischen Problemen- der Weg das Ziel. Gruß, Netbird
> Das also ist des Pudels Kern... und Du schämst Dich gar nicht für so > einen faulen Zauber? *lach* Ok, es geht auch ohne faulen Zauber, wenn man etwas fremde Hilfe in Anspruch nimmt. Folgendes C-Programm braucht zwar 135 Sekunden, berechnet dafür aber die komplette Zahl:
1 | #include <stdio.h> |
2 | #include <gmp.h> |
3 | |
4 | int main(void) { |
5 | mpz_t a, b; |
6 | int i; |
7 | |
8 | mpz_init(a); |
9 | mpz_init(b); |
10 | mpz_set_ui(a, 9); |
11 | |
12 | for(i=0; i<18; i++) { |
13 | mpz_mul(b, a, a); // b = a * a |
14 | mpz_mul(a, b, a); // a = b * a |
15 | }
|
16 | // gmp_printf("%Zd\n", a);
|
17 | return 0; |
18 | }
|
Die fremde Hilfe kommt in Form der GMP-Bibliothek daher. http://gmplib.org Was die Jungs dort an Registern ziehen, nur um zwei Zahlen zu multiplizieren, ist unglaublich. Da gibt es nicht weniger als 4 Multiplikationsalgorithmen, die je nach Größe der Operanden - teilweise auch kombiniert - eigesetzt werden. Bei besonders großen Zahlen wird sogar der scheinbar riesige Umweg über Fouriertrans- formationen gegangen, um am Ende doch schneller zum Ziel zu gelangen. Was allerdings mehr Zeit kostet als die eigentliche Berechnung ist die Umrechnung nach dezimal, was in der auskommentierten zweitletzten Programmzeile passiert. Aktiviert man diese, braucht das Programm fast eine Stunde. Aber immer noch schneller als 10 oder gar 100 Jahre :-) Ich habe übrigens das Ergebnis in eine Datei umgeleitet und die ersten und letzten 1000 Ziffern mit den Ergebnissen aus meinem letzten Beitrag verglichen. Sie stimmen tatsächlich überein.
Huch, jetzt habe ich doch glatt vergessen, das Ergebnis zu posten :D Hier kommt's: ... Dateianhang ... Browse ... Nee, lieber doch nicht ... Cancel. Andreas wird es mir sicherlich danken, wenn ich seinen Server nicht mit solchem Unfug zumülle. (Mal ganz abgesehen von den Stunden, während derer mein Upstream blockiert wäre)
Habs jetzt auch mal selber mit der GMP Lib ausprobiert und finde es interessant, dass die Implementierung mit der for Schleife um einiges langsamer ist, als wenn man die Potenzfunkionen der Lib benützt. Ausführungszeit mit der Potenzfunktion:
1 | mpz_set_ui(a,9); |
2 | z = pow(9,9); |
3 | mpz_pow_ui(b, a, z); |
real 1m30.608s user 1m25.261s sys 0m1.780s und mit der for schleife:
1 | for(i=0; i<18; i++) { |
2 | mpz_mul(b, a, a); // b = a * a |
3 | mpz_mul(a, b, a); // a = b * a |
4 | }
|
real 2m30.549s user 2m14.096s sys 0m2.960s
>Was die Jungs dort an Registern ziehen, nur um zwei Zahlen zu >multiplizieren, ist unglaublich. Unglaublich? Glaub ich! :wird sogar der scheinbar riesige Umweg über Fouriertrans- :formationen gegangen, um am Ende doch schneller zum Ziel zu gelangen. OK, das liegt dann schon weit jenseits der Feld-Wald-Und-Wiesen-Mathe. >Was allerdings mehr Zeit kostet als die eigentliche Berechnung ist die >Umrechnung nach dezimal, Holla :-) Gibts in der Lib vielleicht auch eine Funktion, mit der man riesige Zahlen vom Neunersystem ins Dezimalsystem umrechnen kann? Wenn ja, wäre die 18-malige Kubizierung oder andere Multiplizierereien nämlich obsolet, denn um die Ziffernfolge von 9^(9^9) im Neunersystem zu bekommen, muss man ja überhaupt nichts rechnen: 10000000000000000000000000000............0000000000000000000000000000 mit genau 1000000000 Nullen hinter der "1" ("1000000000" im Neunersystem!). >fast eine Stunde. Aber immer noch schneller als 10 oder gar 100 Jahre :-) Eine Stunde... wow... damit kann man doch leben. > [...] 1000 Ziffern mit den Ergebnissen aus meinem letzten >Beitrag verglichen. Sie stimmen tatsächlich überein. So solls sein. "Gruß zurück" (lach) PS: Wie groß ist eigentlich 9^(9^(9^9))? ;-)
> Habs jetzt auch mal selber mit der GMP Lib ausprobiert und finde es > interessant, dass die Implementierung mit der for Schleife um > einiges langsamer ist, als wenn man die Potenzfunkionen der Lib > benützt. Finde ich auch interessant. Hab's aber nicht ausprobiert, da die dort eingesetzte Power-Funktion so funktioniert: "Normal mpz or mpf powering uses a simple binary algorithm, successively squaring and then multiplying by the base when a 1 bit is seen in the exponent, ..." Das bedeutet (wenn ich richtig gerechnet habe) 41 Multiplikationen, also deutlich mehr als die 18 von AVRFan. Es könnte natürlich seini, dass die 41 Multiplikationen "leichter" sind und deshalb schneller ausgeführt werden. Die Rechenzeit wird maßgeblich durch die größte durchzuführende Multiplikation bestimmt. Dies ist bei dem Verfahren von AVRFan die letzte mit den Operanden
x ist dabei das Gesamtergebnis. Bei der GMP ist es die zweitletzte (die letzte ist eine Multiplikation mit 9 und dürfte relativ schnell gehen). Beide Operanden haben dabei den Wert
Möglicherweise geht diese Multiplikation schneller. Aber wie geschrieben, Ich habe diesbezüglich nichts ausprobiert. > Gibts in der Lib vielleicht auch eine Funktion, mit der man riesige > Zahlen vom Neunersystem ins Dezimalsystem umrechnen kann? Soweit ich gesehen habe, gibt es die nicht, zumindest nicht direkt. Man kann natürlich mit mpz_init_set_str(mpz_t ergebnis, "1000000...000000", 9); Die Zahl vom Neunersystem in die interne Binärdarstellung umwandeln und diese dann mit mpz_printf wieder ausgeben. Es würde mich allerdings wundern, wenn das schneller ginge. Ok, ich war schon zweimal verwundert, so dass mich das vielleicht doch nicht wundern würde :-) Aber vielleicht sollte man die Zahl eh besser im Neunersystem stehen lassen. Irgendwie kann man sie sich dann besser merken. > PS: Wie groß ist eigentlich 9^(9^(9^9))? ;-) Hmm, diese Zahl ist wohl noch etwas größer und sprengt höchstwahrscheinlich die 512-MB-Grenze meines Rechner :( Nur so viel kann ich jetzt schon sagen: Sie endet mit der Ziffer 9.
> "Normal mpz or mpf powering uses a simple binary algorithm, > successively squaring and then multiplying by the base when a 1 bit > is seen in the exponent, ..." Ja, so werden Ganzzahl-Potenzierungen üblicherweise durchgeführt. >Möglicherweise geht diese Multiplikation schneller. Aber wie >geschrieben, Ich habe diesbezüglich nichts ausprobiert. Wer weiß... Anyway können wir das 9^(9^9)-Problem mittlerweile als gelöst betrachten, denke ich. >Ok, ich war schon zweimal verwundert, so dass mich das vielleicht doch >nicht wundern würde :-) lach Einen Versuch wärs vielleicht noch wert, just for fun. >Aber vielleicht sollte man die Zahl eh besser im Neunersystem stehen >lassen. Irgendwie kann man sie sich dann besser merken. Scherzkeks :-) >Hmm, diese Zahl [ 9^(9^(9^9)) ] ist wohl noch etwas größer und sprengt >höchstwahrscheinlich die 512-MB-Grenze meines Rechner :( Selbst wenn Du sämtliche Materie im Weltall nehmen und sie zu einem Computer verbauen könntest - keine Chance. Für 9^(9^(9^9)) müssen ja grob 10^370000000 Bytes irgendwo abgespeichert und dann auch noch verrechnet werden. Unter der Annahme, dass jedes Atom im Universum (von Kosmologen geschätzte Anzahl: 10^79) stolze 100 GByte (= 10^11 Byte) Daten speichern könnte, ergäbe das eine Gesamt-Kapazität von 10^90 Byte. Eine Milliarde Universen zusammengenommen brächten es auf 10^99 Byte. Das ist gemessen an 10^370000000 ein Witz. Tatsächlich liegt schon die Größe der in dieser Notation so unschuldig aussehenden Zahl 9^(9^9) jenseits jeder Vorstellungskraft, und über 9^(9^(9^9)) sollte man wohl besser gar nicht erst nachdenken. >Nur so viel kann ich jetzt schon sagen: Sie endet mit der Ziffer 9. :-) Nachtrag: Wer sich mit 7^(7^7) zufriedengibt, hat es leicht. Diese Zahl hat "nur" 695975 Dezimalstellen, und die komplette Berechnung mit der naiven Methode (7^7 mal "*7", Zehn-Zeilen-Routine) dauerte auf meinem Durchschnitts-PC keine halbe Stunde. Es ist schon verblüffend.
Beitrag #6855788 wurde von einem Moderator gelöscht.
Beitrag #6855798 wurde von einem Moderator gelöscht.
Beitrag #6855820 wurde vom Autor gelöscht.
Ich muss den Thread mal hervorholen. Python macht das im Bruchteil einer (1) Sekunde
1 | >>> a=9**9 |
2 | >>> a=a**9 |
3 | >>> a |
4 | 196627050475552913618075908526912116283103450944214766927315415537966391196809 |
5 | >>> |
. Selbst weitere Potenzen "mit links"
1 | >>> a=9**9 |
2 | >>> a=a**9 |
3 | >>> a |
4 | 196627050475552913618075908526912116283103450944214766927315415537966391196809 |
5 | >>> a=a**9 |
6 | >>> a |
7 | 439328503696464329829774782657072712058010308177126710621676697750466344744764029773301412612482563729435064854354299095570379503452515853238520182740967398746503532324400000659505126023955913142968176998364877699089666171297275956245407453033190168644894850576346492691458695174281789557994923607783461486426448617667076393901104477324982631297641034277093818692823488603426279473674368943609268871793467206677285688478458498235002859256706389043030847945506577080623430066283504397583789044245429585982964571774605868466160379567432725704121260940939343217905975847365096315872153240969882363435363449775254393010368267343970426230801390250903399147001650831878665172798468587509747439118815689 |
8 | >>> a=a**9 |
9 | >>> a |
10 | 609683485452741112075235500724516670453115716895320025142055544060992206118345733195670930601391416031419347837381484188382881951433379123359313314933244210601512487020777732791222771893404859051590828696103799967120373592507057411946836370842145917500334762398351641542409564168524317143715760969367337242278252296192257755590138005663105597330353536830297965125372297102681424686850910639047766049279097023890339143848228023392943078063199836424226954041357578424782631862433423874215159238431543345109430718973560158757704908903172111956056366259712652853432607460910077283409427311989607857053110397329989034825569575562188685305447453330677591022902049353489382228107260629232409368999333685042946398487309186571606142468757152565434485212541721163897314567917523997823121395142317145049341594054811528070197536688303888476958771977502323653181348467752354680020863378480973818298508318268338696302019357148521532095273598636209307997253608343889856073384560577927572337867354822396908678510662371503925980869702639576971942702430789055678881944576812182580901378418898294860706790263994597430111831268711625556356745728755442130871232085685099470290641006222674784729223127188400448612887433108820629470380367355057572351376001828289026362967862424639273455806774138381983139391719563215770240694287203849677560831055766278286055921130338563008375210500966795010401951960267177086738862889331978106287759384737660872735552451751086042784918872934904760782042675129004924276356715421301922392188236481891996346794784316632052651079636553853158992053677395693092569827914929328904654596217077817628463493264816138623805861253498858607687798134962850649623019007141709446429416140168901951026952245323112428680444922280963531416429758022613714116143602824821189791450690561785985328865796850032627017572718356490100095105676235076142976078079397192618073886364752590488211991362605688529536772962022417040606636121435964110777395524949160680134182225915191726034865406003390625199182193704990935060676374990819823281721349606987499507449954162729524128628164389806486941191778116951061002959779309792915802011047015297567696262070807902590624341424651267523754995634828034132969009161722806818947979129519104094176659792899101273912529107352000213040998391280254936459774378680076331527294505187943205606116442740735027269981199798634681059824749208723590031392046892644888565623488228129233828270657491063132675457565165860856375112698580144903082943537288750935180048935928242409821465559574928773585712997132459879081492505228338041747218371864192537854458115384458443284811117109223158217922975271342526900454021410737004974056813740347900173639584819288397003446440395559967822443984946809649260538989890854424983749760215218502405535051899734436256808729304654943315380632199248966175218154536579536483392432757168748519548575914463080864612941543657975520976698508121839730376700637312871357040723739391173247004119377996460400136958194519944877775553905441128766167615205833101791439083812012979266215373806281902732533005665368905557306549177307201247839098755527254576243815293172818701056068187094337000830025044568191819338246332521176984917533143001303544936037217109408608296056961292104677778033512569311185669611058156875751920862714153337048248861344354574341358632587875957691369942874935898638113322640421405566881801965340015901941334817653304156100386242603374489197264858144897492256153754185247688137724095468876305401685269185649055671895403415607192750118946813187627716825769308937935281809880349065098912099942537186223480096589842500124598628855341293980918670736710752753161316977986970230893132883568092722417036577397419329711576046702965060147303177816991840555167389850793397172373291960986137884498969842721115448203731755432055446123713854720966435544053834531814962725787835476454058961787095965238820001762972262348644726507372696136062630889846947967042157274998728255423717506038369054453802699448067181700320583324203971673532509015002200198546220101578637871060271773723985735326312490897528624974678487604360480338646780392785676973708354370116343339372958090155236556264989945152110748284990609230744137588556473478169632324717488899232327650262587730415443828624213119263203235451460137506301422623063069888778412569821819038214360262079585844815271405169278081934512541484799168796365504402617926643709383546636558547065128407589965221536380360737164365161493586151373734502449275476098556849692098238927272648082451753057111398571676688567362269137195467250570594417851428872922702596328004678205243912526004349040271237573969332446648270076706518450787059045724992001802132113820388790929299888571160776522939260299171326471468686458863225497475144416893501180850829978771146935472015137175966533057924747021216126848140769146794309982329972559295289075792967956351607513991727110220921498308244980078479795482015372569623224939778650251487071756534749451100348226056933967588391354541511849177686493559219699542125182527593907861122968626554629883926773846771539543101525574189543625600541697540076702940379874888947144612158982466646309842628547319739077865331476463453992805226514211097711176423255674183845477168040599465258972388573208431575083860615979810029275638989851003295044555549243113839462378873502369543130242015660020602787973598572467060957381241565941205456698910482067836113482102280524406646302743470112087427472514013105288633611502785188213067980467300746437302992567150102075686265552843685417392129983164451911558907471068830798391649115996205050608599640736308585851400373853700540360971706698324794296838560001790320259128642537657946233749749278942121508917513079964037379047390153778173542741898479242726687382246938596706657693174111627846656799557424571601651943183512955281868385914251451010073404817059514241233091408860258393083571386081348796186188323378867994721747659028673328480484459679631662895194137215637219320119109291791279254127828570290501391758311749047110360962043813923111344884366144770117586736537392472191116611664818657084338613647063339077288169097994438000017977949919329083260526096133403745058519219706445278520075152513671209817461154580997332471621813987611514972532379635692724472346821600549802125671248433668213379459545260244454772731023174256697609 |
11 | >>> |
Wie machen die das so schnell und so genau, kann mir das jemand erklären?
Schnell: durch geschickte Algorithmen (a^n kann man für gerades n in (a*a)^(n/2) aufsplitten - damit kann man n bitweise abarbeiten.) Genau: Ganzzahlarithmetik und GHz-Prozessortakt
Die richtige Antwort wurde schon vor 14 Jahren gegeben. Also kann das Skelett wieder in den Schrank. Beitrag "Re: 9^9^9"
nichtmathematiker schrieb: > n ist aber hier ungerade ... Da gibts einen einfachsten Trick: noch genau einmal mit a multiplizieren :)
nichtmathematiker schrieb: > Ich muss den Thread mal hervorholen. > > Python macht das im Bruchteil einer (1) Sekunde Mach das noch neunmal weiter, dann ist es kein Bruchteil einer Sekunde mehr... Du impliziert hier die falsche Klammerung. Grüße, Martin
Ich habs mal in Python eingegeben. Es rechnet immer noch. Wie lange sollte das ungefähr dauern?
Hier läuft 9^(9^9) mit Python3 seit >1 Tag auf einem EPYC der Serie 7002, die Berechnung a=9^(9^9) dauerte 35 Minuten, ABER: die Ausgabe print(a) läuft seit >21 Stunden und dauert immer noch an.
Stefan H. schrieb: > Ich habs mal in Python eingegeben. Es rechnet immer noch. Wie lange > sollte das ungefähr dauern? Wahrscheinlich soviele Jahre, wie zwischen 2007 und 2021 liegen. :-)
Ricardo S. schrieb: > Könnte es wohl möglich sein, irgendwie die Zahl 9^9^9 zu berechnen. Ich > weiß, das ist eine verdammt große Zahl und das lässt sich nicht so > einfach in Excel lösen, müsste deswegen programmiert werden. Kann man > das vielleicht in Assembler machen? 1. Die Frage selber verbessern, denn es gibt ein Darstellungsproblem (?) Hier hilft schon, wenn man die Zahlen zur Frage einfach nur auf ein Blatt Papier schreibt. Die daran anschließende Frage lautet: Wie stelle ich meine Frage richtig? bzw. wie kann ich meine Frage optimieren? 2. Was gibt es so generell? https://de.wikipedia.org/wiki/Sch%C3%B6nhage-Strassen-Algorithmus https://algo.rwth-aachen.de/~algorithmus/algo16.php Weitere Implementierungshilfe u.a. in bestimmten Hardwarebüchern, oder auf https://stackoverflow.com/ Ganz offenbar ist die Expertise für solche Art von Fragen in den 1960ern und 1970ern zuhause. 3.Jetzt kann man noch die Programmierung der Berechnung hinterfragen bzw. die Berechnung selber, und die Möglichkeiten auf der konkreten Hardware überlegen. 4. Die Zahlen rund um 9 mal x kann man auch noch mal in einer bestimmten Richtung maßschneidern wie z.B. (8 + 1) mal x. 9 selbst verhält sich in hexadezimaler Hinsicht ganz ähnlich wie 6 in dezimaler Hinsicht. 5. Punkt 3 und Punkt 4 interagieren jetzt ein wenig mit der Überlegung: Wie gut lassen sich Teilberechnungen parallelisieren? 6. wäre wohl eher so eine Tapetenfrage..war die Drucksituation in den 1970ger oder 1980ger Jahren besser?
bingo schrieb: > Hier läuft 9^(9^9) mit Python3 seit >1 Tag auf einem EPYC der Serie > 7002, > die Berechnung a=9^(9^9) dauerte 35 Minuten, > ABER: die Ausgabe print(a) läuft seit >21 Stunden und dauert immer noch > an. So, jetzt ist meine Berechnung von 9**(9**9) in Python fertig. Hier das Programm:
1 | #!/usr/bin/python3
|
2 | import time |
3 | |
4 | print(time.strftime('%a %d.%m.%Y %H:%M:%S')) |
5 | a=9 |
6 | b=a**a |
7 | b=a**b |
8 | print(time.strftime('%a %d.%m.%Y %H:%M:%S')) |
9 | werte=open('999.txt','w') |
10 | werte.write('%d' % b) |
11 | werte.close() |
12 | print(time.strftime('%a %d.%m.%Y %H:%M:%S')) |
und die Ausgabe der Zeiten
1 | Sat 23.10.2021 17:33:52 |
2 | Sat 23.10.2021 18:08:36 |
3 | Sat 13.11.2021 14:16:58 |
Das Ergebnis hat 369.693.100 Stellen. Interessant finde ich, dass die eigentliche Berechnung im Python-internen Zahlenformat nur 1/2 Stunde benötigt, die Umwandlung vom Python-internen Zahlenformat in das human-readable dezimale Format dagegen 3 Wochen.
hex-fan schrieb: > bingo schrieb: >> in das human-readable dezimale Format > > Auch hex ist human-readable. Naja, wenn man es so betrachtet, ist alles irgendwie human-readable.
bingo schrieb: > die Umwandlung vom Python-internen Zahlenformat in das human-readable > dezimale Format dagegen 3 Wochen. Du hast echt den PC bei Vollast diese Zeit durchlaufen lassen?
Die Ausgabe geht wesentlich schneller, wenn die Berechnung von vornherein im Dezimalsystem durchgeführt wird, da dann das Ergebnis nicht mehr lange konvertiert werden muss:
1 | #!/usr/bin/python3
|
2 | |
3 | from time import time |
4 | from decimal import * |
5 | |
6 | setcontext(Context(prec=MAX_PREC, Emax=MAX_EMAX)) |
7 | |
8 | a = Decimal(9) |
9 | |
10 | t0 = time() |
11 | b = a**a**a |
12 | print('Berechnen: %5.2f s' % (time() - t0)) |
13 | |
14 | t0 = time() |
15 | open('999.txt','w').write(str(b)) |
16 | print('Speichern: %5.2f s' % (time() - t0)) |
Ausgabe:
1 | Berechnen: 36.65 s |
2 | Speichern: 1.38 s |
Interessanterweise geht damit auch die eigentliche Berechnung schneller, so dass alles zusammen von 3 Wochen auf weniger als 40 Sekunden verkürzt wird. Manchmal ist das Dezimalsystem eben nicht nur für Menschen, sondern auch für Computer von Vorteil :)
Yalu X. schrieb:1 | b = a**a**a |
Kann zwar kein Python, aber vermutlich wird das von links nach rechts ausgewertet, also (a^a)^a = a^(a*a). Hier geht es aber um a^(a^a).
hex-fan schrieb: > Kann zwar kein Python, aber vermutlich wird das von links nach rechts > ausgewertet, also (a^a)^a = a^(a*a). Da das Ergebnis 369693100 Stellen hat, sind die Potenzen wohl richtig herum berechnet worden. (9**9)**9 hat nur 78 Stellen, und das Ergebnis steht praktisch sofort da, egal, ob binäre oder dezimal gerechnet wird.
Dann würde mich interessieren, warum es dezimal so viel schneller geht. Gibt es dafür eine Erklärung?
Weil 300 Millionen Divisionen auf einer Zahl mit 300 Millionen Stellen nun mal dauern. Bei einer Dezimalzahl kann die Ausgabe direkt erfolgen.
Yalu X. schrieb: > Interessanterweise geht damit auch die eigentliche Berechnung schneller, hex-fan schrieb: > Dann würde mich interessieren, warum es dezimal so viel schneller geht. Sorry, falsch verstanden. Offenbar geht die eigentliche Berechnung zwar schneller, aber nicht "so viel schneller". Die Frage nach dem warum ist dennoch berechtigt. Multiplikation mit 9 ist dezimal zwar nur ein Linksschift und eine Subtaktion, aber binär ist es auch nur drei Linksshifts und eine Addition. Sollte kein großer Unterschied sein.
hex-fan schrieb: > Offenbar geht die eigentliche Berechnung zwar schneller, aber nicht "so > viel schneller". Naja, von 35 Minuten auf 36 Sekunden ist mit einem Faktor von fast 60 nun durchaus ein recht erheblicher Unterschied. Klar, kein Vergleich zu der Ausgabe, aber trotzdem erstaunlich viel.
>Die Ausgabe geht wesentlich schneller, wenn die Berechnung von >vornherein im Dezimalsystem durchgeführt wird, Da der allererste Post sich über das Zahlensystem des Ergebnisses ausschweigt, kann man sich auch gleich für das Neunersystem entscheiden und es damit denkbar einfach haben: 10^(10^10) = eine "1" gefolgt von 10^10 = 1000000000 Nullen. (Alle Zahlen in Neunersystem-Darstellung!)
Rolf M. schrieb: > Klar, kein Vergleich zu der Ausgabe, aber trotzdem erstaunlich viel. Ja, den genauen Vergleich sehe ich erst jetzt. Umso berechtigter die Frage, wie das zustandekommt.
Potenzen werden von rechts berechnet. Beispiel: 2,3 x 10^3 = 2300, und ist nicht (2,3 x 10) ^ 3 = 12167
Es sollte eine Leseverpflichtung des ganzen Threads vor einer Postmöglichkeit geben, grrr
Rolf M. schrieb: > Naja, von 35 Minuten auf 36 Sekunden ist mit einem Faktor von fast 60 > nun durchaus ein recht erheblicher Unterschied. Bingo hat wohl einen schnelleren PC als ich. Bei mir dauert die Berechnung mit gewöhnlichem int 2807 Sekunden, d.h. dezimal ist sogar um den Faktor 77 schneller. hex-fan schrieb: > Dann würde mich interessieren, warum es dezimal so viel schneller geht. > Gibt es dafür eine Erklärung? Ja, die Erklärung ist sogar ganz einfach: Die Vorstände von Intel und AMD haben schon lange Wind davon bekommen, dass du beabsichtigst, das Dezimalsystem weltweit abzuschaffen und es durch das Hexadezimalsystem zu ersetzen mit der Begründung, dass alle Computer im Binärsystem rechnen, das viel leichter in hexadezimal als in dezimal konvertiert werden kann. Da die alten Herren befürchten, die Umgewöhnung nicht mehr zu schaffen, haben sie schon vor Jahren beschlossen, in ihren Firmen nur noch Prozessoren herzustellen, die im Dezimalsystem (genauer gesagt in BCD) rechnen. Auf diese Weise möchten sie erreichen, dass deine Argumentation für das Hexadezimalsystem ins Leere läuft. Scherz beiseite: Die dem decimal-Modul zugrunde liegende Bibliothek mpdecimal hat einen auf große Zahlen optimierten Multiplikationsalgorithmus, Python für die int-Multiplikation nicht.
:
Bearbeitet durch Moderator
Auf einem AMD A10-7700K dauert das 63s/8s. W10, keine SSD.
:
Bearbeitet durch User
bingo schrieb: > Potenzen werden von rechts berechnet. > > Beispiel: 2,3 x 10^3 = 2300, und ist nicht (2,3 x 10) ^ 3 = 12167 Da kommen aber keine zwei Potenzen vor, sondern eine Multiplikation und eine Potenz. Die Potenz bindet natürlich stärker als die Multiplikation.
also der Rechner von meinem iiiiphöns sagt 9^9^9 =4.28124773176 x 10^369693099 ht gefühlt 5ms gerechnet
:
Bearbeitet durch User
Weingut P. schrieb: > also der Rechner von meinem iiiiphöns sagt 9^9^9 > =4.28124773176 x 10^369693099 Da fehlen aber noch ein paar hundert Millionen Stellen.
Weingut P. schrieb: > also der Rechner von meinem iiiiphöns sagt 9^9^9 > =4.28124773176 x 10^369693099 > > ht gefühlt 5ms gerechnet Dein Iphone rechnet nicht richtig. Es rechnet 9^9^9 als (9^9)^9, das ist trivial und geht sauschnell. Richtig wäre 9^(9^9), denn Potenzen werden von rechts nach links gerechnet.
und wodurch ist es nun bestimmt, ob man (9^9)^9 also 387420489^9 oder 9^(9^9) also 9^387420489 rechnet?
●DesIntegrator ●. schrieb: > und wodurch ist es nun bestimmt, ob man Gar nicht... In dieser Notation ist das Problem nicht eindeutig.
●DesIntegrator ●. schrieb: > und wodurch ist es nun bestimmt, ob man > > (9^9)^9 > also > 387420489^9 > oder > > 9^(9^9) > also > 9^387420489 > > rechnet? Es ist die zweite Variante also a^b^c = a^(b^c) weil man (a^b)^c einfach schreiben kann als (a^b)^c = a^(b*c). Daher ist a^b^c = a^(b^c) die Konvention.
Johann L. schrieb: > Es ist die zweite Variante also a^b^c = a^(b^c) weil man (a^b)^c einfach > schreiben kann als (a^b)^c = a^(b*c). > > Daher ist a^b^c = a^(b^c) die Konvention. Hast du dafür eine Quelle? Der Ausdruck a - b - c wird imho immer von links nach rechts aufgelöst, also (a - b) - c; nicht als a - (b - c).
Mikro 7. schrieb: > Hast du dafür eine Quelle? https://www.gut-erklaert.de/mathematik/potenzregeln-potenzen-vereinfachen.html
Mikro 7. schrieb: > Hast du dafür eine Quelle? > > Der Ausdruck a - b - c wird imho immer von links nach rechts aufgelöst, > also (a - b) - c; nicht als a - (b - c). Das muss nicht unbedingt für alle Operatoren gleich sein. Deswegen geben Programmiersprachen für jeden Operator an, ob er links- oder rechts-assoziativ ist. Siehe https://de.wikipedia.org/wiki/Operatorassoziativit%C3%A4t Dort ist übrigens auch die Potenzierung unter den rechts-assoziativen Operatoren zu finden.
Lorenz schrieb: > Richtig wäre 9^(9^9), denn Potenzen werden von rechts nach links > gerechnet. Hab ich schon in der Schule gelernt.
Mikro 7. schrieb: > Johann L. schrieb: >> schreiben kann als (a^b)^c = a^(b*c). >> Daher ist a^b^c = a^(b^c) die Konvention. > Hast du dafür eine Quelle? genauso hat man es in der Schule gelernt und es leuchtet jeden wohl ein das 9^9^9 von rechts ausgewertet werden muss da 81^9 != 9^81 ist und das Assoziativgesetz https://de.wikipedia.org/wiki/Assoziativgesetz unter Beispiel für eine rechts-assoziative Operation: auch das so festlegt!
Rolf M. schrieb: > Weingut P. schrieb: >> also der Rechner von meinem iiiiphöns sagt 9^9^9 >> =4.28124773176 x 10^369693099 > > Da fehlen aber noch ein paar hundert Millionen Stellen. Lorenz schrieb: > Dein Iphone rechnet nicht richtig. > > Es rechnet 9^9^9 als (9^9)^9, das ist trivial und geht sauschnell. > Richtig wäre 9^(9^9), denn Potenzen werden von rechts nach links > gerechnet. Ich weiß zwar nicht, mit welcher App auf dem Iphone dies ausgerechnet wurde, aber "10^369693099" sind die ominösen 369693100 Stellen, die bei 9^(9⁹) berechnet werden würden. Es würde ja reichen, wenn der Taschenrechner intern mit z.B. 128 Bit rechnen würde, und hier z.B. 32 Bit für den Exponenten bereithalten würde, also (32*log 2)/log 10=9,6 (rund 10 Dezimalstellen für den Exponenten). Das würde zwar nur eine Näherung liefern, aber es wäre berechenbar. Allerdings hat auch das in der IEEE 754 definierte Format Quadruple (=128 Bit Float) nur einen 15 Bit Exponenten, würde also nicht reichen. Im Übrigen "kenne" ich es auch so, dass bei Potenzdarstellungen immer erst der Exponent evaluiert wird, also dass 9^9^9 = 9^(9^9) wäre.
Anmerkung: Evtl. arbeitet der ominöse Rechner auf dem iPhone mit der GNU MP Lib. Hier werden Gleitkommaexponenten mit mindestens einer Word Breite (i.A. 32 Bit, evtl. sogar 64 Bit) dargestellt.
Joachim B. schrieb: > 81^9 != 9^81 nun bin ich selber reingefallen! 81 = 9² und nicht 9^9.... OK war wohl noch müde
Johann L. schrieb: > Eine 81 kommt ins Spiel bei (9^9)^9 = 9^(9*9) = 9^81. Hier ist aber die Rede von 9^9 und nicht von 9*9
Ricardo S. schrieb: > Ja, aber das ...e+77 bedeutet doch, dass die Zahl 10^77 weitere Stellen > hat, oder nicht? Und kann man das GENAU berechnen also bis auf die > letzte Stelle? Bevor du dich an solche Zahlen machst, solltest du dich mit den Grundlagen vertraut machen. Was genau willst du von der Zahl wissen?
Karl II schrieb: > Johann L. schrieb: >> Eine 81 kommt ins Spiel bei (9^9)^9 = 9^(9*9) = 9^81. > > Hier ist aber die Rede von 9^9 und nicht von 9*9 Es geht darum, dass
das selbe ist wie
also wie
Rolf M. schrieb: > Es geht darum, dass an welcher Stelle wird 9^9 immer zu 9*9 oder 9^2, egal wo in 9^9^9 ?
:
Bearbeitet durch User
Angehängte Dateien:
-
81.png
18 KB
Joachim B. schrieb: > An welcher Stelle wird 9^9 immer zu 9*9 oder 9^2, egal wo > > in 9^9^9 ? Es ging bei den "81" um (9^9)^9, nicht um 9^9^9 = 9^(9^9) https://de.wikipedia.org/wiki/Potenz_(Mathematik)#Potenzgesetze
Und, Obacht! jetzt wird's kompliziert! Setze ein: a=9, r=9, s=9.
:
Bearbeitet durch User
Rolf M. schrieb: > Es geht darum, dass(99)9(9^{9})^{9} das selbe ist wie9(9⋅9)9^{(9\cdot9)} > also wie981 NEIN, 9^(9⁹) ist NICHT 9^(9*9), ersteres ist 9^387420489, letzteres ist 9^81
Lorenz schrieb: > NEIN, 9^(9⁹) ist NICHT 9^(9*9) Lies mein Posting nochmal. Dann wird dir vielleicht auffallen, dass ich das nie behauptet habe.
Εrnst B. schrieb: > Es ging bei den "81" um (9^9)^9, nicht um 9^9^9 = 9^(9^9) an keiner Stelle ist 81 richtig! weder bei (9^9)^9 = 387420489^9 noch bei 9^(9^9) = 9^387420489 nirgends eine 81 = 9² in Sicht!!!!
Joachim B. schrieb: > weder bei (9^9)^9 = 387420489^9 … was auch gleich 9^81 ist! Und da ist sie dann, die 81. Warum ist das so schwer zu verstehen?
Joachim B. schrieb: > nirgends eine 81 = 9² in Sicht! Wenn du schon grundlegenden Rechenregeln nicht glaubst, vielleicht können dich ein paar hingerotzte Zahlen überzeugen? 9⁸¹ = 196627050475552913618075908526912116283103450944214766927315415537966391 196809 387420489⁹ = 196627050475552913618075908526912116283103450944214766927315415537966391 196809 Bitte selber nachrechnen, und auch kontrollieren ob nicht doch irgendwo ein Zahlendreher drinnen ist.
2⁵ schrieb: > Ich weiß zwar nicht, mit welcher App auf dem Iphone dies ausgerechnet > wurde, aber "10^369693099" sind die ominösen 369693100 Stellen, die bei > 9^(9⁹) berechnet werden würden. Es würde ja reichen, wenn der > Taschenrechner intern mit z.B. 128 Bit rechnen würde, und hier z.B. 32 > Bit für den Exponenten bereithalten würde, also (32*log 2)/log 10=9,6 > (rund 10 Dezimalstellen für den Exponenten). Das würde zwar nur eine > Näherung liefern, aber es wäre berechenbar. Allerdings hat auch das in > der IEEE 754 definierte Format Quadruple (=128 Bit Float) nur einen 15 > Bit Exponenten, würde also nicht reichen. > > Im Übrigen "kenne" ich es auch so, dass bei Potenzdarstellungen immer > erst der Exponent evaluiert wird, also dass 9^9^9 = 9^(9^9) wäre. Die App heißt NCalc FX und ich verwendete die x^y-Funktion, die Darstellung im Display war exakt diese:
¯\_(ツ)_/¯
:
Bearbeitet durch User
mike schrieb: > 9^(9^9) ist hingegen deutlich größer. Das ist auch die einzig richtige Rechnung, denn man muss erst den Exponenten ausrechnen, bevor man ihn anwendet. Daher geht nur: 9 hoch (9 hoch 9). Rolf M. schrieb: > Joachim B. schrieb: >> weder bei (9^9)^9 = 387420489^9 > > … was auch gleich 9^81 ist! Und da ist sie dann, die 81. Warum ist das > so schwer zu verstehen? Ganz sicher nicht.
Info schrieb: > Rolf M. schrieb: >> Joachim B. schrieb: >>> weder bei (9^9)^9 = 387420489^9 >> >> … was auch gleich 9^81 ist! Und da ist sie dann, die 81. Warum ist das >> so schwer zu verstehen? > > Ganz sicher nicht. Ich kann mich nur wiederholen: >> Warum ist das so schwer zu verstehen? Die Potenzgesetze, zu denen auch dieses gehört, sollte eigentlich jeder in der Schule im Matheunterricht mal gelernt haben. Wenn man die nicht mehr so im Kopf hat, ist das ja ok, aber dann sollte man nicht rausposaunen, dass die "ganz sicher nicht" gelten. Der entsprechende Wikipedia-Link wurde auch schon mal in Beitrag "Re: 9^9^9" gepostet und erklärt.
Rolf M. schrieb: > Ich kann mich nur wiederholen: >>> Warum ist das so schwer zu verstehen? Weil es kompliziert ist. Und weil keiner in seinem Leben ausserhalb der Schule sowas braucht. Sowas erfinden gelangweilte Leute für gelangweilte Leute.
Beitrag #7001392 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
20220312_123423.jpg
130 KB
9^81 = 2E+85 Genauer muss man das gar nicht wissen. Wichtig ist nur, dass hinter der 2 noch 85 Stellen folgen.
Angehängte Dateien:
-
Potenzturm.jpg
36 KB
schon & schön erklärt in Beitrag "Re: 9^9^9" "Potenzturm" (https://de.wikipedia.org/wiki/Potenzturm)
:
Bearbeitet durch User
Angehängte Dateien:
-
Windows-Rechner-1.png
28 KB
Thomas S. schrieb: > schon & schön erklärt in > Beitrag "Re: 9^9^9" > "Potenzturm" (https://de.wikipedia.org/wiki/Potenzturm) Dann rechnet der Windows Rechner falsch (ohne Klammersetzung). 2^3^4 = 4096 :)
Matebook schrieb: > Dann rechnet der Windows Rechner falsch (ohne Klammersetzung). > > 2^3^4 = 4096 Der Windows Rechner ist in der Normaleinstellung noch nicht einmal in der Lage
1 | 2+3*4 |
zu rechnen.
Norbert schrieb: > Matebook schrieb: >> Dann rechnet der Windows Rechner falsch (ohne Klammersetzung). >> >> 2^3^4 = 4096 > > Der Windows Rechner ist in der Normaleinstellung noch nicht einmal in > der Lage2+3*4 > zu rechnen. Das war aber der wissenschaftliche Modus und da sollte er das eigentlich können.
Matebook schrieb: > Das war aber der wissenschaftliche Modus und da sollte er das eigentlich > können. Normalmodus: Grundrechenarten falsch. Wissenschaftlicher Modus: Exponentialfunktionen falsch. Fazit: Bei Microsoft muss man immer mit dem Schlimmsten rechnen. Dann ist man auf der sicheren Seite.
Angehängte Dateien:
-
234.png
150 KB
Matebook schrieb: > Dann rechnet der Windows Rechner falsch (ohne Klammersetzung). > > 2^3^4 = 4096 Richtig, ist ja auch Windows. Was hast Du erwartet? Anbei mal die Version von Ubuntu
Bartli schrieb: > Hab schnell n C Programm geschrieben: > #include <stdio.h> > int main(int argc, char *argv[]) > { > printf("%d\n", 9^9^9); > return 0; > } > > Ausprobiert hab ichs nicht, aber das Dingens müsste 9 ausgeben, seh ich > schon vom Schiff aus. Also nix mit 10 hoch 77 stellen :D Dazu brauche ich kein Programm. Das Ergbnis ist FF, FFFF, FFFFFFFF oder FFFFFFFFFFFFFFFF. Und immer falsch.
234 schrieb: > Richtig, ist ja auch Windows. Was hast Du erwartet? In diesen Tagen ist Hoffnung eine meiner obersten Lebensmaxime. ;-)
Matebook schrieb: > In diesen Tagen ist Hoffnung eine meiner obersten Lebensmaxime. In Beziehung zur Ukraine bin ich voll bei Dir.
och schrieb: > Bartli schrieb: >> Hab schnell n C Programm geschrieben: >> int main(int argc, char *argv[]) { >> printf("%d\n", 9^9^9); >> return 0; >> } >> Ausprobiert hab ichs nicht, aber das Dingens müsste 9 ausgeben, seh ich >> schon vom Schiff aus. Also nix mit 10 hoch 77 stellen :D > Dazu brauche ich kein Programm. Das Ergbnis ist FF, FFFF, FFFFFFFF oder > FFFFFFFFFFFFFFFF. Kannst du erklären wie du darauf kommst?
lol, wie einfach sich die Leute hier trollen lassen. @TO: sehr gut gemacht. 8 von 10 Trollpunkte. lg. Heiner
Heiner schrieb: > @TO: sehr gut gemacht. 8 von 10 Trollpunkte. Ob der das noch mitkriegt nach 15 Jahren ist fraglich. ;)
Beitrag #7200525 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.