FindItem suchen nach 2ter spalte in CListCtrl (Hashkey)

Martin Richter

Mit O(n) (sprich O von n) wird die Komplexität eines Algorithmus beschreiben.
Der Aufwand für das Finden eines Elementes ist linear und abhängig von der Anzahl der Elemente n. Hierbei fällt nicht ins gewicht ob Du je Element enen Vergleich oder 2 machst...

Wenn Du also häufige Updates machst, muss Die klar sein, das Du im schlechtesten Fall jedesmal die gesamte Liste durchlaufen musst um Dein dämliches Element zu finden.

Dein Problem ist die Komplexität einer Liste die häufig ein Update erfährt und die zyklisch durchsucht wird.

Evl. solltest Du Dich mal mit den Grundlagen der Informatik beschäftigen.
Insbesondere der Komplexität von Algorithmen.

Danke dir. Jetzt wäre das mit dem O(n) geklärt.

Nun ist aber das andere noch offen. Ob das was MFK beschrieben hat das Problem löst das du angesprochen hast?

MFK

y-vonne schrieb:

Nun ist aber das andere noch offen. Ob das was MFK beschrieben hat das Problem löst das du angesprochen hast?

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Besteh ich doch gar nicht. Wollte ja nur wissen ob deine Lösung das angesprochene Problem löst. Du meinst ja, was meint Martin?

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Dann noch zu dem:

Mit O(n) (sprich O von n) wird die Komplexität eines Algorithmus beschreiben.
Der Aufwand für das Finden eines Elementes ist linear und abhängig von der Anzahl der Elemente n. Hierbei fällt nicht ins gewicht ob Du je Element enen Vergleich oder 2 machst...

Da war doch noch was im Hinterkopf. Was ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

MFK

y-vonne schrieb:

Besteh ich doch gar nicht.

Doch, tust du. Auf die Hinweise, dass dein Lösungsansatz ineffizient ist, hast du mit

y-vonne schrieb:

Ist ja ok. Ich weiß dass es Zeit braucht. Wollte aber was anderes wissen!!

geantwortet.

y-vonne schrieb:

Wollte ja nur wissen ob deine Lösung das angesprochene Problem löst. Du meinst ja, was meint Martin?

Nein, ich meine nicht ja. Das Problem ist das Suchen im Listcontrol. Da deine Listen recht kurz sind und du außerdem mit einem komplexen benutzerdefinierten Steuerelement arbeitest, dessen Code du vermutlich nicht verstehst, habe ich mich damit abgefunden.

y-vonne schrieb:

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Es gibt sehr viele Möglichkeiten.

y-vonne schrieb:

DWas ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn du zwei Strings vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

Wenn du Hash-Werte vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

Wenn du ItemData-Werte vergleichst, brauchst du bei der doppelten Anzahl Einträgen die doppelte Zeit.

y-vonne schrieb:

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Du kannst dir die ganze Sucherei aber auch komplett sparen, wenn du es richtig anstellst. Aber davon wolltest du nichts hören!

Martin Richter

y-vonne schrieb:

Da war doch noch was im Hinterkopf. Was ich hier aber noch nicht ganz verstehe. Hier versteh ich nicht warum es keinen Unterschied macht ob ich einen Vergleich mache oder zwei.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Hör mal eine Vorlesung zu Komplexität von Algorithmen... Das war mal mein Hobby <bg>

Klar fällt es ins Gweicht. Aber das hauptproblem liegt in der Grundkomplexität eben in O(n). Konstante Gaktoren werden weggelassen.

MFK.

Danke für deine Hilfe aber du verdrehst immer komplett alles was ich frage.

Wenn ich hundert durchsuche muss ich doch bei einem einfachen Vergleich maximal 100 Werte vergleichen. Bei einem doppelten Vergleich sind es doch 200. Ist doch viel Zeitintensiver.

Du kannst dir die ganze Sucherei aber auch komplett sparen, wenn du es richtig anstellst. Aber davon wolltest du nichts hören!

Weiß nicht was die Antwort hier soll ich wollte hier einfach die Frage der Komplexität klären. Dass ich mir die Suche sparen kann ist mir bereits klar.

Überlass bitte die Fragen die ich an Martin stelle auch Martin. Danke.

dessen Code du vermutlich nicht verstehst...

So wie du meine Anfragen halt nicht verstehst.

