mod mit extended

[choose]

Hallo Hagen,

wenn ich Dich richtig verstanden habe, möchtest Du für für den Restklassenopratoren mod und a,b e R und m e N folgendes definieren:

Code:

a = b  mod m

mit zB

Code:

a := (Trunc(b) mod m) + Frac(b)

sehe ich das richtig?
Ist m dabei zwingend eine natürliche Zahl oder siehst Du eine Möglichkeit, nicht-abzählbar viele Restklassen mit m e R zu erzeugen?

[alcaeus]

Du kannst aus der Gleitkommazahl zwar noch den Rest berechnen, aber im Grunde haben Gleitkommazahlen keinen Rest, denn alles, was nicht durch eine Ganzzahldivision gelöst werden kann, wird als fraktionaler Teil dargestellt. Man kann den Rest der Ganzzahldivision aber wieder berechnen, jedoch nur ungenau:

Delphi-Quellcode:

a := b mod c;
Rest := Frac(a)*c;

oder auch so (dieser Weg ist genauer)

Delphi-Quellcode:

a := b mod c;
Rest := a - Trunc(a)*cö

Greetz
alcaeus

[negaH]

Grundsätzlich gilt zu jedem Zahlensystem, das wenn die Division klar definiert ist diese Divison auch die Restklassen erzeugt. Egal also ob man Ganzzahlen, Fließkommazahlen oder Komplexezahlen usw. benutzt.

Das Manko ist nicht die Mathematik sondern die Rechentechnik die eben bei Fließkommazahlen "Verluste" erzeugt, sprich immer jede Operation rundet. Mathematisch kann man auch bei Divisionen mit gebrochenen Zahlen eine Modulo Operation durchführen. Dazu ist die Anwendung des GCD = Größten gemeinsammen Vielfaches notwendig.
Man kann also mit x'beliebigen Fließkommazahlen bei deren Division auch den Rest berechnen, nur eben mit dem Problem das die einzelnen Operationen auf Grund der Rechentechnik ungenaue Resultate liefern. Dies lässt sich aber kompensieren indem man die darzustellenden Zahlen in Matrizen umwandelt bei denen dann jedes Element IMMER innerhalb der exakt darstellbaren Grenzen des Zahlensystemes liegt. D.h. man zerlegt die großen Zahlen in deren Exponentielle Teile wobei jeder Einzelteil so klein gewählt wird das er immer exakt berechenbar ist. Nun, wird jede Operation auf dieser Darstellung der Zahl durchgeführt. Dabei kann man nun absolt exakte Berechnungen in jedem Zahlensystem zur jeder x'beliebigen Zahlendarstellung durchführen, die dann auch exakte Resultate liefert. Lange Rede kurzer Sinn: exakt so gehen math. Bibliotheken, wie obengenannte BigNum, BigFlots, LargeInteger usw. vor. Wenn man sich Zb. die 32 Bit Rechentechnik anschaut so wird man feststellen das die Hauptaufgabe der CPU darin besteht die Rechenoperationen auf 32 Bitzahlen so zu zerlegen das diese in der CPU in "Einzelschritten" auf Bits arbeitet. Ein 32Bit Integer wird also intern ebenfalls in 32 einzelne Bits zerlegt und immer nur 2 Bits werden addiert/subtrahiert usw. Auch hier wird also mit der Exponentiellen Zerlegung von 32 Bit Zahlen zur Basis 2 in einzelne Bits gearbeitet. Ob diese Einzelbits nun Ganzzahlige oder gebrochene Zahlen oder Fließkommazahlen darstellen ist für die Mathematik uninteressant, so lange man mit jeder Einzeloperation niemals die Fehlertoleranzen überschreitet.

Nun, bei einer normalen Division interessiert nur der Quotient, der bei Fließkommaoperationen annähernd exakt ist. Der modulare Rest dagegen ist nur auf Ganzzahlebene interessant (meistens zumindest) und dann wird er auch ganz exakt benötigt. Für solche Ansprüche sind die Fließkommazahlen, bzw. alle Rechenoperationen die implizit runden und Informationen "abschneiden" uninteressant.

Zb. eine RSA Schlüsselberechnung ist in Fließkommaarithmetik absolut untauglich. Alexander: es wäre also interessant zu wissen in welchem mathematischem Zusammenhang die Frage gestellt wurde, um sie korrekt beantworten zu können.

Gruß Hagen

[Alexander Roth]

Hallo alle zusammen,

tut mir leid, dass ich erst so spät antworten kann (war krank und ans Bett gefesselt), ich wollte es für riesige Primzahlen benutzen. Mir war zwar klar dass es verdammt lange dauern würde eine so große Primzahl zu berechnen, doch ich wusste nicht,

Zitat:

Bei Gleitkommazahlen (ich denk du willst hier auf Extended hinaus) hast du auch "nur" 19-20 signifikante Stellen (entspricht 64bit).

dass Extended auch nur so wenige Stellen speichert. Damit erübrigt sich meine Frage, denn dann ist int64 anscheinend das größte was der Comp zu bieten hat.

Danke für eure Mühe!!!


Klaine Frage am Rande: Weis jemand wie groß ein Array von int64 sein kann??? Meldet bei mir nämich einen Fehler bei so ungefähr 10 Millionen Plätzen im Array.

[tommie-lie]

Also selbst bei 100.000.000 Einträgen geht's bei mir noch (wenn auch mit intensiver Benutzung des Pagings ). Das gesamte Array muss aber in RAM oder Auslagerungsdatei passen, wo soll er sonst die Daten unterbringen?

[Alexander Roth]

Ja kann auch eine Millarde gewesen sein, aber dann ist bei mir zappeduster. Da bringt er irgend so einen gemeinen Fehler. Wollte nur wissen ob das normal ist.

[Nikolas]

Zitat von Hagen:

GCD = Größten gemeinsammen Vielfaches

Müsste das nicht Größter gemeinsamer Teiler (Greatest common Divisor) heissen ?

[tommie-lie]

Zitat von Alexander Roth:

Wollte nur wissen ob das normal ist.

Bei einem so großen Array: Ja.
Du musst dir das mal vor Augen führen: Ein Element ist 8 Byte groß. Jetzt hast du eine Milliarde Einträge, das sind 8 Milliarden Byte, etwas weniger als 8GB. Na, wieviel RAM hat deine Workstation inklusive Pagefile zur Verfügug?

[Chewie]

Zitat von tommie-lie:

Na, wieviel RAM hat deine Workstation inklusive Pagefile zur Verfügug?

Selbst wenn dein Pagefile auf 100 GB eingestellt sein würde, müsste der Speichermanager eines 32Bit-Betriebssystems die Speicheranforderung irgendwann verweigern, da er nicht mehr als 4 GB adressieren kann.

[tommie-lie]

stimmt, daran habe ich (diesmal) nichtmal gedacht. Die maximale Größe für ein Array of Int64 ist also schon von der Architektur her auf 536 870 912 begrenzt, wobei das auch widerum nicht stimmt, da einige Teile des Adressbereichs bereits vergeben sind.