Doppel schnell aus Liste löschen.

[Amateurprofi]

Versuch es mal so:

Bei ca. 100000 Einträgen wird am Schluss ca. 100000*100000 mal SameValue aufgerufen.
Die Idee ist, in TFloatPoints.InList, wiederholtes laden des Items (das mit allen Einträgen der Liste verglichen wird) und Epsilon in die FPU Register zu vermeiden und auch die Zugriffe auf die Items der Liste zu beschleunigen.
Ein kurzer Test verlief erfolgreich.
Ich habe 1000 Einträge mit Zufallswerten von X und Y im Bereich 0 bis 9 erzeugt.
Somit können nur max 100 verschiedene Einträge vorhanden sein.
Nach Aufruf von RemoveDuplicates enthielt die Liste dann auch 100 statt vorher 1000 Einträge.
Auf das Clear für "gelöschte" Einträge habe ich verzichtet, denn erstens kann auf diese Einträge eh nicht zugegriffen werden (bzw. sollte nicht zugegriffen werden können) und zweitens weiß ich nicht, was Clear macht. Ich vermute TFloatPoint.Clear setzt X und Y = 0. Da aber X=0 und Y=0 auch gültige Koordinaten sind, sehe ich da keine Vorteile.

Ich habe übrigens ein
type TAFloatPoint=Array of TFloatPoint; eingefügt und die Definition von FItems auf
FItems:TAFloatPoint; geändert.

Delphi-Quellcode:

procedure TFloatPoints.RemoveDoubles;

FUNCTION InList(List:TAFloatPoint; const Item:TFloatPoint; Count:Integer):Boolean;
const Epsilon:Double=1E-4;
asm
            fld      Epsilon        // st0=Epsilon
            fld      QWord [edx]    // st0=X, st1=Epsilon
            fld      QWord [edx+8]  // st0=Y, st1=X, st2=Epsilon
@Loop:      fld      QWord [eax]    // st0=List.X, st1=Y, st2=X, st3=Epsilon
            fsub     st,st(2)       // st0=List.X-X
            fabs
            fcomip   st,st(3)       // List.X-X vs. Epsilon
            ja       @Next          // Verschieden (Abs(List.X-X) > Epsilon)
            fld      QWord [eax+8]  // st0=List.Y, st1=Y, st2=X, st3=Epsilon
            fsub     st,st(1)       // st0=List.Y-Y
            fabs
            fcomip   st,st(3)       // List.X-X vs. Epsilon
            jbe      @True          // Gleich (Abs(List.X-X) <= Epsilon)
@Next:      add      eax,16
            sub      ecx,1
            jnz      @Loop
            xor      al,al
            jmp      @End
@True:      mov      al,1
@End:       ffree    st(2)
            ffree    st(1)
            ffree    st
end;
var
   I,J: integer;
begin
   if FCount<2 then Exit;
   J:=1;
   for I:=1 to FCount-1 do
      if not InList(FItems,FItems[I],J) then begin
         FItems[J]:=FItems[I];
         Inc(J);
      end;
   FCount:=J
end;

[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?