If Anweisung wird übersprungen

[wob]

@Jockelx sagte in If Anweisung wird übersprungen:

Oder count, was ich schöner finde.

Aber nur, wenn man wissen möchte, ob der Key enthalten ist.
Für die Frage, ob der Key enthalten und wenn ja, welchen Wert er hat (was hier im Beispiel der Fall war), will man ja nicht den Hash-Lookup doppelt durchführen (1x zum Testen, 1x zum Auslesen), wenn find es auch mit 1x (zum Testen UND zum Auslesen) erledigt.

[*john 0]

@SeppJ sagte in If Anweisung wird übersprungen:

Kannst du es mal lassen, in jedem Thread Unsinn zu posten?

Unsinn? Unsinn ist Deine Anmerkung und sonst nichts.

[Tyrdal]

@Bushmaster sagte in If Anweisung wird übersprungen:

at riecht nach O(1), aber find nach O(n)

Wie zur Hölle kommst du denn darauf? Beide müssen den Key suchen. Warum sollte sich da was unterscheiden? Nebenbei sind diese Komplexitäten auch im Standard dokumentiert, also mehr lesen und weniger annehmen.

[Columbo]

@john-0

Aber insbesondere im HPC optimiert man auf Cache Hits, d.h. dann kann der Overhead von .at() zum Tragen kommen.

Du benutzt std::map im high-performance Sektor? Also einen red-black tree der jeden Knoten mit new alloziert?

Und weshalb sprechen wir von Cache-hits, wo es hier um zwei Funktionen operator[]/at geht, deren einziger Unterschied darin besteht, was eine branch, die im gegebenen Rahmen (Key soll bereits existieren) als "unlikely" kategorisiert wird, macht?

[Ein ehemaliger Benutzer]

@Tyrdal sagte in If Anweisung wird übersprungen:

Wie zur Hölle kommst du denn darauf? Beide müssen den Key suchen. Warum sollte sich da was unterscheiden? Nebenbei sind diese Komplexitäten auch im Standard dokumentiert, also mehr lesen und weniger annehmen.

semantisch entspricht ein at() dem []-array-operator. da sollte nichts gesucht werden. warum eine map ein at() oder ein [] allerdings als 'suchen' oder O(n) implementiert, ist mir allerdings nicht klar.

[Tyrdal]

@Bushmaster Wieso sollte map::operator[] dem vector::operator[] ( oder array[] ) entsprechen? Das sindoch völlig unterschiedliche Datenstrukturen?! Selbstverständlich muss man in einer map suchen, dafür ist sie doch da!

[SeppJ]

@Bushmaster sagte in If Anweisung wird übersprungen:

@Tyrdal sagte in If Anweisung wird übersprungen:

Wie zur Hölle kommst du denn darauf? Beide müssen den Key suchen. Warum sollte sich da was unterscheiden? Nebenbei sind diese Komplexitäten auch im Standard dokumentiert, also mehr lesen und weniger annehmen.

semantisch entspricht ein at() dem []-array-operator. da sollte nichts gesucht werden. warum eine map ein at() oder ein [] allerdings als 'suchen' oder O(n) implementiert, ist mir allerdings nicht klar.

Wie soll das gehen, dass du prüfst, ob etwas existiert, ohne danach gesucht zu haben?

Außerdem: Wie kommst du auf O(n)? Du scheinst Maps nicht im geringsten verstanden haben, aber die Doku hast du offensichtlich auch nicht gelesen.Wieso liest du nicht zuerst die Doku, bevor du wild herum spekulierst? Zumal dir das nun schon wiederholt gesagt wurde…

[Ein ehemaliger Benutzer]

@SeppJ sagte in If Anweisung wird übersprungen:

Wie soll das gehen, dass du prüfst, ob etwas existiert, ohne danach gesucht zu haben?

key und value sind schon vorher bekannt. man kann den zugriff optimieren. vielleicht kommt man nicht ganz auf O(1). aber fast.

[SeppJ]

@Bushmaster sagte in If Anweisung wird übersprungen:

@SeppJ sagte in If Anweisung wird übersprungen:

Wie soll das gehen, dass du prüfst, ob etwas existiert, ohne danach gesucht zu haben?

key und value sind schon vorher bekannt. man kann den zugriff optimieren. vielleicht kommt man nicht ganz auf O(1). aber fast.

Hör endlich auf zu spekulieren und lies, was eine Map ist!

Aber selbst ohne Lesen muss dir doch sofort klar sein, dass das Unsinn ist. Wie soll das magisch anders gehen, etwas zu finden, als etwas zu suchen? Wo soll da die Optimierung stecken? Suchen: Ich gucke, ob an der Stelle, an der es sein müsste, wirklich etwas ist. Finden: Ich hole das Ding von der Stelle, an der es sein müsste. Wie kommst du in einem der Fälle schneller oder langsamer zu der fraglichen Stelle? Denken vor Schreiben!

[Ein ehemaliger Benutzer]

@SeppJ sagte in If Anweisung wird übersprungen:

Hör endlich auf zu spekulieren und lies, was eine Map ist!

ist schon okay. ich akzeptiere wie es ist. bitte kein streit.

