Doppel schnell aus Liste löschen.

[Dejan Vu]

1. Vorschlag: Sortiere die Liste und dann lösche beim einmaligen Durchlaufen alle Punkte raus, die "gleich! dem vorherigen Wert sind. Das 'löschen' geht so, das man das entstehenden Loch einfach mit dem nächsten Element auffüllt. etwa so:

Delphi-Quellcode:

procedure RemoveDuplicates (aList : TSomeList);
Var
  i,j : Integer;

Begin
  aList.Sort();
  j := 0;
  for i := 1 to aList.Length - 1 do 
    if aList[i].CompareTo(aList[j]) <> TCompareResult.Equal then begin 
      inc(j);
      aList[j] := aList[i];
    end;

  aList.Length := j;
end;

Sortieren ist vom Aufwand O(n log n), ergo ist das Verfahren vom gleichen Aufwand. Besser als O(n^2), wie beim zu optimierenden Verfahren.
Es geht aber noch schneller: Verwende dazu eine Dictionary und übertrage mit o.g. Pattern nur die Werte, die noch nicht in der Dictionary sind.

Delphi-Quellcode:

procedure RemoveDuplicates<TElement> (aList : TSomeList);
Var
  i,j : Integer;
   lookup : THashMap<TElement>;
Begin
  j := 0;
  lookup := THashmap<TElement>.Create;
  try
    for i := 1 to aList.Length - 1 do 
      if not lookup.Contains(aList[i]) then begin 
        lookup.Add(aList[i]);
        inc(j);
        aList[j] := aList[i];
      end;
  finally
    lookup.Free;
  end;
  aList.Length := j;
end;

K.a. ob es in Delphi eine THashmap gibt. Das ist eine Dictionary, aber nur für Schlüssel (ohne Nutzdaten)

Der Aufwand ist hier O(n), wenn das Nachschlagen ('Contains') und Anfügen ('Add') an eine THashmap vom Aufwand O(1) ist. Das sollte aber so sein, da hier idR Hashlisten zum Einsatz kommen. Wegen der Floatwerte muss der Comparator der THashmap vermutlich angepasst werden.

[Jasocul]

Vielleicht wäre es ja auch möglich, die doppelten Elemente gar nicht erst in die Liste aufzunehmen?
Also beim Einlesen der Daten in die Liste schon prüfen, ob der Wert schon enthalten ist.

[Dejan Vu]

Dann hättest Du -rein theoretisch- das gleiche Performanceproblem bzw. Optimierungspotential

[himitsu]

Zitat von Dejan Vu:

Dann hättest Du -rein theoretisch- das gleiche Performanceproblem bzw. Optimierungspotential

Nicht, wenn es sehr viele Doppelte sind, denn jetzt werden die Doppelten mit verglichen und so wären sie garnicht erst in der Liste.

Und wenn man die Liste gleich sortiert aufbaut, dann verringert sich auch noch der Nachschau- und Sortieraufwand.

[mkinzler]

Es kommt auch darauf an, wieviele auf einen Schlag eingefügt werden und wieviele Einträge die Liste hat.
Eine kleine Verzögerung beim Einfügen ist meist weniger schlimm, als eine größere, wenn später vorhandene Werte entfernt werden müssen.

Bei eienr Stringliste kann man das Einfügen von Doubletten ja einfach durch entsprechenden Wert von <TStringList>.Duplicates verhindern.

[Dejan Vu]

Natürlich kann es sinnvoll sein, eine Prüfung am Eingang vorzunehmen, aber rein rechnerisch ist der Aufwand eh der Gleiche. Wenn ich bei jedem Einfügen mit 'IndexOf' prüfe, ob es den Wert schon gibt, dann habe ich bei jedem Einfügen den Aufwand O(n). Wenn ich also N Elemente einfüge ist das O(n^2). Kein Unterschied zu vorher (vom Aufwand, Komplexität, Big-Oh). Klar, die zu durchsuchende Liste ist anfangs kürzer, insofern wird das schon etwas bringen, aber zuerst schrauben wir an der Komplexität (Aufwand, Algorithmus), und anschließend kümmern wir uns um den Kleinkram.

Wenn ich die Liste ständige sortiert halte, ist der Aufwand sogar höher, denn das Einfügen eines Wertes in eine Liste ist leider vom Aufwand O(n), denn auch wenn das Suchen schnell geht, muss ich doch Platz schaffen, um das Element in der Mitte irgendwo einzufügen, und das geht in einer normalen Liste nicht unter O(n). Ergo habe ich beim Einfügen in eine sortierte Liste den Aufwand O(log n) für das Suchen + O(n) für das Einfügen = O(n). Für N Elemente sind das wieder O(n^2).

Das lohnt sich nur, wenn die Wartezeit beim Einfügen eines Elements unwichtig ist bzw. in der Betrachtung keine Rolle spielt, z.B. da die Erfassung z.B. manuell oder nur sporadisch erfolgt.

[Jasocul]

Programmieraufwand:
Ob ich nun beim Einfügen eine Prüf-Routine habe oder eine Routine im Anschluss habe, halte ich für einen geringen Unterschied beim Programmieraufwand (wenn überhaupt einer da ist).

Schnelligkeit:
Das hängt natürlich von der Menge der Elemente ab.
Aber prinzipiell sollte die Anzahl der Vergleiche weniger sein, wenn man vor dem Einfügen prüft, weil grundsätzlich weniger Elemente vorhanden sind.
Abgesehen davon spart man sich im Doppelungsfall das Einfügen und das spätere Löschen.

Oder stimmt etwas nicht mit meinem gesunden Menschenverstand?

[mkinzler]

Zitat:

Wenn ich bei jedem Einfügen mit 'IndexOf' prüfe, ob es den Wert schon gibt, dann habe ich bei jedem Einfügen den Aufwand O(n).

Unter Umständen fällt das aber nicht so auf.

[Dejan Vu]

Zitat von Jasocul:

Programmieraufwand:

Der ist gut Mit 'Aufwand' meine ich die Performance hinsichtlich der Komplexität. Also Big-Oh. Man sagt doch: Quicksort ist vom Aufwand O(n log n), Bubblesort ist vom Aufwand O(n^2) usw.

Zitat:

Oder stimmt etwas nicht mit meinem gesunden Menschenverstand?

Ganz bestimmt nicht, also ganz bestimmt ist alles in Ordnung. Ich sagte ja: Es ist vermutlich schneller, das ganze während des Einfügens zu machen, aber von der Komplexität her (hier wieder: Nicht, was man tippt ) ist es das Gleiche.

Von der reinen Performance her wäre die Hashmap-Variante mit Sicherheit die schnellste.