2 dimensionale sets?

[alzaimar]

Zitat von 3_of_8:

Weil du "Fließkommazahlen" geschrieben hast, was falsch ist.

Echt? Also, ich kenn das seit meinem Studium, in meinen Büchern als Fließkomma, Google spuckt fast so viele Artikel zu 'Fließkomma' aus, wie zu 'Gleitkomma'. Ich denke mal, ich schließe mich den fast 50% Dummen an, die eine falsche Ausdrucksweise verwenden.

Zitat von 3_of_8:

Und der Compiler kann die Obergrenze ja leicht ermitteln, indem er sich das größte Element ansieht.

Äh, woher weiss er das? Das größte Element, das die Menge enthalten wird, ist zur Kompilierzeit nichtbekannt. Wie groß soll der Speicherbereich werden? Oder meinst Du allen Ernstes, das Delphi sowas unterstützen sollte?

Delphi-Quellcode:

Var 
  X : Set Of Int64; // Das wird ganz schön groß.
  Y : Set Of TObject; // Das auch.

[3_of_8]

Nein, tue ich nicht. TObject ist kein Ordinaltyp, Int64 auch nicht (zumindest nicht in 32 Bit-Delphi). Spätestens bei Cardinal sollte Schluss sein, das sind ja bereits 128 MB pro Set. Aber zumindest Words sollten drin sein.

Aber der Compiler kann definitiv die Obergrenze sehen, in dem Fall ist es zum Beispiel high(Cardinal).

[Apollonius]

Das sehe ich auch so. Die Koordinaten-Tupel müsste man eben in den entsprechenden Ordinaltyp casten, wie ich bereits in Post 12 vorgeschlagen habe.

[3_of_8]

Was dann aber zu unnötigem Speicherverbrauch führen kann. Eine Hashset-Implementation oder eine sortierte Liste von Sets oder sogar eine sortierte Liste von getaggten, sortierten Listen von Integern könnte hier sinnvoller sein. Dann kann man immerhin in logarithmischer Zeit nach Koordinaten suchen.

[alzaimar]

@3_of_8, @Apollonius:Meint ihr allen Ernstes, daß ein 128MB großer Basistyp in einer seriösen Programmiersprache etwas zu suchen hat? Aber ich sehe gerade, ihr widmet euch wieder dem Thema, bei dem mit 3_of_8's Vorschlag eigentlich die optimale Lösung vorgeschlagen wurde. Man kann ja die X-Koordinate in den höherwertigen 16/32-bit ablegen, die Y-Koordinate in den unteren. Dann kann man aufs Casten verzichten und mappt mit einfachen MOD in die Hashmap.

[3_of_8]

Wenn array[Cardinal] of <Typ> geht, warum nicht set of Cardinal? Letzteres ist sogar kleiner.

[alzaimar]

@3_of_8: Gähn.

[3_of_8]

Was heißt da gähn? Nach deiner Begründung dürfte array[Cardinal] ja auch nicht gehen und der Compiler müsste da dann auch eine Obergrenze setzen.

[alzaimar]

Zitat von 3_of_8:

Was heißt da gähn? Nach deiner Begründung dürfte array[Cardinal] ja auch nicht gehen und der Compiler müsste da dann auch eine Obergrenze setzen.

'Gähn' ist deutsch und eine Lautmalerei. Ich wollte damit zum Ausdruck bringen, das mich deine Rechthaberei langweilt.

Von mir aus ist 'SET OF CARDINAL' ein wichtiger Datentyp, der unverständlicherweise in ObjectPascal und allen anderen Programmiersprachen nicht implementiert wurde, obwohl er durchaus abgebildet werden könnte. So wie 128-stelliges BCD, Ganzzahlen mit beliebiger Stellenanzahl, Tristate Logic usw. Allerdings bezweifle ich, das die Person, die dieses Sprachfeature implementiert, am nächsten Tag noch seinen Job innhalten dürfte.

Bei meinen Einwänden bezüglich einer effizienten Umsetzung eines Compilers bin ich nicht davon ausgegangen, das jemand allen Ernstes ein 128MB-Monster im Speicher halten würde, wo man so etwas mit sparse sets wesentlich komprimierter darstellen könnte.

Noch Einwände, bei denen ich nicht einschlafe?

[dajuhsa]

ich will mich ja in eure Diskussion nicht einmischen, aber hier geht es wohl nicht mehr um mich, oder? ^^"