Eine andere Möglichkeit gibts nicht. z.B. einen Zeiger auf den key der Map anstatt der position?

Die Frage wurde nun ganz übersehen. Vieleicht kann darauf auch noch jemand eingehen.

Es gibt sehr viele Möglichkeiten.

Super das hat mir nun auch sehr viel geholfen

Hör mal eine Vorlesung zu Komplexität von Algorithmen... Das war mal mein Hobby

Tolles Hobby Dank dir Martin für deine Antwort.

MFK

y-vonne schrieb:

Weiß nicht was die Antwort hier soll ich wollte hier einfach die Frage der Komplexität klären

Die Komplexität deiner Lösung in Abhängigkeit von der Listenlänge ist völlig uninteressant, wenn deine Listenlänge begrenzt ist.

Was interessiert es, wie sich die Laufzeit mit wachsendem n entwickelt, wenn dein n nicht wächst?

y-vonne schrieb:

Überlass bitte die Fragen die ich an Martin stelle auch Martin

Du beißt dich an Martins Aussagen fest, die er gemacht hat, bevor du damit rausgerückt bist, dass du maximal 40 Einträge durchsuchen musst.

y-vonne schrieb:

So wie du meine Anfragen halt nicht verstehst.

Ich versuche, dir zu helfen. Ich kann es auch lassen.

y-vonne schrieb:

Super das hat mir nun auch sehr viel geholfen

Deine Frage war, ob es eine andere Möglichkeit gibt. Die habe ich beantwortet. Vielleicht stellst du die falschen Fragen.

Nein, du kannst mit CListCtrl::GetItemData den lParam-Wert direkt auslesen.

Auf den Satz wollte ich auch noch eingehen. Hier kann ich dann den lParam Wert direkt auslesen. Aber das brauche ich ja gar nicht.

Ich habe ja den lParam Wert und möchte mit diesem nun dein Eintrag suchen und aktualisieren.

Und dazu brauche ich doch dann FindItem oder etwa nicht?

MFK

y-vonne schrieb:

Und dazu brauche ich doch dann FindItem oder etwa nicht?

Du brauchst FindItem nicht, aber es ist einfacher und vermutlich schneller, als in einer Schleife GetItemData aufzurufen. Ich wusste nicht, dass man mit FindItem auch nach lParam suchen kann.

Die Komplexität deiner Lösung in Abhängigkeit von der Listenlänge ist völlig uninteressant, wenn deine Listenlänge begrenzt ist.

Ja versteh ich. Ich wollte das mit der Komplexität nur allgemein geklärt haben jetzt nicht im Zusammenhang mit meinem Problem. Und das hat mir Martin auch benatwortet.

Ich versuche, dir zu helfen. Ich kann es auch lassen.

Bin für jede Hilfe dankbar. Aber mit deiner Aussage: "Code den du eh nicht verstehst" greifst du mich an statt zu helfen.

Deine Frage war, ob es eine andere Möglichkeit gibt. Die habe ich beantwortet. Vielleicht stellst du die falschen Fragen.

Das ist genauso wie die folgende Frage mit ja zu beantworten: "Könnten sie mir die Uhrzeit sagen". Klar wenn man den anderen Ärgern will sagt man einfach nur ja.

Also hier nochmals genauer für dich: Welche einfachere Lösung gibt es, als die mit dem Vector?

Du brauchst FindItem nicht, aber es ist einfacher und vermutlich schneller, als in einer Schleife GetItemData aufzurufen. Ich wusste nicht, dass man mit FindItem auch nach lParam suchen kann.

Ja also doch FindItem. Und dann doch die Liste durchgehen. Und vermutlich schneller.

Das ist ja das was ich gesagt habe.

MFK

y-vonne schrieb:

Bin für jede Hilfe dankbar. Aber mit deiner Aussage: "Code den du eh nicht verstehst" greifst du mich an statt zu helfen.

Das ist kein Angriff, sondern eine Feststellung. Eine Lösung, die ohne Suchen auskommt, würde es erfordern, dass du in den Code deines CodeProject-Steuerelements eingreifst. Da das ein Steuerelement mit vielen zusätzlichen Funktionen ist, ist der Code vermutlich recht lang und komplex und damit für jemanden mit deinem Kenntnisstand nicht so ohne weiteres zu durchschauen. Das ist alles.

Also hier nochmals genauer für dich: Welche einfachere Lösung gibt es, als die mit dem Vector?