[Columbo]

@Bushmaster Es gibt hier keinen Streit, und erst Recht nicht von einem Mod initiiert. Versuche einfach, deine Annahmen besser zu überprüfen, bevor du Schlussfolgerungen postest.

[Ein ehemaliger Benutzer]

@Columbo
ein mod ist auch nur ein mensch.
kein problem. ich weiß wann ich lieber still sein soll.
ist nicht der rede wert. vergesst das einfach.

[Finnegan]

Nur so am Rande, wenn hier schon wieder wortreich mikrooptimiert wird: Da der Mose-Code zusammen mit der Pause zwischen den Buchstaben als Zeichen ein Präfixcode ist, wäre das eventuell mal wieder eine Gelegenheit einen Trie zu verwenden. Die werden ja sonst gerne etwas stiefmütterlich behandelt

Natürlich nur, wenn man sich den Aufwand geben will, diese Datenstruktur kommt leider nicht fertig aus dem Werkzeugkasten wie die std::map.

[SeppJ]

Ich sage voraus: Die optimalste Variante wird am Ende aber doch irgendwas langweiliges wie ein flaches Array sein. Weil mickrige ~40 Code in einer einfachen, kompakten Struktur mittels Brute-Force zu behandeln ist erfahrungsgemäß immer besser als jede noch so gut skalierende Datenstruktur.

[Finnegan]

@SeppJ sagte in If Anweisung wird übersprungen:

Ich sage voraus: Die optimalste Variante wird am Ende aber doch irgendwas langweiliges wie ein flaches Array sein.

So einen Trie kann man auch sehr kompakt in ein flaches Array quetschen. Der Unterschied ist nur, wie man letztendlich durch dieses Array hüpft, um ans Ziel zu kommen.

Das war ehrlich gesagt auch das, woran ich bei dem Vorschlag dachte. Schliesslich ist das Morse-Alphabet ja nicht sonderlich gross. Für einen "High Performance Morse Decoder" würde ich so einem kompakten Trie auf jeden Fall mal austesten um zu sehen wie er sich gegen die Alternativen schlägt.

[hustbaer]

@Bushmaster Es geht nicht um einen einzelnen Vorfall irgendwo sondern um deine allgemeine Tendenz einfach irgendwas als wahr anzunehmen was du dir gerade ausgedacht hast ohne es nachzuprüfen. Und auf Dinge zu antworten die du nicht bzw. nicht ausreichend verstanden hast.

Konkret zum Thema map::operator []: Die Standard Library bietet at und operator [] grundsätzlich nur dort an wo sie effizient implementierbar sind. D.h. besser als O(N) - was konkret dann meistens O(log N) und manchmal O(1) ist. Was z.B. auch der Grund ist warum std::list weder at noch operator [] hat, obwohl beide trivial zu implementieren wären.

Das selbe gilt übrigens auch für einige andere Funktionen, z.B. push_back und push_front.

[Ein ehemaliger Benutzer]

@hustbaer sagte in If Anweisung wird übersprungen:

Es geht nicht um einen einzelnen Vorfall irgendwo sondern um deine allgemeine Tendenz einfach irgendwas als wahr anzunehmen was du dir gerade ausgedacht hast ohne es nachzuprüfen.

ich behauptete nie eine expertenmeinung zu vertreten. ich bin nur ein einfacher user mit wissenslücken, wie die meisten hier.

@hustbaer sagte in If Anweisung wird übersprungen:

Und auf Dinge zu antworten die du nicht bzw. nicht ausreichend verstanden hast.

das sowas in einem öffentlichen diskussionsforum ein problem sein kann, hätte ich zuvor nicht für möglich gehalten.

[Wutz]

@Ein-ehemaliger-Benutzer sagte in If Anweisung wird übersprungen:

@hustbaer sagte in If Anweisung wird übersprungen:

Und auf Dinge zu antworten die du nicht bzw. nicht ausreichend verstanden hast.

das sowas in einem öffentlichen diskussionsforum ein problem sein kann, hätte ich zuvor nicht für möglich gehalten.

Klappe halten wenn man keine Ahnung hat - insofern konsequent, dass dieser Ahnungslose hier nicht weiter mit sinnfreien Aussagen die Beiträge zumüllt.

[hustbaer]

@Ein-ehemaliger-Benutzer sagte in If Anweisung wird übersprungen:

@hustbaer sagte in If Anweisung wird übersprungen:

Und auf Dinge zu antworten die du nicht bzw. nicht ausreichend verstanden hast.

das sowas in einem öffentlichen diskussionsforum ein problem sein kann, hätte ich zuvor nicht für möglich gehalten.

Wenn man so wie du den Unfug als Aussage formuliert ohne diese weiter zu qualifizieren, dann ist das ein Problem, ja.

[Wutz]

@hustbaer
Der o.g. Herr ist von Prekariatsforen - genannt SocialMedia - verwöhnt, wo im Gegensatz zu moderierten Fachforen jeder seinen Schwachsinn ablassen kann und Klicks/Likes von Leuten mit negativem IQ gleichrangig zu denen von aufgeklärten Leuten behandelt werden.