Minimum

[Jester]

@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.

[Xin]

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.

[Jester]

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

[finix]

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.

[Xin]

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.

[finix]

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.

[konfus]

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.

[hustbaer]

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.

[Jester]

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.

[THX 1138]

hustbaer schrieb:

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.

becks21 schrieb:

Hallo!
Ich hab mehrere Werte und ich muss das Minimum der Werte herausfinden, gibt's da eine Funktion oder muss ich das selbst programmieren?

Ich denke, die Frage war klar: "Gibs da nich was fertiges?" Und diese Frage stellt man sich als Anfänger oft. Wenn man mal ne verkettete Liste gemacht hat, dann reicht das, und man möchte sich der nächsten Herausforderung stellen. Darum Probs an die, die ihre Erfahrung teilen.

Ich muss einfach mal zu dem ganzen Hickhack sagen, ich bin froh, dass hier immer mal wieder andere Lösungswege eingebracht werden. Auch wenn jetzt vielleicht die Bäume nicht so passen, der OP googelt später vielleicht mal nach, was dass denn ist und wo er das brauchen könnte.
Ich hab am Anfang alles mit Arrays und for Schleifchen gemacht, und erst durch die Antworten von Usern die STL Container, Iteratoren und Algorithmen kennen gelernt und auch verstanden, aber auch Funktionsobjekte, Templates und schliesslich auch ein paar Patterns. Und hey, danke! Das hats echt gebracht. Ich bin übers Stadium der Pascal Programmierung mit C Syntax hinaus gekommen.

Danke Forumianerinnen und Forumianer

[Xin]

Jester schrieb:

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.

Ich habe mich noch nicht auf eine Datenstruktur festgelegt, sondern gefragt, wie die Daten vorliegen.
"nicht schneller" kann kein Argument sein, weil überhaupt kein Vergleich möglich ist, bevor ich mich auf etwas festlege. Lege ich mich spontan auf ein Array fest, kannst Du wettern wie Du lustig bist, schneller als ein Array wirst Du jedenfalls nicht.
Also ist es auch noch nicht möglich mich mit "nicht schneller" zu widerlegen. Im Gegenteil, ich frage mich, warum jemand schon wettert, bevor ich einen fertigen Ansatz anbiete. Ist halt zu früh, um einfach nur dagegen zu sein.

Ein Argument "kürzer" sehe ich hier auch nur sehr bedingt, da eine derart simple for-Schleife eben zwei Zeilen mehr sind als std::min_element().

Wäre mein Ansatz komplett gewesen, so stelle ich mich gerne jeder Kritik, bei guten Argumenten lerne ich schließlich vielliecht selber noch etwas.

Die beleidigte Leberwurst finde ich nett. Ich bin wieder erstaunt, dass die eine Seite meint, ich akzeptiere keine Meinung neben meiner und die andere, dass ich beleidigt sein müsse, nur weil jemand meine Meinung nicht annehmen möchte.
Vielleicht liegt die Antwort in der Mitte?
Leute, die wie finix herumtrollen finden sich überall. Mein Fehler, dass ich ihn zu Beginn davon ausging, dass es ihm um Austausch ging. Aber sowas schockt nun wirklich nicht mehr.

Für mich ändert sich nichts, ich sehe weder ein ausreichend starkes Argument meine Meinung zu ändern - Argument wogegen auch, ich habe ja noch gar nichts fertiges angeboten - noch habe ich ein Problem damit, wenn jemand derartige Aufgaben mit der STL löst. Ich bin lediglich einen anderen Weg gegangen, der auch für jemanden nachzuvollziehen ist, der Templates noch nicht kennt. Das ist mein wichtiges Pro-Argument für die Schleife.
Jeder ist seines eigenen Quelltexts Schmidt und solange er das Problem adequat löst, ist es doch gut.

THX 1138 schrieb:

Ich hab am Anfang alles mit Arrays und for Schleifchen gemacht, und erst durch die Antworten von Usern die STL Container, Iteratoren und Algorithmen kennen gelernt und auch verstanden, aber auch Funktionsobjekte, Templates und schliesslich auch ein paar Patterns. Und hey, danke! Das hats echt gebracht. Ich bin übers Stadium der Pascal Programmierung mit C Syntax hinaus gekommen.

Du hast Arrays programmiert, Du hast gelernt, Du bist über C Syntax hinaus gekommen.

Du hast die Frage nicht gestellt.

[finix]

konfus schrieb:

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.

