Rechenprogramm

[Corpsman]

hier kannst den Screeny sehen,

warum google bei mir was anderes gerechnet hat, kann ich nu leider auch nicht mehr nachvollziehen.

Jup es mus auch beides mal das Gleiche rauskommen, Pyton sagt das auch.

EVTL sollte man da anzeigen das zwischenergebnisse einen Überlauf erzeugten ..

[himitsu]

Zitat von krassonkel:

Edit: Aber Wolfram|Alpha tut es und kommt auf 21!

ist dir aufgefallen, daß Wolfram es falsch parst?

[Corpsman]

es wird immer obskurer

(35 * ( 21 ^ ( 47 - 1 - 16 ) ) ) mod 47 = 9.4447E+0021

und das das Falsch ist sieht man sofort, wo doch nur eine Zahl im Bereich [0..46 ] rauskommen darf ...

[kroimon]

Zitat von himitsu:

ist dir aufgefallen, daß Wolfram es falsch parst?

Die Darstellung ist falsch, das Parsing richtig, das Ergebnis stimmt.
Mit einem Klick auf "Mathematica form" bekommt man es auch richtig geparst angezeigt (siehe Screenshot).


Edit:

Zitat von Corpsman:

es wird immer obskurer
(35 * ( 21 ^ ( 47 - 1 - 16 ) ) ) mod 47 = 9.4447E+0021
und das das Falsch ist sieht man sofort, wo doch nur eine Zahl im Bereich [0..46 ] rauskommen darf ...

Und rauskommen sollte 26...
Auch hier ist 21^30 definitiv zu groß

[Corpsman]

Mir scheint das der Rechner die Teilergebnisse schon rausbringt,

nur der Mod operator hat eine extrem kleine obergrenze ...

[himitsu]

zum Glück hat meine neue Lib kein Überlaufproblem ... sie kennt nur OutOfMemory und zu lange Berechnungszeiten

[add]
also der Mathematica-Plaintext von 21^(47-1-16) ist für mich sehr verwirrend 21^47 - 1 - 16

wie kommt man denn bitte auf solche Namen?
4 duodecillion, 640 undecillion, 650 decillion, 289 nonillion, 117 octillion, 164 septillion, 100 sextillion, 520 quintillion, 51 quadrillion, 333 trillion, 566 billion, 36 million, 654 thousand and 601

und nein, es ist mehr eine rethorische Frage, obwohl ich grad in Wiki etwas durchdreh, da ich da keine einheitlichen Namen vorfinde, um eventuell selber soeine Konvertierung von Zahlen vorzunehmen[/add]




Nja, hier sollte mindestens eine Fehlerbehandlung für Überläufe eingebaut werden.

[Amateurprofi]

Zitat von Corpsman:

Dein Parser Rechnet Falsch :(

(((5^16) mod 47)^9) mod 47 = 21
(((5^9) mod 47)^16) mod 47 = 0

behauptet dein Parser,

Laut Google ist das aber = 34, beides mal ...

Hallo Corpsman,
ich war im Urlaub, dahei eine verspätete Antwort:

beide von dir genannten Rechnungen sollten 21 ergeben.
Daß mein Parser für die zweite Rechnung 0 als Resultat nennt, liegt, wie von krassonkel schon vermutet, an den hohen Zwischenergebnissen.
Der Parser arbeitet intern mit Extended-Zahlen und 40^16 / 47 läßt sich damit nicht exakt darstellen.

Aber : Warum verwendest du nicht die Funktion ExpMod ?

expmod(expmod(5,16,47),9,47) ergibt 21
expmod(expmod(5,9,47),16,47) ergibt 21

Ich hab übrigens das gesamte Innenleben des Parsers überarbeitet - er ist jetzt etwa 25 % schneller.
Außerdem möchte ich den Teil des Programmes der für die Auswertung von Ausdrücken zuständig ist, in Form von .dcu Dateien zur Verfügung stellen. Die können dann in eigene Programme eingebunden werden.
Aber ich werde noch einige Zeit brauchen um Fehler zu finden und zu beseitigen.

[Amateurprofi]

Zitat von Corpsman:

Mir scheint das der Rechner die Teilergebnisse schon rausbringt,

nur der Mod operator hat eine extrem kleine obergrenze ...

Das hängt davon ab, was du unter "extrem klein" verstehst.

Ich zum Beispiel bin 184 cm groß und empfinde mich nicht als exterm klein.

Die von dir gezeigte Teilrechnung (35 * ( 21 ^ ( 47 - 1 - 16 ) ) ) ergibt
162422760119100743518201796674811282911232
und ist ca. 883 Sextillionen mal so groß wie ich - und das empfindest du als "extrem klein" ?

Aber trotzdem danke für die Beispiele.
Sie zeigen, daß ich noch viel mehr Prüfungen einbauen muß, ob die eingegebenen Zahlen exakt verarbeitet werden können und daß es Fehlermeldungen hageln muß, wenn das nicht der Fall ist.

[kroimon]

Zitat von Amateurprofi:

Aber trotzdem danke für die Beispiele.
Sie zeigen, daß ich noch viel mehr Prüfungen einbauen muß, ob die eingegebenen Zahlen exakt verarbeitet werden können und daß es Fehlermeldungen hageln muß, wenn das nicht der Fall ist.

Oder du arbeitest, wie andere Libraries auch, mit unbegrenzten BigNumbers, die lediglich durch die Größe des RAM beschränkt werden

[Amateurprofi]

Zitat von "krassonkel:

Oder du arbeitest, wie andere Libraries auch, mit unbegrenzten BigNumbers, die lediglich durch die Größe des RAM beschränkt werden ;-)

Nein, das ist für dieses Programm keine Alternative. Dafür hab ich andere Programme, die mit (in der Theorie) unbegrenzt langen Realzahlen arbeiten.
Vielleicht ist es noch nicht bemerkt worden: Dieses Programm wertet nicht nur einen einzigen Ausdruck dann aus, wenn der Anwender nach Eingabe des Ausdruckes die Entertaste drückt, sondern alle Ausdrücke im Eingabefeld immer dann, wenn irgendeine Veränderung im Eingabefeld stattfindet.
Natürlich soll der Anwender auch dann flüssig tippen können wenn viele Ausdrücke auszuwerten sind.
Und genau diese (für mich) wichtige Eigenschaft ginge verloren, wenn ich mit solchen Zahlen arbeiten würde.
Das Problem ist bei diesen Zahlen weniger das Rechnen, sondern die Ausgabe der Ergebnisse; ich glaube himitsu hat damit schon seine Erfahrungen gemacht.