Collections TreeSet/TreeMap, doppelte Einträge zulassen ?

[Back2Basic]

moinsen,

hab folgendes Problem,

ich hab ungefähr 78000 Objekte die ich in einen TreeSet/TreeMap abspeichern soll.

Das Problem ist nur das ich auf ungefähr 17.000 komme, es werden wohl Objekte nicht eingefügt die vom Wert her gleich sind etc.

Gibt es eine Lösung die mir zulässt das ich doppelte Einträge habe oder muss ich meine Objekte irgendwie erweitern (zb. Counter).

mit freundlichen Grüßen

 

[bygones]

du musst die compare Methode deiner Klasse anpassen. d.h. sie darf nicht 0 zurueckliefern.

 

[Back2Basic]

mein Professor meinte das ich einen Wert anhängen sollte, nur wie funzt das ohne das der Baum völlig entarntet bzw. meine keys ( nach den ich sortiere ) manipulieren muss.

keys << kommen mehr als einmal vor

 

[bygones]

entweder du machst deine keys eindeutig oder eben du aenderst wie du sortierst.

wenn deine keys eindeutig sein sollen, dann musst du diese eindeutigkeit in der equals bzw compareTo methode definieren (zb mit einem zusaetzlichen counter).

ansonsten eben beim sortieren 0 nicht zulassen und einen Wert <0 oder > 0 zurueckgeben

 

[SlaterB]

was ist das denn für ein doppelter Vorschlag, bei gleichen Elementen soll compareTo <0 zurückgeben?
und das läßt die Welt nicht abstürzen?

Keys eindeutig machen klingt für mich besser, oder gleiche Elemente zu Listen zusammenfassen

 

[Back2Basic]

schonmal danke für die Vorschläge,

Mein Element besteht halt aus 2 Strings

Wortpaar ( string 1 , string 2)

nach dem ersten String wird sortiert nur habe ich halt 1000 x einen "." oder "?"

Einen internen Counter basteln, darauf bin ich auch schon gekommen aber wenn ich alle elemente suche die "." haben um daraus Gibberisch zu produzieren o0 . Da würde ich ja ne Fehler kriegen, , klar kann ich auch mein value durchsuchen aber dachte das geht irgendwie anderes grr.
Zumindest laut meinem Professor ist das ne 5 Zeiler...

 

[bygones]

was ist das denn für ein doppelter Vorschlag, bei gleichen Elementen soll compareTo <0 zurückgeben?
und das läßt die Welt nicht abstürzen?

wenn gleiche Element in einer sortieren Liste eingefuegt werden sollen, ist es egal ob sie nun vor einander oder hineinander stehen (je nach dem von welchem Element man sieht), ergo kann man bei gleichheit in der compareTo methode bei 0 entweder einfach einen negativen wert oder einfach einen positiven wert zurueckgeben (im normalfall waere das dann -1 bzw 1)

 

[bygones]

schonmal danke für die Vorschläge,

Mein Element besteht halt aus 2 Strings

Wortpaar ( string 1 , string 2)

nach dem ersten String wird sortiert nur habe ich halt 1000 x einen "." oder "?"

Einen internen Counter basteln, darauf bin ich auch schon gekommen aber wenn ich alle elemente suche die "." haben um daraus Gibberisch zu produzieren o0 . Da würde ich ja ne Fehler kriegen, , klar kann ich auch mein value durchsuchen aber dachte das geht irgendwie anderes grr.
Zumindest laut meinem Professor ist das ne 5 Zeiler...

kannst du nicht deine equals methode bzw dein sortierer erweitern, dass wenn string1 gleich ist, nach string2 sortiert wird ?!

 

[Back2Basic]

hmm brauch den leider noch für andere Sachen

Muss leider auch alles vorgefertigte aus den Collections benutzen, inkl den Sortieralgorithmen etc.

 

[nillehammer]

wenn gleiche Element in einer sortieren Liste eingefuegt werden sollen, ist es egal ob sie nun vor einander oder hineinander stehen (je nach dem von welchem Element man sieht), ergo kann man bei gleichheit in der compareTo methode bei 0 entweder einfach einen negativen wert oder einfach einen positiven wert zurueckgeben (im normalfall waere das dann -1 bzw 1)

Ich halte das für einen schlechten Vorschlag. Die compareTo() sollte immer konsistent zu equals() sein. Wenn man Deinen Vorschlag umsetzt, kann man Instanzen dieser Klasse nicht mehr in Treebasierten Strukturen (TreeSet, TreeMap) speichern. Wenn man inkonsistent zu equals() vergleichen will, sollte man das über einen dedizierten Comparator machen.

 

[SlaterB]

selbst wenn man equals außen vorläßt, so wie auch equals oft genug ohne hashcode() funktioniert,
ist es einfach grausig, ein nicht reproduzierbares compareTo-Verhalten zu haben

A wird eingefügt,
B wird eingefügt, ist gleich A, wird mit A vergleichen, landet links von A,
nach A wird gesucht, ist gleich B aber Vergleich liefert wieder kleiner, also wird links von B weitergesucht aber da ist nix da A rechts von B steht?

man kann ja Elemente in Sortierung pressen, aber nicht pauschal -1 zurückgeben, sondern z.B.
Reflexive Relation ? Wikipedia
wahren!

 

[bygones]

Ich halte das für einen schlechten Vorschlag. Die compareTo() sollte immer konsistent zu equals() sein. Wenn man Deinen Vorschlag umsetzt, kann man Instanzen dieser Klasse nicht mehr in Treebasierten Strukturen (TreeSet, TreeMap) speichern. Wenn man inkonsistent zu equals() vergleichen will, sollte man das über einen dedizierten Comparator machen.

das ist ein Missverstaendnis. Ich spreche hier nicht von der equals/compareTo methode des Objektes selber, sondern eben nur ueber einen dedizierten Comparator.

Daher meine Aussage "entweder eindeutigen key oder das sortieren aendern" - sorry wenn das falsch ausgedrueckt war