Natürlich. Aber es macht trotz allem einen Unterschied, selbst wenn er bei diesem Beispiel recht marginal und nahezu zu vernachlässigen ist.

Bei std::min_element weiß man sofort was geschieht, bei einer Schleife muss man sich den Code erst ansehen, verstehen, und wird ihn dann gedanklich sowieso zu einem logischen min_element -Block zusammenfalten.

Abgesehen davon dass selbstgestrickte Lösungen anfälliger für Bugs und Performanceprobleme sind. (Siehe z.B. Xins Beispiel.)

[finix]

Xin schrieb:

[...]
Also ist es auch noch nicht möglich mich mit "nicht schneller" zu widerlegen. Im Gegenteil, ich frage mich, warum jemand schon wettert, bevor ich einen fertigen Ansatz anbiete. Ist halt zu früh, um einfach nur dagegen zu sein.

Du schnallst es nicht, was? Es geht darum dass die Schleife nicht schneller ist.

Xin schrieb:

Ein Argument "kürzer" sehe ich hier auch nur sehr bedingt, da eine derart simple for-Schleife eben zwei Zeilen mehr sind als std::min_element().

Tz tz. Du bringst es wohl nicht über dich einfach mal zu sagen "ja, es ist kürzer", was?
Darüber hinaus geht es nicht nur um kürzer an sich, sondern vor allem verständlicher, das ist der eigentliche Punkt.

Und wie sieht's mit folgenden Argumenten für std::min_element aus:
flexibler
robuster

Xin schrieb:

Die beleidigte Leberwurst finde ich nett. Ich bin wieder erstaunt, dass die eine Seite meint, ich akzeptiere keine Meinung neben meiner und die andere, dass ich beleidigt sein müsse, nur weil jemand meine Meinung nicht annehmen möchte.
Vielleicht liegt die Antwort in der Mitte?

Vielleicht liegt die Antwort nicht in der Mitte, sondern vielleicht liegst du auch ganz einfach falsch?

Niemand sagt dass die Schleife unpraktikabel, 'evil' oder sonstwas ist, aber gegenüber std::min_element ist sie ganz einfach die schlechtere Wahl.

Xin schrieb:

Leute, die wie finix herumtrollen finden sich überall. Mein Fehler, dass ich ihn zu Beginn davon ausging, dass es ihm um Austausch ging. Aber sowas schockt nun wirklich nicht mehr.

Fuck you, too

[Checker*amp*Murckser]

Edit:
sorry hab nen überflüssigen Beitrag gemacht ...

[Xin]

