TObjectDictionary auch mehr-dimensional?

[photor]

Hallo Forum,

ich verknote mir gerade mein Hirn und frage mich, ob ich mir das alles nicht zu kompliziert mache.

Kurze Erklärung:

• bisher speichere ich eine Spannungstensor (3 Spannungswerte - Real-Zahlen) für ca. 20 berechnete Zwischenschritte für alle interessierenden Knoten (KnotenID - integer) in einem TObjectDictionary<Knoten-ID,SpannungstensorArray>. Dafür habe ich eine Unit mit entsprechenden Klassen, Prozeduren, Funktionen ... gebaut.
• jetzt würde ich das gerne für Elemente machen, die jeweils mittels 4 Knoten definiert sind. Es wäre jetzt einfach, wenn ich statt eines Dictionaries mit der KnotenID (Integer) als Key zusätzlich die ElementID (= Integer) als Schlüssel hätte. Also etwas in der Art TObjectDictionary<(ElementID,KnotenID),SpannungstensorArray> hätte - also ein Tupel (Integer,Integer) als Schlüssel. Aber diese Art, das aufzuschreiben zeigt schon, dass das wohl syntaktisch schwierig ist. Trotzdem könnte ich dann natürlich einiges von oben wiederverwenden.

Würde sowas gehen?

Eigentlich ist das ganze nur eine Frage, wie organisiere ich die Daten (die auch noch aus diversen Files eingelesen werden müssen), so dass ich geordnet drauf zugreifen kann. Vielleicht hat ja jemand noch eine andere Idee, wie das recht einfach ginge, was ich nur nicht sehe, weil langsam betriebsblind.

Im Moment versuche ich, eine Klasse zu definieren, die alle Daten strukturiert für ein Element zusammenfasst. Dabei verknotet sich halt gerade mein Hirn und ich suche nach was einfacherem.

Ciao,
Photor

[Warf]

Dem fpc fehlt eine Tupel Bibliothek. Deshalb hatte ich mal für meine Zwecke sowas schonmal geschrieben: https://github.com/Warfley/Iterators/tr ... /src/tuple

Für die Nutzung im dictionary musst du schauen was für Methoden und Operatoren du brauchst für die entsprechenden Vergleichsoperatoren (gleicheit, hashing, etc.). Generics.Collections hat aber soweit ich weiß binäres Standardverhalten, was auf records ohne besondere Semantik bereits schon von Haus aus laufen müsste. Also sollte es reichen einfach als key einen Tupel record reinzustecken

[paweld]

Ich würde es wie im beigefügten Beispiel tun - ich verwende FGL und nicht Generics.Collections.

[Warf]

ich verwende FGL und nicht Generics.Collections.

Würde ich nicht empfehlen, fgl ist Recht alt und sehr limitiert und es gibt kaum Intentionen da viel weiter zu arbeiten. Generics.Collections ist moderner, hat mehr features, wird mehr maintained und ist auch Delphi kompatibel.
Gibt eigentlich keinen Grund noch fgl zu benutzen

[photor]

Hallo,

Danke für den Input. Ich schau mir das mal an. Vielleicht bringt es mir ja ein paar Ideen (und hilft beim Entknoten).

Bei der Generics.Collection würde ich aber bleiben wollen.

Ciao,
Photor

[PascalDragon]

Gibt eigentlich keinen Grund noch fgl zu benutzen

Fgl ist kleiner. Je nach Usecase kann das einen Unterschied machen.

[photor]

Hallo Forum,

ich hänge mich nochmal an meinen Beitrag an (ich hoffe, das ist erlaubt), weil ich eine - zumindest halbwegs zugehörige - Anschlussfrage habe.

Nachdem ich mich gegen mehrdimensionale Keys im TDictionary entschieden habe, konnte ich die Daten halbwegs in der Struktur hinter dem Key unterbringen. Ich hoffe noch, dass das sich ordentlich einlesen lässt. Ich habe dazu das TDictionary zunächst einmal mit Default-Daten initialisiert ... (die Struktur ist dann vorhanden und kann stückweise gefüllt werden)

... und dazu den Key (vom Typ Integer) auch mit Zahlen von 0 ... AnzahlDatensätze-1 belegt.

Aber kann ich jetzt einfach die Keys mit neuen (den wirklichen) Namen/IDs/Keys für die Daten belegen? Oder muss ich sowieso erst den alten Datensatz z.B. Key = 1 löschen und dann den Key = 2009122 anlegen?

Im letzten Fall kann ich mir die Initialisierung schenken und besser direkt die Original-Daten einlesen.

Warum so kompliziert? Die Daten, die unter einem Key vereinigt werden sollen, stammen aus mehreren Dateien, die ich lieber nacheinander verarbeiten würde (sonst müssten die alle gleichzeitig im Speicher liegen - das würde ich vermeiden wollen).

Vielleicht kann ja jemand helfen oder hat eine andere Idee.

Vielen Dank,
Photor

[Warf]

Du kannst den Key nicht einfach ändern, denn aus dem Key wird ein Hash berechnet um damit das Datenelement im Container zu finden. Wenn sich der Key ändert muss eine neue Position berechnet werden und das Datum dort hin verschoben werden.

[Warf]

Im letzten Fall kann ich mir die Initialisierung schenken und besser direkt die Original-Daten einlesen.

Warum so kompliziert? Die Daten, die unter einem Key vereinigt werden sollen, stammen aus mehreren Dateien, die ich lieber nacheinander verarbeiten würde (sonst müssten die alle gleichzeitig im Speicher liegen - das würde ich vermeiden wollen).

Vielleicht kann ja jemand helfen oder hat eine andere Idee.

Vielen Dank,
Photor

Für sowas kannst du pointer verwenden, das du dann im Dictionary nur einen Record oder ne Klasse mit pointern auf die verschiedenen Daten abliegst

[photor]

Du kannst den Key nicht einfach ändern, denn aus dem Key wird ein Hash berechnet um damit das Datenelement im Container zu finden. Wenn sich der Key ändert muss eine neue Position berechnet werden und das Datum dort hin verschoben werden.

So etwas hatte ich mir schon gedacht (was aber mehr Halb- als richtiges Wissen ist). Schade zwar, aber dann muss ich mir etwas anderes überlegen. Das Initialisieren der Struktur war trotzdem gut; anhand der Struktur habe ich zumindest einige Prozeduren drumherum (z.B. Ausgabe und Logging) implementiert. Dann muss die Init-Prozedur jetzt halt zur Einlese-Funktion umgebaut werden.

Danke für die schnelle Antwort.
Photor

PS: da der Key zum Auffinden der Daten gebraucht wird, ist ein TDictoinary mit diesem Key (eine ID) schon die richtige Wahl. Ob dahinter jetzt eine Datenstruktur oder ein Pointer auf die Datenstruktur liegt, ist dann egal, denke ich.