Gauß-Verfahren - Matrix lösen

[Danny92]

Hallo.
Nachdem mein Algorithmus zur Erstellung einer Dreiecksmatrix endlich fertig ist, muss ich nun leider feststellen, dass dieser bei größeren Matrizen (>12 Unbekannte/Zeilen) schon einige Minuten in Anspruch nimmt. (Selbstverständlich nimmt der Rechenaufwand mit der dritten Potenz der Anzahl der Unbekannten zu)

Wer sich meinen Code im Anhang anschauen wird, wird feststellen, dass dies aufgrund der aufwändigen Umsetzung mit Stringrechnung nicht verwunderlich ist.
Allerdings bin ich auf den Datentyp string umgestiegen, da ich einen ganzzahligen Datentypen benötige, und der größte Ordinaldatentyp, den es in Delphi gibt, ist in erster Linie erst einmal nur Integer. Da dieser jedoch nur bis 2^31-1 (also nur ca. 2,1 Mrd.) reicht, ist man da im mathematischen Sinne sehr schnell an den informationstechnischen Grenzen angelangt. (Wie groß ist in der Mathematik schon eine Zahl mit nur 10 Dezimalstellen, im Vergleich zu einer mit z. B. 1000 Stellen?)

Gleitkommazahlen wie extended sind in der Hinsicht ein gutes Vorbild, jedoch für meine Zwecke nicht zu gebrauchen, da ich Operationen Div und Modulo (Divisison mit Rest) benötige, die mit Kommazahlen leider Gottes nicht funktionieren...Also habe ich meine eigenen Methoden (+, -, *, /) implementiert, die mit (unbegrenzten) Strings rechnen und das jeweilige Ergebnis als String wieder ausgeben können. (z. B. function APlusB(A, B: TPoint): TPoint; //TPoint als Bruch (X Zähler, Y Nenner zu verstehen)

Code:

type
  TPunkt = Packed Record //Bruch mit X als Zähler und Y als Nenner
X: String;
Y: String;
end;

function APlusB(A, B: TPunkt): TPunkt; //Addiere zwei Brüche
begin
 //und so weiter
end;

Lange Rede, kurzer Sinn:
Ist es möglich und wenn ja wie, den Code hinsichtlich der Effizienz und des Rechenaufwandes zu optimieren um bei großen Matrizen schneller ans Ziel zu kommen?
Es sollte doch möglich sein, bis zu 40x40 große Matrizen in einer passablen Laufzeit zu lösen.
Am einfachsten wäre es sicherlich, einfach auf extended umzusteigen, aber
1. können da durch die vielen Rechenschritte enorme Rundungsfehler auftreten (nur Brüche sind exakt und eindeutig, extended ist leider nicht beliebig genau) und
2. wird mir extended für z.B. Modulo und damit für die Bestimmung des ggT oder kgV nichts nützen.

Praktisch ist mein Taschenrechner bei der Lösung von Matrizen in die Dreiecksmatrix mittels Gauß mindestens 10x so schnell...aber dennoch exakt!
Ich möchte keine Kompromisse eingehen - schnell UND exakt.

Ist es vielleicht doch ohne viel Aufwand möglich, einen eigenen, viel größeren ganzzahligen Datentypen - in der Größenordnung wie extended - zu implementieren? Und wenn ja, wie? Dann könnte ich mir das ganze aufwändige Gedattel mit den Strings sparen, denn ich bin sicher da liegt die größte Bremse.:-D

Schon mal lieben Dank für die weisen Antworten :shock:

PS: Code und Programm im Anhang, bei diesem würde die Lösung einer 40x41 Ref Matrix mindestens unübertrieben Stunden dauern!!

[Dejan Vu]

Ich würde ein Datenformat wählen, welches Zahlen beliebiger Größe handhaben kann. Dann tauschst Du das aus und solltest zufrieden(er) sein.
Hier ist ein Datentyp für 512-bit Integer.
Und Hier sogar für beliebig große Zahlen (bis 2 Mio Stellen).

Ich fände es interessant, Deine Ergebnisse zu sehen.

Klar ist aber auch: Ein Algorithmus vom Aufwand O(n^3) wird bei großen n immer langsam.

[Bjoerk]

Ein Gauß 40 x 40 dürfte bei Floats so 1 sec. brauchen. Das Problem hier dürfte dein Zahlenformat sein. Wie wäre es hingegen, mit Floats zu arbeiten und zur Ausgabe sich eine FloatToFrac zu schreiben. Hier das wäre mal ein Anfang.

[Namenloser]

Es ist eigentlich üblich, bei der Lösung von Gleichungssystemen mit Gleitkommazahlen zu arbeiten. Es gibt bestimmte Verfahren, um Rundungsfehler zu minimieren (beispielsweise QR-Zerlegung). Weshalb brauchst du Ganzzahlen? Du hast es begründet mit GGT und KGV, aber ich finde das in deinem Code nur im Zusammenhang mit den Bruch-Berechnungen. Die bräuchtest du mit Gleitkommazahlen ja gar nicht mehr. Was soll am Ende wirklich berechnet werden?

[frankyboy1974]

Hallo,

ich würde das Problem auch in Abbildung des Gauß-Verfahrens sehen. Wenn ich dir jetzt als Beispiel das LGS 2,59X+ 7,657Y= 874584 und 4,55X + 18,456Y=44837 gebe, sucht du jetzt den kgVF von 2,59 und 4,55, nur um das LGS zu lösen?

mfg

frank

[Dejan Vu]

Zitat:

Zitat von Bjoerk (Beitrag 1313845)

Ein Gauß 40 x 40 dürfte bei Floats so 1 sec. brauchen.

Das wird sehr schnell ungenau, sofern man das klassische Eliminationsverfahren verwendet. Die LUP-Dekomposition (Cormen) ist hier besser, jedenfalls bei meinen Versuchen.

[frankyboy1974]

Hallo,

Zitat:

Die LUP-Dekomposition (Cormen) ist hier besser

Ja mag ja sein(ich habs nur mal überflogen:oops:), aber der TE wollte

Zitat:

Gauß-Verfahren - Matrix lösen

mfg

[Dejan Vu]

Ich dachte, er meint das Gaußsche Eliminationsverfahren, um Gleichungssysteme zu lösen. Weil: Eine 'Matrix lösen' kann nur Neo.

[frankyboy1974]

hallo,

als ich Neo laß, dachte ich zuerst an den Fisch (aber der heißt nemo).

mfg

[jfheins]

Zitat:

Zitat von Bjoerk (Beitrag 1313845)

Ein Gauß 40 x 40 dürfte bei Floats so 1 sec. brauchen. Das Problem hier dürfte dein Zahlenformat sein. Wie wäre es hingegen, mit Floats zu arbeiten und zur Ausgabe sich eine FloatToFrac zu schreiben. Hier das wäre mal ein Anfang.

Du musst aber einen langsamen Computer haben. Steht da TI-57 oder so drauf? :stupid:
Ich habe mal MATLAB angeworfen auf meinem Desktop-PC von 2008. Ein 40x40 Gleichungssystem wird in 0,15ms gelöst. Eingabe "x = A\b;" entspricht anschaulich A^(-1)*b benutzt aber LU-Zerlegung.
Eine Gauss-Implementierung von Github schafft es immer noch in 0,6ms. Bei 400 Elementen ist es auffälliger, da braucht der Gauß 400ms und linsolve() 20ms.

Zum Thema: Du musst auf jeden Fall mit dem String-gerechne aufhören ;-) Vll. als erste Maßnahme mal Int64 für Zähler/Nenner hernehmen, oder wenn es WIRKLICH rational bleiben muss, dann auf Byte-Arrays für Zähle/Nenner gehen. Oder halt etwas Gehirnschmalz in eine eigene Div/Mod Funktion für Extended stecken und doch Gleitkommazahlen verwenden.