(-:

finix schrieb:

Abgesehen davon dass selbstgestrickte Lösungen anfälliger für Bugs und Performanceprobleme sind. (Siehe z.B. Xins Beispiel.)

Ich konnte bisher keinen Fehler in meinem Dreizeiler finden.

Ich bin auch überzeugt, dass die meisten Dreizeiler, die ich formuliere, korrekt ablaufen. Da können natürlich subjektiv unterschiedliche Erfahrungswerte vorliegen.

finix schrieb:

Xin schrieb:

Also ist es auch noch nicht möglich mich mit "nicht schneller" zu widerlegen. Im Gegenteil, ich frage mich, warum jemand schon wettert, bevor ich einen fertigen Ansatz anbiete. Ist halt zu früh, um einfach nur dagegen zu sein.

Du schnallst es nicht, was? Es geht darum dass die Schleife nicht schneller ist.

Yepp, der Fettdruck hat mich überzeugt. Zusammenhanglos, aber warum soll ich mich nicht einfach mal überzeugen lassen von jemand, der einfach mal dagegen ist.

finix schrieb:

Tz tz. Du bringst es wohl nicht über dich einfach mal zu sagen "ja, es ist kürzer", was?

"Ja, es ist kürzer" (zwei Zeilen), wenn man für seine Daten keinen zusätzlichen Iterator programmieren muss. Ist alles schon gesagt worden.

finix schrieb:

Darüber hinaus geht es nicht nur um kürzer an sich, sondern vor allem verständlicher, das ist der eigentliche Punkt.

Nicht für jemanden, der seine ersten Schritte in C++ unternimmt und noch nicht weiß, was Templates sind. Ist auch schon alles gesagt worden.

finix schrieb:

Und wie sieht's mit folgenden Argumenten für std::min_element aus:

flexibler

Bis ich eine zusätzliche Bedingung benötige. Die Schleife genauso flexibel, wie die Funktion, die die Schleife enthält. Allerdings verzichtet sie auf den Umweg über virtuelle Funktionen.

finix schrieb:

robuster

Wer sich bei diesem Dreizeiler bereits Gedanken machen muss, ob er das korrekt implementiert bekommt... der hat auf jeden Fall recht, wenn er std::min_element() verwendet.

finix schrieb:

Vielleicht liegt die Antwort nicht in der Mitte, sondern vielleicht liegst du auch ganz einfach falsch?

Vielleicht. Vielleicht auch nicht. Wir zwei, wir werden es wohl nie herausfinden.

finix schrieb:

Fuck you, too

Ist auch schon alles gesagt worden.

Wie sieht's aus... wollen wir noch eine Runde?

[Jester]

Xin schrieb:

"nicht schneller" kann kein Argument sein, weil überhaupt kein Vergleich möglich ist, bevor ich mich auf etwas festlege. Lege ich mich spontan auf ein Array fest, kannst Du wettern wie Du lustig bist, schneller als ein Array wirst Du jedenfalls nicht.
Also ist es auch noch nicht möglich mich mit "nicht schneller" zu widerlegen. Im Gegenteil, ich frage mich, warum jemand schon wettert, bevor ich einen fertigen Ansatz anbiete. Ist halt zu früh, um einfach nur dagegen zu sein.

Moment mal. Du hast gesagt: "Es ist schneller." Ich habe begründet, warum das falsch ist. Es ist nicht schneller. Nochmal anders: min_element ist mindestens genauso schnell. Von "min_element ist schneller" war hier nicht die Rede. Zur Erinnerung, die Begründung war: Da steht letztlich nur die Schleife drin. Ich denke schon, daß man das daher vergleichen kann. Dabei ist es wurscht, welche Datenstruktur tatsächlich drunter liegt. Sei es ein Array oder eine Liste.

[otze]

Xin schrieb:

finix schrieb:

Tz tz. Du bringst es wohl nicht über dich einfach mal zu sagen "ja, es ist kürzer", was?

"Ja, es ist kürzer" (zwei Zeilen), wenn man für seine Daten keinen zusätzlichen Iterator programmieren muss. Ist alles schon gesagt worden.

ich überleg grad, wann ich das letzte mal an ne situation kam, bei der ich nen iterator selber schreiben musste, ohne vorher nen kompletten container geschrieben zu haben...

eigentlich nie.

finix schrieb:

Darüber hinaus geht es nicht nur um kürzer an sich, sondern vor allem verständlicher, das ist der eigentliche Punkt.

Nicht für jemanden, der seine ersten Schritte in C++ unternimmt und noch nicht weiß, was Templates sind. Ist auch schon alles gesagt worden.

mit templates kommt man hier aber auch nicht direkt in berührung. Ich muss ja nicht wissen, was templates sind, genauso, wie ich nicht wissen muss, wie cin oder cout funktionieren. Und was "using namespace std;" bedeuted, lernen die meisten auch erst lange nach ihrem ersten "hello world" programm. Von daher zeiht das Argument hier recht wenig.

Was man aber wissen muss ist, wie man die stl benutzt. Wenn ich sehe, dass so ziemlich alle Anfänger irgendwann eine liste zusammenbasteln die sie nichtmal im ansatz verstehen, krieg ich die Krise. Genauso sieht es mit den Algorithmen aus. Anstatt std::sort zu nutzen, hacken sie sich nen verbugten bubble sort zusammen, und wundern sich, dass es dann nicht funktioniert(steht ja genauso da, wie im lehrbuch).
Das ganze weckt dann bei einem Anfänger auch nur den frust bei der Sprache, und ist absolut kontraproduktiv. Besser wäre es deshalb, von Anfang an die STL zu nutzen. Erstens stellen sich damit die ersten erfolge schneller ein, und zweitens übt man sich in der benutzung dieser bibliothek, die einen dann doch irgendwann bis zum rest des "c++ programmierer" daseins begleiten wird.

Später lernt man eh diese ganzen kleinigkeiten, ne liste kann man immernoch implementieren, wenn man sicher mit den grundmitteln der sprache ist. Zeit genug hat man ja

finix schrieb:

Und wie sieht's mit folgenden Argumenten für std::min_element aus:

flexibler

Bis ich eine zusätzliche Bedingung benötige. Die Schleife genauso flexibel, wie die Funktion, die die Schleife enthält. Allerdings verzichtet sie auf den Umweg über virtuelle Funktionen.

Das mit den virtuellen funktionen solltest du näher erläutern. Klingt sehr neu und spannend für mich.

finix schrieb:

robuster

Wer sich bei diesem Dreizeiler bereits Gedanken machen muss, ob er das korrekt implementiert bekommt... der hat auf jeden Fall recht, wenn er std::min_element() verwendet.

du weist wohl nicht, was robust bedeuted ;). Die Beispielschleife von dir auf Seite 7 ist zb nichtmal ansatzweise robust. Mach ich im zuge der entwicklung aus dem Array eine Liste, ist das ergebnis höchst suboptimal.