Erweitere deine Map um einen Zähler, den du beim Einfügen hochzählst, und benutz den für das lParam.

Kurzfassung

y-vonne: schrieb:

Gibt es eine Möglichkeit ein Listcontrol mit zwei Spalten als Key mit FindItem zu durchsuchen. Beispielsweise ein weiterer Wert als key einfügen.

Martin Richter schrieb:

Macht keinen Sinn FindItem durchläuft das ganze ListControl egal ob ein vergleich oder mehrere. Kein Zeitvorteil.

y-vonne schrieb:

Andere Lösung?

Martin Richter und MFK:
Virtual ListControl

y-vonne: schrieb:

Geht nicht. Da Benutzerdefiniertes Listcontrol

MFK: schrieb:

Wert in LFITEM speichern.

y-vonne: schrieb:

Somit besteht immer noch das Problem mit FindItem das Martin Richter angesprochen hat.

MFK: schrieb:

Nein du kannst GetIemData verwenden.

y-vonne: schrieb:

Nein ich möchte mt dem item den Eintrag suchen.

MFK: schrieb:

Nimm FindItem das ist schneller.

MFK

y-vonne schrieb:

Kurzfassung

Ja, so kann es laufen, wenn man nur nach und nach mit den wichtigen Informationen rausrückt.

Bau da doch mal ein, wo du erwähnt hast, dass du nur 40 Einträge hast und ein Steuerelement benutzt, das du nicht selbst geschrieben hast.

Da das ein Steuerelement mit vielen zusätzlichen Funktionen ist, ist der Code vermutlich recht lang und komplex und damit für jemanden mit deinem Kenntnisstand nicht so ohne weiteres zu durchschauen. Das ist alles.

Du hast recht dass der Code sehr lang und auch komplex ist. Das heißt nicht, dass ich ihn nicht verstehe. Es macht aber aus meiner sicht keinen Sinn so ein komplexes Control anzufassen, zumal dass nur einen kleinen Teil meines ganzen Projekts ist.

Nur weil man nicht alles versteht in diesem komplizierten MFC, heißt das nicht dass man einen schlechten Kenntnisstand in der Informatik hat

Kann ich gerne einbauen

hier:
y-vonne: ich habe maximal 40 einträge

vor diesen beiden ausssagen

y-vonne schrieb
Somit besteht immer noch das Problem mit FindItem das Martin Richter angesprochen hat.

MFK schrieb:
Nein du kannst GetIemData verwenden.

Ich sagte dass das Problem immer noch besteht immer noch, und du hast beauptet nein. Martin Richter hat darauf nicht geantwortet.

MFK

Wenn die Zeit und Energie, die du gerade darauf verwendest, Recht zu behalten, in dein Problem gesteckt hättest, wärst du fertig.

Und hier noch deine Aussage dazu:

MFK schrieb:

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Und ich sagte dass muss ich immer noch! Du hast behauptet nein. Und zum Schluss sind wir dann doch bei FindItem gelandet und der linearen Suche.

Also hatte ich recht!!!!

MFK

y-vonne schrieb:

Du hast recht dass der Code sehr lang und auch komplex ist. Das heißt nicht, dass ich ihn nicht verstehe.

Natürlich nicht. Deswegen schrieb ich "vermutlich" und "nicht so ohne weiteres"

y-vonne schrieb:

Nur weil man nicht alles versteht in diesem komplizierten MFC, heißt das nicht dass man einen schlechten Kenntnisstand in der Informatik hat

Natürlich nicht. Hat ja auch niemand was von schlecht gesagt. Ich bin der Meinung, dass bei deinem Kenntnisstand von Hashfunktionen, Listcontrols und Laufzeitkomplexität du diesen Code besser nicht anfasst. Und du offenbar auch.

y-vonne schrieb:

Und hier noch deine Aussage dazu:

MFK schrieb:

Das Problem besteht, solange du weiter darauf bestehst, dein Listcontrol linear zu durchsuchen.

Und ich sagte dass muss ich immer noch! Du hast behauptet nein. Und zum Schluss sind wir dann doch bei FindItem gelandet und der linearen Suche.

Es gibt eine Lösung, bei der du nicht suchen musst, aber für die würdest du länger brauchen, und der Geschwindigkeitsvorteil wäre bei deinen kleinen Datenmengen wohl nicht besonders groß.

y-vonne schrieb:

Also hatte ich recht!!!!

Kindergarten?