Koordinatentupel-Map sortieren??

[SuperFamicom]

Hallo,
ich habe eine Hashmap<String, Objekt>, die Korrdinatentupel und das dazugehörige Objekt enthält.
String enthält die Koordinaten, als Bsp.: "10:30".
10 entspräche dem x- und 30 dem y-Wert.
Nun will ich den String splitten und sortieren: (1, 1), (1, 2), ..., (1, n), (2, 1), (2, 2), ..., (m, n)
Wie geht's schnell?

-VG-

 

[SlaterB]

was hat denn das Splitten eines Strings mit einer Koordinatentupel-Map zu tun?

mit
String[] parts = st.split("\\),");
bekommst du aus
(1, 1),_(1, 2),_(n, m)
die Einzelstrings
(1, 1
_(1, 2
_ (n, m)

nicht besonders schön, vielleicht das Leerzeichen und die öffende Klammer auch ins split aufnehmen,
dann müsstest du nur noch das erste und letzte Element etwas korrigieren

Alternativen:
indexOf + substring

RegEx und find()

 

[0x7F800000]

egal woher die koordinaten kommen: wenn du diese öfter als einmal im leben brauchst, würde ich dringend empfehlen, diese in angemessener form, nämlich als tupel von zahlen, abzuspeichern. Wenn du jedes mal Strings splittest und Ziffer parsen musst, ist das performancemäßig (verglichen zum auslesen von gewöhnlichen integern o.ä.) eine totale katastrophe.

 

[homer65]

Zum Sortieren gibt es das Stichwort Comparator.

 

[SuperFamicom]

@SlaterB:
*g* villeicht etwas unglücklich rübergebracht
Die Map hat einen Key vom Typ String und einen Eintrag mit dem Objekt (hier irrelevant).
Die keys sehen so aus: "10:30".
Mit den Klammern wollte ich nur für Übersicht sorgen.
Das mit dem splkit-Befehl habe ich jetzt auch.
ich hab erstmal eine Klasse Point eingeführt:

class Point implements Comparable<Point> {
    int x;
    int y;
    
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    
    public int compareTo(Point o) {
        if (this.x == o.x) {
            return this.y - o.y;
        } else {
            return this.x - o.x;
        }
    }
    
}

Sortiert wird hier:

ArrayList<Point>    list = new ArrayList<Point>();
        
        for (String keys : source.keySet()) {
            list.add(new Point(Integer.parseInt(keys.split(":")[0]), Integer.parseInt(keys.split(":")[1])));
        }
        Collections.sort(list);
        Iterator it = list.iterator();
        
        while (it.hasNext()) {
            System.out.println(((Point) it.next()).x + ", " + ((Point) it.next()).y);
        }

Ein Problem habe ich jetzt immernoch dabei: Er spuckt mir eine Liste aus, deren size() kleiner ist, als die eingespeiste source-HashMap-size().
Ein Bsp.: source enthält z.b. die Koordinaten "7:19", "2:19", "2:16", "5:1" (~> Größe = 4)
Dann schrumpft der mir das ganze und gibt aus: "2:16", "5:1" und "7:19" (~> Größe = 3)
"2:19" verschwindet im Nichts.

 

[0x7F800000]

verstehe ich nicht. Sollte nicht so sein. Kannst du ein kompilierbares Stück code posten, bei dem das problem auftaucht?

 

[SlaterB]

da wird doch zweimal it.next() aufgerufen
jeder next()-Aufruf -> nächstes Element


> "2:19", "2:16",
> Dann schrumpft der mir das ganze und gibt aus: "2:16",
> "2:19" verschwindet im Nichts.

aus "4000:19", "2:16",
würde "4000:16" werden

 

[0x7F800000]

da hat SlaterB wieder mal genauer hingeguggt... Naja, großer schwachsinn ist das schon (wofür gibt's denn toString()?) aber mit dem beschriebenen Fehler hat's nichts zu tun. Also ich meine: auch wenn da jetzt unsinn ausgegeben wird, an der size() der map kann das ja nichts ändern.

 

[SuperFamicom]

@SlaterB:
Ja, natürlich. Das war's (doppelter next-Aufruf) ^^

Problem gelöst!

Danke @all

 

[0x7F800000]

Man trinke eine Tasse Tee, schieße sich mit der Schrotflinte ins Bein, und schließe daraus, dass das Teetrinken wehtut^^

 

[SlaterB]

immer auf alles gefasst sein

 

[SuperFamicom]

Jetzt tut sich das nächste problem auf -.-

private final HashMap<Point, EditorTile> sortKeys(HashMap<Point, EditorTile> source) {
        System.out.println("source-size() = " + source.size());
        
        ArrayList<Point>    list = new ArrayList<Point>();
        
        for (Point keys : source.keySet()) {
            list.add(new Point(keys.x, keys.y));
        }
        Collections.sort(list);
        for (int i = 0; i < list.size(); i++) {
            System.out.println("x = " + list.get(i).x + ", y = " + list.get(i).y);
        }
        
        return null;
    }

... funktioniert soweit schön und gut. (Ignoriert den Rückgabewert. Soweit bin ich noch nicht.)

Ich hab jetzt Andreys Ratschlag befolgt und kein String mehr als Schlüssel, den ich splitte.
Der neue Schlüssel ist vom Typ Point.
In meinem Programm kann es vorkommen, dass das Objekt mit dem dazugehörigen Schlüssel neu zugewiesen wird: ein neues Objekt mit selbigen Schlüssel. Normalerweise sollte dieser beim put-Aufruf den alten Eintrag überschreiben. Die folgende Methode fügt ein Objekt X mit Schlüssel A hinzu oder (sollte zumindest - laut Literatur -) überschreibt gegebenfalls ein vorhandenes Objekt X mit Schlüssel A mit einem neuen Objekt Y und Schlüssel A.

Was mein Programm hier an der Stelle macht: zweimal der gleiche Schlüssel Point (mit x und y) mit put-Aufruf führen zu doppelten Einträgen:

private final void addTile(int x, int y) {
        map.put(new Point(x, y), new EditorTile(parent.getSelectedTile().getImage(), x, y));
    }

Dies soll natürlich nicht sein. Muss ich dem Point-Schlüssel eine eindeutige ID mitgeben? Reichen x und y als Koordinaten nicht aus? Oder liegt es am new-Operator? Muss ich jetzt noch eine Liste erstellen mit den Schlüsseln?

Ich hoffe, das Problem ist verständlich formuliert^^

-VG-

 

[mvitz]

Du solltest in Point noch die Methode equals überschreiben:
[HIGHLIGHT="Java"]public boolean equals(Object anObject) {
}[/HIGHLIGHT]

Zu tun ist hier:
Prüfen ob anObject != null gucken ob anObject vom Typ point ist und darauf casten. Anschließend x und y koordinaten vergleichen.

 

[SuperFamicom]

Danke habi55,

funktioniert einwandfrei^^

 

[mvitz]

Achso und soweit ich weiß, soll man wenn man equals überschreibt auch hashCode überschreiben. Evtl ginge als Hashcode für so ein Tupel etwas in der Form:
[HIGHLIGHT="Java"]@Override
public int hashCode() {
return this.x * 10 + this.y;
}[/HIGHLIGHT]

 

[Spacerat]

Equals scheint hier wohl weniger relevant... Er arbeitet mit einer HashMap. Deswegen wohl eher "hashCode()". Denn selbst wenn die Points inhaltlich gleich sind, sind es doch zwei verschiedene Instanzen
@Edit: habi55 war schneller...
@Edit2: Wenn man equals überschreibt, soll man auch hashCode überschreiben... Mal aufräumen mit diesem saudämlichen Gerücht....
equals bedeutet inhaltliche Gleichheit. hashCode ist dagegen (suzusagen) eine Instanzierungs-ID. hashCode sollte also nur zusätzlich überschrieben werden, wenn man es vermeiden will, das eine HashMap zwei Objekte aufnimmt, die zwar inhaltlich gleich sind, jedoch zwei verschiedene Instanzen.

 

[Marco13]

Equals und hashCode sollten immer so überschrieben werden, dass sie "konsistent" sind - es gibt kaum Fälle, wo man nur eine von beiden überschreibt. Wenn man eine überschreibt, dann auch die andere. Siehe dazu auch http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#hashCode() und http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)