Gauß-Verfahren - Matrix lösen

[Dejan Vu]

Diese Diskussion à la 'Extended ist genau genug' ist Quark. Entschuldigung. Beim Rechnen mit sehr kleinen UND sehr großen Zahlen kommen falsche Ergebnisse heraus, außer! man rechnet genau. Und das kann man nun einmal nur mit exakten Brüchen machen. Ergo benötigt man als 'Zahl' Datentyp z.B. einen Record (oder ne Klasse) mit Zähler und Nenner. Dann definiert man noch die Operationen auf diesem Zahl-Datentyp und -wupps- werden die Ergebnisse genau.

Ich habe -wie erwähnt- mit Gauß und Extened bei Berechnungen zur Kälteleistung von Kühlkompressoren keine guten Erfahrungen gemacht. Es ist blöd, wenn die Kennlinien statt im Bereich von 600W dann bei -170 liegen, weil klitzekleine Ungenauigkeiten beim Rechnen passiert sind. Gut, ich hatte Glück, das LUP Dekomposition hier geholfen hat. Aber grundsätzlich sollte man das schon anders lösen.

Ich unterstelle dem TE im übrigen, sich in der Zahlentheorie und mit Genauigkeitsrechnungen auszukennen. Ich denke, da muss man nicht mehr den Besserwisser raushängen lassen. Natürlich ist niemand gemeint, ich habe das nur präventiv gesagt

[Danny92]

Zitat von Namenloser:

Du wirst dich von der Idee der Exaktheit sowieso früher oder später verabschieden müssen. Rationale Zahlen kannst du zwar noch exakt darstellen, aber spätestens bei den reellen Zahlen hört es eh auf.

Ich lasse nur rationale Zahlen als Eingabe zu. Sprich ganze Zahl / ganze Zahl. Kein pi oder E oder sonstiges. Und egal welche Rechenoperation (+,-,*,/), das Ergebnis ist immer auch eine rationale Zahl.
Und Int64 kann ich leider nicht nehmen, da dies kein Ordinaldatentyp im Gegensatz zu Integer ist.
Mit dem Methoden QR und LUP bin ich bisher noch nicht vertraut, deswegen hatte ich mir die Berechnung erst einmal ohne weiteren Aufwand erhofft.
Ich werde das mit dem BigInt mal probieren.

[Jens01]

Das Ding von Michael ist bekannt, oder?

[Danny92]

Zitat von Jens01:

Das Ding von Michael ist bekannt, oder?

Das "Ding" von Michael Jackson ist mir nicht bekannt. Ob mir das außerdem was nützen wird?

Ich habe den Code halt auf extended umgestellt. Wie erwartet, ein schreckliches Ergebnis, und noch schlimmer...(Bild 1)

Abhilfe schafft hier nur die FloatToFracStr von Björk....Dankeschön, besser als gar nichts. Jedoch treten auch hier Rundungsfehler ab einer bestimmten Matrixgröße auf, schade! (Bild 2)

[Jens01]

Zitat:

Das "Ding" von Michael Jackson ist mir nicht bekannt. Ob mir das außerdem was nützen wird?

Wieso benötigst Du das Ganze überhaupt? Vielleicht findet man dort die Lösung des Problems.

[Danny92]

Zitat von Jens01:

Zitat:

Das "Ding" von Michael Jackson ist mir nicht bekannt. Ob mir das außerdem was nützen wird?

Wieso benötigst Du das Ganze überhaupt? Vielleicht findet man dort die Lösung des Problems.

Um Matrizen mittels dem Gauß-Algorithmus schnell und exakt lösen zu können.

Leider aber unterstützt Delphi keine sog. Langzahlarithmetik.
https://de.wikipedia.org/wiki/Langzahlarithmetik

[Dejan Vu]

Da Du eine exakte Lösung möchtest, bringt Extended gar nichts. Das wusstest Du vorher, hast es auch bewiesen und hast es nun belegt.

Der Grund für deine langsame Implementierung liegt zum Einen in der Forderung nach Exaktheit und zum Anderen an der Umsetzung mittels Strings. Alternativen, d.h. Datenstrukturen, die beliebig lange Zahlen repräsentieren, wurden Dir hier auch genannt.

Also: Umsetzen!