[finix]

Xin schrieb:

(-:

finix schrieb:

Abgesehen davon dass selbstgestrickte Lösungen anfälliger für Bugs und Performanceprobleme sind. (Siehe z.B. Xins Beispiel.)

Ich konnte bisher keinen Fehler in meinem Dreizeiler finden.

Ich bin auch überzeugt, dass die meisten Dreizeiler, die ich formuliere, korrekt ablaufen. Da können natürlich subjektiv unterschiedliche Erfahrungswerte vorliegen.

Deine Schleife startet mit dem ersten Element, was komplett unnötig ist.
Wenn du also schon diesen Dreizeiler nicht anständig hinbekommst, wie wird es dann mit komplexeren DIY-Lösungen aussehen?

Xin schrieb:

finix schrieb:

Xin schrieb:

Also ist es auch noch nicht möglich mich mit "nicht schneller" zu widerlegen. Im Gegenteil, ich frage mich, warum jemand schon wettert, bevor ich einen fertigen Ansatz anbiete. Ist halt zu früh, um einfach nur dagegen zu sein.

Du schnallst es nicht, was? Es geht darum dass die Schleife nicht schneller ist.

Yepp, der Fettdruck hat mich überzeugt. Zusammenhanglos, aber warum soll ich mich nicht einfach mal überzeugen lassen von jemand, der einfach mal dagegen ist.

finix schrieb:

Tz tz. Du bringst es wohl nicht über dich einfach mal zu sagen "ja, es ist kürzer", was?

"Ja, es ist kürzer" (zwei Zeilen), wenn man für seine Daten keinen zusätzlichen Iterator programmieren muss. Ist alles schon gesagt worden.

Oh Mann. Es war schlicht die Erklärung was mit "nicht schneller" gemeint war.
Aber das "Zusammenhangslos" aus deiner Feder ist echt urkomisch

Bezüglich " std::min_element langsamer und/oder aufwändiger": zeig doch mal ein konkretes Beispiel in dem das tatsächlich der Fall ist!

Xin schrieb:

Bis ich eine zusätzliche Bedingung benötige. Die Schleife genauso flexibel, wie die Funktion, die die Schleife enthält. Allerdings verzichtet sie auf den Umweg über virtuelle Funktionen.

Schieß dir nicht selber ins Knie. std::min_element(foo.begin(), foo.end(), pred_bar); ist immer noch sehr deutlich, bei der Schleife wird's da schon komplizierter. Darüber hinaus ist die Minimumsuche in Teilbereichen einfach und übersichtlich, und die einzige Anforderung an den Container sind Forward-Iteratoren.

Xin schrieb:

finix schrieb:

Fuck you, too

Ist auch schon alles gesagt worden.

Wie sieht's aus... wollen wir noch eine Runde?

Heh. Kennst du "Die Ritter der Kokusnuss"?

[lemonhead]

Oh man das is ja lustich hier. Soll ich da meinen Senf auch noch zu abgeben? Ja gut dann mach ich mal. Als neues Member muss ich mich ja an diesem Kräftemessen beteiligen.

Wenn ich die Daten alle nacheinander einlese, kann ich auch gleichzeitig schon feststellen was das Minimum ist. Was ich weiter mache, ist dann wohl egal.

Wenn ich die Daten nachher noch brauche, dann werde ich sie eh irgendwo speichern wollen. In den meisten Fällen ist es am besten, einfach einen STL container zu benutzen. Wir nehmen mal an es sollen double-Werte gespeichert werden.

Welchen stl/eigenbau container ich verwende, das hängt davon ab was ich später machen will mit meinen Daten.
- Wenn ich vorher die Anzahl der Eingabewerte schon kenne, dann kann ich einfach einen simplen array verwenden. Damit bin ich insgesamt aber weniger flexibel, und es verleitet dazu zuviel selber herum zu basteln.
- Am besten ist meistens ein std::vector<double>. Da kann man hinten neue Werte einfügen, und die Arraygröße passt sich automatisch an.
- Bei std::list<double> kann man auch zwischendrin Elemente einfügen, und vor allem einzelne Elemente löschen. Sie kostet aber im allgemeinen mehr Speicher als ein Array, und ist etwas schwerfälliger.
- In seltenen Fällen kann hier auch ein sortierter Baum sinnvoll sein. Nämlich dann, wenn man zwischendurch Elemente einfügen und entfernen will, und die ganze Zeit die Sortierung vom kleinsten bis zum größten Element behalten. In der STL heißt das Ding multiset<double>. Wobei ich jetzt nicht so genau weiß wie das multiset von innen aussieht (aber etwas anderes als ein Baum wird es wohl nicht sein).
- Es gibt noch weitere Möglichkeiten (zB map), aber das reicht jetzt mal.

Wenn ich nun all meine Werte in einem solchen container abgelegt habe (was wirklich zu empfehlen ist), dann kann ich auf verschiedene Weise das Minimum heraussuchen. Gehen wir mal davon aus, die Daten stehen in einem Array, vector<double> oder list<double>.
- das minimum finden wir, indem wir den container von Anfang bis Ende durchlaufen und die Elemente mit dem bisher gefundenen Minimum vergleichen. Genau das macht Xin mit seiner for-Schleife, und ist damit average-case-zeitoptimal, und zwar nicht nur asymptotisch. Natürlich muss man bei list<vector> mit einem iterator arbeiten. So hat Xin das gemeint.
- Dasselbe macht aber auch das min_element() aus der stl. Es läuft innendrin genau dasselbe ab, ist aber tatsächlich einfacher zu lesen.
- Bei einfachen double-Werten benutzen wir den Standard-"<"-Operator. Die Funktion min_element macht das automatisch.
- Wenn die Werte aber einen selbstgebauten Datentyp haben, dann muss man sich selber darum kümmern wie diese verglichen werden. Für mal-eben-schnell-das-minimum-finden empfehle ich da ganz klar die for-Schleife, da sieht man sofort wie verglichen wird.

Warum sortieren?
- Wenn man noch weitere Dinge vorhat mit den Daten, kann es Sinn machen diese innerhalb des containers zu sortieren. Das dauert im allg. O(n log(n)) Laufzeit.
- In einem sortierten std::vektor oder einem std::multiset kann man durch Bisektion in O(log(n)) ein beliebiges Element finden. In einer sortierten std::list ist das nicht möglich, weil es kein random access gibt.
- Einen Baum/std::multiset braucht man dafür nicht. Wozu der gut ist, hab ich ja schon erklärt.

Und, für den guten Ton: Ihr habt alle keine Ahnung. Ich habe das Gefühl mich mit einer Packung Zwieback zu unterhalten.

[Xin]

Jester schrieb:

Dabei ist es wurscht, welche Datenstruktur tatsächlich drunter liegt. Sei es ein Array oder eine Liste.

Ähh... wenn Du einen Vector nimmst, wirst Du auf Dauer Schwierigkeiten haben an einem Array dran zu bleiben. Ich denke, das macht durchaus einen Unterschied.
Vektoren sind schnell, aber alles hat seine Grenzen. Die Grenze ist das Array.

Nebenher ist die Grundlage meines STL-Gemecker nicht die Geschwindigkeit, sondern die Notwendigkeit einem Anfänger STL zu verpassen.

otze schrieb:

mit templates kommt man hier aber auch nicht direkt in berührung. Ich muss ja nicht wissen, was templates sind, genauso, wie ich nicht wissen muss, wie cin oder cout funktionieren. Und was "using namespace std;" bedeuted, lernen die meisten auch erst lange nach ihrem ersten "hello world" programm. Von daher zeiht das Argument hier recht wenig.

Ich halte nichts davon mit objektorientierten Verfahren zu beginnen, bevor man weiß, was objektorientierte Programmierung bedeutet.

Ich programmiere fast ausschließlich OOP, auch in C, weil es fast immer das Mittel der Wahl ist. Aber ich halte nichts davon ein Hilfsmittel zu nutzen, wenn ich nicht weiß, warum.
Wie ich aus Deinem Posting herauslese sind wir uns da einig.

Als ich Autofahren oder Tauchen lernte, wurde man erstmal über aller notwendigen Interna aufgeklärt. Ich wurde weder ins Auto gesetzt und mit Anhänger auf die Autobahn geschickt und das erste Mal unter Wasser wurden auch keine Höhlen in 30 Metern Tiefe erkundet. Ich übte entsprechend meines Wissenstandes: Seitenstraßen und Übungen im Pool. Basierend darauf Landstraßen und Meerwasser usw. Step by Step.

Ich sehe keinen Grund, dass in der Informatik anders zu machen. Ich weiß, dass ich damit erstaunlicherweise recht alleine stehe.

Während meiner Zeit als Tutor durfte ich eigentlich jedes Semester komplett bei Null anfangen, weil die Leute aufgrund zuvieler Informationen diese überhaupt nicht sauber sortiert bekamen. Offiziell konnten die schon programmieren. Die haben schon komplexere Projekte abgegeben. Die wußten was Klassen sind und wie man Standard-Bibliotheken ruft, aber es wäre nett, wenn ich die while-Schleife nochmal erklären könnte....?!?
Hier sah ich viele Gründe, die deutlich dagegen sprechen, die Leute mit Informationen wegzubombem.

otze schrieb:

Anstatt std::sort zu nutzen, hacken sie sich nen verbugten bubble sort zusammen, und wundern sich, dass es dann nicht funktioniert(steht ja genauso da, wie im lehrbuch).
Das ganze weckt dann bei einem Anfänger auch nur den frust bei der Sprache, und ist absolut kontraproduktiv.

Ich habe den Frust der Leute eigentlich regelmäßig aufbeschworen in dem ich sie in jede mögliche Falle getrieben habe. Einer meinte später zu mir, dass er in dem paar Stunden Tutorium mehr gelernt hätte als in der Zeit davor.
Frust gehört dazu - immer. Genauso, wie die das Gefühl, dass man verstanden hat, warum man zuvor Frust hatte.

otze schrieb:

Später lernt man eh diese ganzen kleinigkeiten, ne liste kann man immernoch implementieren, wenn man sicher mit den grundmitteln der sprache ist.

Das kenne ich auch anders. Vectoren sind bekannt, aber nur als "Ding", dass irgendwie die Sachen zusammenhält.

otze schrieb:

Das mit den virtuellen funktionen solltest du näher erläutern. Klingt sehr neu und spannend für mich.

Lufthol... aushol... ähh... <buzzer>

Mit den virtuellen Funktionen habe ich mich in die Nesseln gesetzt. ^^

Die Diskussion gab es die Tage schonmal mit iostreams, da virtuelle Funktionen, hier werkeln Templates - keine virtuellen Funktionen.
Gleiche Geschwindigkeit zum Array ist damit möglich. ("möglich" ist nicht der Versuch einen letzten Widerstand im Sinne von 'Ich will aber recht behalten', sondern zollt der Tatsache Respekt, dass nicht spezialisierte Templates auch Informationen managen können, die für das spezielle Problem nicht von Bedeutung sind.)
Mea culpa!

otze schrieb:

finix schrieb:

robuster

Wer sich bei diesem Dreizeiler bereits Gedanken machen muss, ob er das korrekt implementiert bekommt... der hat auf jeden Fall recht, wenn er std::min_element() verwendet.

du weist wohl nicht, was robust bedeuted ;). Die Beispielschleife von dir auf Seite 7 ist zb nichtmal ansatzweise robust. Mach ich im zuge der entwicklung aus dem Array eine Liste, ist das ergebnis höchst suboptimal.

Ich denke schon, dass ich weiß, was robost lautet.
Machst Du im Zuge der Entwicklung aus dem Array eine Liste, muss das Ergebnis nicht unbedingt suboptimal sein, ist die Frage, wie die Liste implementiert ist.

Robost bedeutet für mich in erster Linie, dass ein Code mit unerwarteten Werten ohne Sonderbedingungen klarkommt.

Designänderungen für die Zukunft plane ich in der Regel nicht, sonst hätte das Design schon von vornerein einen Fehler.
Wenn es mich trifft, trifft es mich hart und das merke ich mir auch für's nächste Mal. In manchen privaten Projekten bin so kompromisslos, dass ich zugunsten einer geringfügig besseren Lösung auch wochen- und monatelange Arbeit ohne Zögern in die Tonne haue. Doch keine dieser Änderungen hätte mit der STL beschleunigt werden können.
Wenn geändert wird, dann ist die Frage 'Array oder Liste?' absolut bedeutungslos.