Minimum
-
Nachdem ich hier jede Menge Zeugs über STL gelesen habe und beim Überfliegen etwas mitbekommen habe von Anfänger und 3000 Werten, sei die Frage erlaubt, ob 6 Seiten STL-Fachsimpelei Dir irgendetwas bei Deinem Problem geholfen haben?
Falls nicht - und das befürchte ich, schließlich scheint das Problem noch nicht gelöst zu sein - so lass uns mal an den Anfang zurückgehen und Dich einfach fragen, wie Du die Daten vorliegen hast.
becks21 schrieb:
Ich hab mehrere Werte und ich muss das Minimum der Werte herausfinden, gibt's da eine Funktion oder muss ich das selbst programmieren?
Klingt für mich erstmal nach einem Dreizeiler, ganz ohne dass Du erstmal Templates und STL lernen musst. Die eigentliche Frage ist nämlich nur, wie die Daten eigentlich vorliegen, dass Du sie vergleichen kannst.
Der Vergleich ist schließlich nurMinimum = Wert[0]; for( int i = 0; x < AnzahlWerte; x++ ) if( Wert[x] < Minimum ) Minimum = Wert[x];In dem Sinne programmiere es selbst, es wird vermutlich kürzer, weniger aufwendig und schneller sein, als jegliche STL-Lösung.
Klar kann man das in eine Funktion packen, aber ob es das wirklich wert ist, dafür die STL zu bemühen?Falls Du Fragen hast, lass mich doch bitte wissen, wie die Daten vorliegen, ob Du sie bereits in einem Array im Computer zur Verfügung hast oder erst einlesen musst... beschreibe Dein Problem einfach genauer. Der "Algorithmus", wenn man das überhaupt so nennen darf, steht da. Die Frage ist nun nur noch, wie Du drauf zugreifst ("Wert[x]") und wie Du für Deine Werte Kleiner ("<") definierest.
Wenn ich damit richtig liege, so mögen sich die STL-Vertreter kurz überlegen, ob die beste Lösung im Sinne der C++ Softwaretechnik auch die beste Lösung für das zu lösende Problem sei. Ich habe das Gefühl, dass die STL-Kanonen hier sehr unangebracht sind, um diesen Spatzen zu erlegen.
STL != 42!
-
Xin schrieb:
Nachdem ich hier jede Menge Zeugs über STL gelesen habe und beim Überfliegen etwas mitbekommen habe von Anfänger und 3000 Werten, sei die Frage erlaubt, ob 6 Seiten STL-Fachsimpelei Dir irgendetwas bei Deinem Problem geholfen haben?
Ja, daß Du nur überflogen hast merkt man Deinem Posting deutlich an.
In dem Sinne programmiere es selbst, es wird vermutlich kürzer, weniger aufwendig und schneller sein, als jegliche STL-Lösung.
Okay, mal vergleichen. Schneller als std::min_element? Ne, das macht ja das Gleiche. Kürzer? Ne, std::min_element ist kürzer. Aufwendiger... naja, std::min_element ist sogar weniger zu tippen.
std::min_element vs superschnelle_einfache_schleife: 3 : 0
Aber letzlich ging es im Rest des Threads auch darum nicht. Fall Dich interessiert worum es stattdessen ging kannste ja einfach mal nachlesen.
-
Jester schrieb:
Okay, mal vergleichen. Schneller als std::min_element? Ne, das macht ja das Gleiche. Kürzer? Ne, std::min_element ist kürzer. Aufwendiger... naja, std::min_element ist sogar weniger zu tippen.
std::min_element vs superschnelle_einfache_schleife: 3 : 0
<nitpick>2,5 : 0,5. "macht das Gleiche" ist wohl kaum ein voller Punkt fuer eine der beiden Seiten</nitpick> *duckundweg*
-
btw - werden die werte von irgendwo eingelesen? dann ist es evtl schlauer eine variable mitzuführen, die das aktuelle minimum enthält, anstatt sich zig seiten um irgendwelche sinnfrei verwendeten algos zu streiten
-
becks21 schrieb:
Den Vektor kann ich ja auch einfach mehrdimensional machen? Oder spricht was dagegen?
Können kannst DU schon, dann hast Du einfach soviele Suchanfragen wie Dimensionen.
Nun sag doch mal was Du vorhast.
Woher kommen die Werte?
Willst Du das Minimum jeder Serie oder das aller Serien?
Brauchst Du die Werte nachher noch oder brauchst Du nur das Minimum?
-
Jester schrieb:
Xin schrieb:
Nachdem ich hier jede Menge Zeugs über STL gelesen habe und beim Überfliegen etwas mitbekommen habe von Anfänger und 3000 Werten, sei die Frage erlaubt, ob 6 Seiten STL-Fachsimpelei Dir irgendetwas bei Deinem Problem geholfen haben?
Ja, daß Du nur überflogen hast merkt man Deinem Posting deutlich an.
Ich las die Fragestellung und was danach kam, sieht mir eher nach deutlichen STL-Verliebtheit, als einer sinnvollen Problemlösung aus. Ich denke, dass liest sich auch quer da wunderbar raus.
Jester schrieb:
In dem Sinne programmiere es selbst, es wird vermutlich kürzer, weniger aufwendig und schneller sein, als jegliche STL-Lösung.
Okay, mal vergleichen. Schneller als std::min_element? Ne, das macht ja das Gleiche. Kürzer? Ne, std::min_element ist kürzer. Aufwendiger... naja, std::min_element ist sogar weniger zu tippen.
std::min_element vs superschnelle_einfache_schleife: 3 : 0
Das beurteilst Du so? Okay, damit kann ich gut leben und mir gedanklich eine kleine Notiz für unter 'Jester' anlegen, irgendwie scheint mir da sowieso schonwas aus früheren Threads zu klingeln... Aber deklariere derartiges doch bitte als Deine persönliche Meinung, denn mehr stellt es nicht dar.
Abgesehen davon, kann es nicht schaden, wenn sich nach 7 Seiten mal jemand um das eigentliche Problem bemüht.
Schön, dass Deine Reaktion derart freundlich formuliert ist, nur weil mein Ansatz ein anderer ist als der von Dir bevorzugte.Aus der Anfrage las ich nämlich nicht, dass die Daten entsprechend eines STL-Templates iterierbar sind. Wenn er das zusätzlich noch entwickeln muss, dann bröckelt Deine kompetente Argumentation angefangen von 'weniger zu tippen' von hinten weg.
Für den Fall, dass er tatsächlich Anfänger ist, könnte die STL-Lösung ihn damit vollends überfordern und außer seine Zeit zu verschwenden keinen weiteren Nutzen bringen.Jester schrieb:
Aber letzlich ging es im Rest des Threads auch darum nicht. Fall Dich interessiert worum es stattdessen ging kannste ja einfach mal nachlesen.
Worum es in diesem Thread geht, steht in der Regel im ersten Posting. Um das Minimum diverser Werte. Wie mir scheint, scheint das bisher kaum beachtet worden zu sein.
r0nny schrieb:
btw - werden die werte von irgendwo eingelesen? dann ist es evtl schlauer eine variable mitzuführen, die das aktuelle minimum enthält, anstatt sich zig seiten um irgendwelche sinnfrei verwendeten algos zu streiten
Das stellt für mich ein gutes Beispiel einer sinnvollen, möglichen Problemlösung dar - daher meine Frage, wie die Daten überhaupt vorliegen.
-
Xin schrieb:
Ich las die Fragestellung und was danach kam, sieht mir eher nach deutlichen STL-Verliebtheit, als einer sinnvollen Problemlösung aus. Ich denke, dass liest sich auch quer da wunderbar raus.
Haha, und das von jemandem der so
for-verliebt ist wie du? Du hättest auch ganz einfachif&gotoverwenden können...(Die STL ist Teil des C++-Standards. Jemandem der darauf hinweist dass es in der Standardbibliothek einen dem Problem angemessenen Algorithmus gibt STL-Verliebtheit vorzuwerfen ist äußerst lächerlich.)
Xin schrieb:
In dem Sinne programmiere es selbst, es wird vermutlich kürzer, weniger aufwendig und schneller sein, als jegliche STL-Lösung.
Okay, mal vergleichen. Schneller als std::min_element? Ne, das macht ja das Gleiche. Kürzer? Ne, std::min_element ist kürzer. Aufwendiger... naja, std::min_element ist sogar weniger zu tippen.
std::min_element vs superschnelle_einfache_schleife: 3 : 0
Das beurteilst Du so? Okay, damit kann ich gut leben und mir gedanklich eine kleine Notiz für unter 'Jester' anlegen, irgendwie scheint mir da sowieso schonwas aus früheren Threads zu klingeln...[/quote]
Es wäre weniger albern wenn du statt dieser ominösen Andeutung + Pseudodrohung einfach auf sein Argument eingehen würdest.
Xin schrieb:
Aber deklariere derartiges doch bitte als Deine persönliche Meinung, denn mehr stellt es nicht dar.
Ich sehe nicht dass du deine Meinung als solche deklariert hast. (Und wozu auch, das ist in aller Regel nicht nötig, der Unterschied zwischen "1+1=2" und "mir gefällt die 3" ist offensichtlich.)
Nicht zu vergessen dass nicht alle Meinungen gleich viel Wert sind.
Xin schrieb:
Abgesehen davon, kann es nicht schaden, wenn sich nach 7 Seiten mal jemand um das eigentliche Problem bemüht.
Schön, dass Deine Reaktion derart freundlich formuliert ist, nur weil mein Ansatz ein anderer ist als der von Dir bevorzugte.
Xin schrieb:
Aus der Anfrage las ich nämlich nicht, dass die Daten entsprechend eines STL-Templates iterierbar sind. Wenn er das zusätzlich noch entwickeln muss, dann bröckelt Deine kompetente Argumentation angefangen von 'weniger zu tippen' von hinten weg.
Ähm, LOL?
Xin schrieb:
Für den Fall, dass er tatsächlich Anfänger ist, könnte die STL-Lösung ihn damit vollends überfordern und außer seine Zeit zu verschwenden keinen weiteren Nutzen bringen.
Es geht hier nicht um hochgradig obskure Metaprogrammierung sondern schlicht um simples Standard C++. Kann es sein dass du dich damit einfach selber nicht auskennst und deswegen dagegen sträubst?
Xin schrieb:
Jester schrieb:
Aber letzlich ging es im Rest des Threads auch darum nicht. Fall Dich interessiert worum es stattdessen ging kannste ja einfach mal nachlesen.
Worum es in diesem Thread geht, steht in der Regel im ersten Posting. Um das Minimum diverser Werte. Wie mir scheint, scheint das bisher kaum beachtet worden zu sein.
Folgt man deiner Argumentation dürfte kein Thread aus mehr als 2 Beiträgen bestehen, redundante Postings die sich dem OP anschließen ausgenommen.
Xin schrieb:
r0nny schrieb:
btw - werden die werte von irgendwo eingelesen? dann ist es evtl schlauer eine variable mitzuführen, die das aktuelle minimum enthält, anstatt sich zig seiten um irgendwelche sinnfrei verwendeten algos zu streiten
Das stellt für mich ein gutes Beispiel einer sinnvollen, möglichen Problemlösung dar - daher meine Frage, wie die Daten überhaupt vorliegen.
Hättest du den Thread gelesen wäre dir klar dass dieser Punkt auch schon angesprochen wurde.
-
Hallo finix.
Erstaunlich, dass Du mir eine for-Verliebtheit nach einer einzigen for-Schleife unterstellst... ich muss Dich enttäuschen, im Schnitt bin ich eher im while-Wahn denn for-verliebt.
Um Dein Weltbild jedoch nicht ganz zu zerstören: ich gehöre tatsächlich zu den Leuten, die in goto eine sinnvolle C/C++ Anweisung sehen. Vielleicht nicht in dem von Dir genannten Zusammenhang, aber dennoch der Mehrheit der C/C++-Gläubigen zum Widerspruch.
finix schrieb:
Xin schrieb:
Für den Fall, dass er tatsächlich Anfänger ist, könnte die STL-Lösung ihn damit vollends überfordern und außer seine Zeit zu verschwenden keinen weiteren Nutzen bringen.
Es geht hier nicht um hochgradig obskure Metaprogrammierung sondern schlicht um simples Standard C++. Kann es sein dass du dich damit einfach selber nicht auskennst und deswegen dagegen sträubst?
Wer sich bemüht, eine Frage zu tippen, die hoffentlich auch für Dich aufwendiger ist, als eine Minimumfunktion zu implementieren, lernt C++ vermutlich zur Zeit. Das heißt, es ist kein Standard C++ vorhanden. In dem Fall liegt die Definition von 'simples Standard C++' sicherlich anders, als es vielleicht Deine Vorstellung ist.
Ich meine, dass es durchaus sinnvoll ist, den Wissenstand des Fragenden zu berücksichtigen, damit er die Problemlösung auch umsetzen kann. Meinst Du nicht?
Weiterhin meine ich, dass es immernoch weniger aufwendig ist, eine Minimum-Funktion zu schreiben, als für nicht STL-iterierbare Werte einen Iterator.
Der notwendige Aufwand ist meiner Meinung nach ebenfalls beachtenswert oder meinst Du nicht?finix schrieb:
Xin schrieb:
Worum es in diesem Thread geht, steht in der Regel im ersten Posting. Um das Minimum diverser Werte. Wie mir scheint, scheint das bisher kaum beachtet worden zu sein.
Folgt man deiner Argumentation dürfte kein Thread aus mehr als 2 Beiträgen bestehen, redundante Postings die sich dem OP anschließen ausgenommen.
Meine Argumentation ist, dem Fragenden erst zu helfen und sich danach bei Bedarf dann an der STL aufzugeilen.
Bisher sehe ich jedenfalls nicht, ob der Fragende sein Problem gelöst hat.
Darum geht es doch in diesem Forum und in diesem Thread, dachte ich!?
Vielleicht gibt es da auch gleichwertige andere Meinungen und ich muss meine mal überdenken.
-
Xin schrieb:
Erstaunlich, dass Du mir eine for-Verliebtheit nach einer einzigen for-Schleife unterstellst... ich muss Dich enttäuschen, im Schnitt bin ich eher im while-Wahn denn for-verliebt.
Um Dein Weltbild jedoch nicht ganz zu zerstören: ich gehöre tatsächlich zu den Leuten, die in goto eine sinnvolle C/C++ Anweisung sehen. Vielleicht nicht in dem von Dir genannten Zusammenhang, aber dennoch der Mehrheit der C/C++-Gläubigen zum Widerspruch.
Erstaunlich dass du anderen STL-Verliebtheit vorwirfst nach einem einzigen Algorithmus....
Weniger erstaunlich dass du komplett am Punkt vorbei geantwortet hast.Die Unterstellung im zweiten Absatz entbehrt nicht nur jeglicher Grundlage, sondern hat noch weniger Bezug zum eigentlichen Punkt.
Xin schrieb:
Wer sich bemüht, eine Frage zu tippen, die hoffentlich auch für Dich aufwendiger ist, als eine Minimumfunktion zu implementieren, lernt C++ vermutlich zur Zeit. Das heißt, es ist kein Standard C++ vorhanden. In dem Fall liegt die Definition von 'simples Standard C++' sicherlich anders, als es vielleicht Deine Vorstellung ist.
Sorry, kompletter Semantik-Crash. Kannst du das nochmal neu formulieren?
Xin schrieb:
Ich meine, dass es durchaus sinnvoll ist, den Wissenstand des Fragenden zu berücksichtigen, damit er die Problemlösung auch umsetzen kann. Meinst Du nicht?
Ja, das ist genau mein Punkt. Standard-Container & -Algorithmen sind keine Atomphysik, daher ist
Wissensstand |= generische Standardlösungdurchaus erstrebenswert.Xin schrieb:
Weiterhin meine ich, dass es immernoch weniger aufwendig ist, eine Minimum-Funktion zu schreiben, als für nicht STL-iterierbare Werte einen Iterator.
Der notwendige Aufwand ist meiner Meinung nach ebenfalls beachtenswert oder meinst Du nicht?Hm. Sollte das nicht der Fall sein liegt aller Wahrscheinlichkeit nach ein Designfehler vor, der behoben werden sollte.
Vor allem geht dein Code geht vom Vorhandensein einesop[]aus, was eine wesentlich größere Einschränkung darstellt.Xin schrieb:
Meine Argumentation ist, dem Fragenden erst zu helfen und sich danach bei Bedarf dann an der STL aufzugeilen.
Du magst die Standardbibliothek nicht, was? Aber dein Argument kann man genauso gut (und wesentlich sinnvoller, IMAO) umdrehen: man sollte dem Fragenden zunächst die angemessene Lösung anbieten und sich dann erst, auf ausdrücklichen Wunsch, an NIH-Konstrukten aufgeilen.
Xin schrieb:
Bisher sehe ich jedenfalls nicht, ob der Fragende sein Problem gelöst hat.
Darum geht es doch in diesem Forum und in diesem Thread, dachte ich!?
Vielleicht gibt es da auch gleichwertige andere Meinungen und ich muss meine mal überdenken.Dass der OP sich nicht zum Stand seines Problems geäußert hat legt eher die Vermutung nahe dass er es bereits lösen konnte.
Und vielleicht solltest du dich mit dem Gedanken anfreunden dass es ggf nicht nur gleichwertige sondern auch höherwertige Meinungen neben deiner gibt.
-
Hallo finix... :-\
finix schrieb:
Xin schrieb:
Wer sich bemüht, eine Frage zu tippen, die hoffentlich auch für Dich aufwendiger ist, als eine Minimumfunktion zu implementieren, lernt C++ vermutlich zur Zeit. Das heißt, es ist kein Standard C++ vorhanden. In dem Fall liegt die Definition von 'simples Standard C++' sicherlich anders, als es vielleicht Deine Vorstellung ist.
Sorry, kompletter Semantik-Crash. Kannst du das nochmal neu formulieren?
Sollte Dein Deutsch-Parser hier Fehler werfen, wird es Zeit für ein Update. Ein Stack-Overflow ist bei den paar Worten jedenfalls definitiv ein Bug.
Aus Benutzersicht scheint es mir klüger zu sein, mich zukünftig anderen Interpretern zuzuwenden.
finix schrieb:
Standard-Container & -Algorithmen sind keine Atomphysik, daher ist Wissensstand |= generische Standardlösung durchaus erstrebenswert.
Hier stimme ich mit Dir überein. Sollte Dein Parser jedoch die Semantik des Ursprungsposting korrekt wiedergeben können, so wirst Du feststellen, dass er nicht gefragt hat, was er zukünftig lernen soll, sondern wie er jetzt ein spezielles Problem lösen soll. Hier ist eine zeitliche Komponente gegeben, die u.U. der Verwendung der STL widerspricht.
finix schrieb:
Xin schrieb:
Weiterhin meine ich, dass es immernoch weniger aufwendig ist, eine Minimum-Funktion zu schreiben, als für nicht STL-iterierbare Werte einen Iterator.
Der notwendige Aufwand ist meiner Meinung nach ebenfalls beachtenswert oder meinst Du nicht?Hm. Sollte das nicht der Fall sein liegt aller Wahrscheinlichkeit nach ein Designfehler vor, der behoben werden sollte.
Es ist nicht automatisch ein Designfehler, wenn man nicht die STL verwendet.
Vorsichtshalber der Hinweis für Deinen semantikcrashgeprüften Deutsch-Parser: (!Designfehler && !STL) != (Designfehler && STL)
finix schrieb:
Vor allem geht dein Code geht vom Vorhandensein eines
op[]aus, was eine wesentlich größere Einschränkung darstellt.Du möchtest mir jetzt nicht andeuten, dass Du nicht in der Lage bist, die Semantik eines Codes zu lesen, sondern ausschließlich die Syntax zu prüfen?
Hmm... ich möchte dazu anfügen, dass ich die Frage eigentlich ernst meinte, als ich sie schrieb. Mir ging erst beim Kontrolllesen auf, dass sie doch rhetorischer Natur zu sein scheint.
Xin schrieb:
Du magst die Standardbibliothek nicht, was?
False. Weiterhin kannst Du diese Frage wegoptimieren, denn sie wird grundlose gestellt.
Ich sehe beim Programmieren auch Fragen, auf die die STL nicht die richtige Antwort ist.
Xin schrieb:
Und vielleicht solltest du dich mit dem Gedanken anfreunden dass es ggf nicht nur gleichwertige sondern auch höherwertige Meinungen neben deiner gibt.
Meinst Du, Dein Deutschparser kann das Attribut 'arrogant' parsen und semantisch mit Deiner Instanz verknüpfen?
Meiner bescheidenen Meinung nach, ist der Quelltext mit Deinem Namen jedenfalls hier am Ende. Weiterführende Textzeilen erscheinen meinem Parser als Kommentar.
Schönen Abend noch.
-
Xin schrieb:
Hallo finix... :-\
Hallo Xin!
Ich spar's mir einfach mal deinen Post auseinander zu nehmen.
Aber lass dir gesagt sein dass deine generelle Einstellung nicht falsch liegen zu können wesentlich arroganter erscheint als meine nicht immer allzu verblümter Ausdrucksweise. IMAO, natürlich.
Wenn du wenigstens für deinen Standpunkt argumentieren könntest...
p.s. Colorless green ideas sleep furiously
-
@Xin: Bitte lies doch den Thread einfach. Oder laß es. Dann behaupte aber auch nicht Du hättest da irgendwas rausgelesen.
Du darfst hier natürlich gerne Deine Schleife präsentieren. Vielleicht solltest Du Dich aber nicht zu sehr drüber aufregen, wenn ich Deine Argumentation warum die so viel toller ist, zerlege.
Es kann natürlich durchaus sein, daß Du Dich da an frühere Threads erinnert fühlst. Kommt öfter vor, daß ich widerspreche wenn jemand Mist erzählt. Du hast übrigens keine Deiner Aussagen mit "Das aber nur meine Meinung" kenntlich gemacht. Warum muß ich das tun?
edit: Falls Du den Thread doch noch liest wirst Du bemerken, daß ich die ganze Zeit für entweder die Schleife oder std::min_element plädiert habe.
-
Jester schrieb:
@Xin: Du darfst hier natürlich gerne Deine Schleife präsentieren. Vielleicht solltest Du Dich aber nicht zu sehr drüber aufregen, wenn ich Deine Argumentation warum die so viel toller ist, zerlege.
edit: Falls Du den Thread doch noch liest wirst Du bemerken, daß ich die ganze Zeit für entweder die Schleife oder std::min_element plädiert habe.
Ich hab' ihn gelesen und auch tatsächlich den Satz gefunden, der auf eine Schleife deutet.
Wieso argumentierst Du gegen die Schleife, wenn Du zuvor noch dafür argumentiert hast?
Und seien wir ehrlich, wirklich argumentativ war diese 'Argumentation '3:0' nicht. Das war mehr 'Wir hauen mal mi'm Hammer drauf, dann ist hoffentlich Ruhe.'.Was ich in dem Thread quer gelesen habe, gab' mir einen guten Überblick. Verpasst hatte ich lediglich, dass die Daten über die Standardeingabe kommen.
Der Fragende ist Anfänger, ich weiß nicht, ob ihm der Stoß ins kalte STL-Wasser wirklich geholfen hat. Nach dem Thread sieht er den Wald vor lauter Bäumen nicht mehr.
Wenn er Pech hat, hätte er nur eine Schleife machen müssen und einfach immer vergleichen, ob die aktuelle Eingabe kleiner als die bisher kleinste Eingabe war?Jester schrieb:
Es kann natürlich durchaus sein, daß Du Dich da an frühere Threads erinnert fühlst. Kommt öfter vor, daß ich widerspreche wenn jemand Mist erzählt.
Oha, schwerer Seitenhieb. Netter Versuch.
Jester schrieb:
Du hast übrigens keine Deiner Aussagen mit "Das aber nur meine Meinung" kenntlich gemacht. Warum muß ich das tun?
Müssen muss keiner was. An manchen Stellen wär's ehrlicher, wahrer.
Ich bin immer wieder erstaunt, wieviele Wahrheiten in der Informatik rumgeistern, die nichts mehr als häufig genug zitierte Meinungen sind. Wenn man will kann man sie sogar beweisen, vieles steht im Informatik-Duden schwarz auf weiß. Und für verschiedene Ansichten braucht man sich sogar nur einen einzigen Duden zu kaufen.
Im Gegensatz zu finix Behauptung, halte ich meine Überzeugung für eine begründete Möglichkeit, aber nicht für die einzig machbare.
Wenn ich mir angucke, wie alt das Topic schon ist, spielt das aber vermutlich eh keine Rolle mehr.
-
Xin schrieb:
Wieso argumentierst Du gegen die Schleife, wenn Du zuvor noch dafür argumentiert hast?
Zum einen halte ich die stl-Lösung tatsächlich für besser. Zum anderen hat mich auch dieses "Nachdem jetzt hier keiner das vernünftig lösen konnte und alle nur Mist erzählt haben, zeigt euch der Onkel Xin jetzt mal, wie man's richtig macht"-Gelaber ein bißchen angenervt.
Und seien wir ehrlich, wirklich argumentativ war diese 'Argumentation '3:0' nicht. Das war mehr 'Wir hauen mal mi'm Hammer drauf, dann ist hoffentlich Ruhe.'.
Zumindest schneller und kürzer sind (auch objektiv gesehen) widerlegt. Über einfacher kann man sicherlich noch streiten. Aber hey, warum sollte ich 2:1 spielen, wenn Du mich vielleicht auch mit 3:0 davonkommen läßt.
Was ich in dem Thread quer gelesen habe, gab' mir einen guten Überblick. Verpasst hatte ich lediglich, dass die Daten über die Standardeingabe kommen.
Dann haste auch gesehen, daß es ca. 4 Seiten darum ging, daß es nicht das tollste ist dafür nen Baum zu implementieren?
Jester schrieb:
Es kann natürlich durchaus sein, daß Du Dich da an frühere Threads erinnert fühlst. Kommt öfter vor, daß ich widerspreche wenn jemand Mist erzählt.
Oha, schwerer Seitenhieb. Netter Versuch.
Okay, Du hast es bemerkt.
Wenn ich mir angucke, wie alt das Topic schon ist, spielt das aber vermutlich eh keine Rolle mehr.
Vermutlich nicht. Ich hoffe er hat min_element genommen. :p
-
Xin schrieb:
Im Gegensatz zu finix Behauptung, halte ich meine Überzeugung für eine begründete Möglichkeit, aber nicht für die einzig machbare.
Oh Mann, du bist echt ein Knaller. Eine ironischere falsche Behauptung hättest du wohl kaum mit Absicht hinbekommen.
-
Jester schrieb:
Zum einen halte ich die stl-Lösung tatsächlich für besser. Zum anderen hat mich auch dieses "Nachdem jetzt hier keiner das vernünftig lösen konnte und alle nur Mist erzählt haben, zeigt euch der Onkel Xin jetzt mal, wie man's richtig macht"-Gelaber ein bißchen angenervt.
Schön, wie Du den Onkel Xin so interpretierst... aber auch hier sei Meinungsfreiheit gegeben.
Jester schrieb:
Und seien wir ehrlich, wirklich argumentativ war diese 'Argumentation '3:0' nicht. Das war mehr 'Wir hauen mal mi'm Hammer drauf, dann ist hoffentlich Ruhe.'.
Zumindest schneller und kürzer sind (auch objektiv gesehen) widerlegt. Über einfacher kann man sicherlich noch streiten. Aber hey, warum sollte ich 2:1 spielen, wenn Du mich vielleicht auch mit 3:0 davonkommen läßt.
*lach* Ich sehe nix mit 2:1, aber wenn Du meinst...
Ich muss nicht als Gewinner aus einer Forums-Diskussion gehen... im Recht zu sein, reicht mir vollkommen.
Ich muss das aber nicht mehr aller Welt beweisen.Jester schrieb:
Was ich in dem Thread quer gelesen habe, gab' mir einen guten Überblick. Verpasst hatte ich lediglich, dass die Daten über die Standardeingabe kommen.
Dann haste auch gesehen, daß es ca. 4 Seiten darum ging, daß es nicht das tollste ist dafür nen Baum zu implementieren?
Die Katastrophe überhaupt... falls der Hammer mit der STL ihn nicht umhaut, schlagen wir mit der O-Notation und Bäumen nochmal hinterher. O( Baum ), genau das fehlt einem Anfänger, um das Problem des kleinsten Wertes zu lösen: erstmal herausfinden, was überhaupt eine O-Notation ist... Ich wartete die ganze Zeit darauf, dass sich eine große Diskussion über balancierte und unbalancierte Bäume ergibt. <kopfschüttel>
Jester schrieb:
Wenn ich mir angucke, wie alt das Topic schon ist, spielt das aber vermutlich eh keine Rolle mehr.
Vermutlich nicht. Ich hoffe er hat min_element genommen. :p
Ich hoffe, er konnte sein Problem rechtzeitig lösen.
-
Jester schrieb:
Zumindest schneller und kürzer sind (auch objektiv gesehen) widerlegt. Über einfacher kann man sicherlich noch streiten. Aber hey, warum sollte ich 2:1 spielen, wenn Du mich vielleicht auch mit 3:0 davonkommen läßt.
Naja, im Prinzip steht das 3:0. Wenn ich die Zeile
std::min_element(...)sehe weiß ich umgehend & automatisch was da passiert, im Gegensatz zu einer handgestrickten Schleife.
-
finix schrieb:
... Wenn ich die Zeile
std::min_element(...)sehe weiß ich umgehend & automatisch was da passiert, im Gegensatz zu einer handgestrickten Schleife.Ne for-schleife, die man mit einem Blick erfassen kann, sollte man als C++ Progger jedenfalls "auch" lesen können.
-
Für einen Anfänger der die STL noch nicht gut kennt ist die for Schleife super toll verständlich (wenns auch ein paar Sekunden dauert), die "min_element" Sache aber komplett unverständlich, bzw. kann er nie sicher sein "richtig geraten" zu haben, bis er nachgeguckt hat.
Dafür ist für einen "STL Kenner" die "min_element" Sache schneller verständlich, weils weniger zu lesen ist, und er sowieso im Schlaf weiss was "min_element" nun genau tut.
Im Prinzip machen beide Varianten dasselbe. Die Frage ist wohl eher wie man die Frage des OP interpretiert. Wenn er bloss wissen will wie man sowas programmiert, weil er überhaupt keine Lösung selbst hinbekommt, dann ist die for Schleife wohl die "richtige" Antwort. Wenn er weiss wie man es selbst ausprogrammiert, aber wissen möchte ob's nicht was "fertiges" gibt um genau so eine Schleife zu ersetzen dann ist "min_element" die "richtige" Antwort.
-
Xin schrieb:
Die Katastrophe überhaupt... falls der Hammer mit der STL ihn nicht umhaut, schlagen wir mit der O-Notation und Bäumen nochmal hinterher. O( Baum ), genau das fehlt einem Anfänger, um das Problem des kleinsten Wertes zu lösen: erstmal herausfinden, was überhaupt eine O-Notation ist... Ich wartete die ganze Zeit darauf, dass sich eine große Diskussion über balancierte und unbalancierte Bäume ergibt. <kopfschüttel>
Ach, das war nun auch falsch, das geklärt zu haben? Jo, macht ja den Thread länger, wenn wir klären, daß der Baum nicht toll ist, obwohl ihn jemand als toll vorgeschlagen hat. Werd ich mir merken. In Zukunft lieber Mist unkommentiert stehen lassen, und nicht den Thread länger machen!
Letztlich schreibe ich meine Beiträge aber auch nicht unbedingt nur für den OP. Es gibt schließlich noch mehr Leser. Wer damit nichts anfangen kann, der kann's ja überlesen. Wenn eine vernünftige Begründung einen Fachbegriff benötigt, dann benutze ich den auch. Überspring meine Beiträge also einfach, wenn Du mit Begriffen wie "O(.)" oder "Baum" nicht so fit bist.
Gegen "kürzer" und "nicht schneller" sehe ich vermutlich keine Argumente mehr von Dir. Wenn Du der Meinung bist, das stimmt nicht, dann sag doch was. Aber spiel hier nicht die beleidigte Leberwurst.
