Frage zu for-Schleife

[Michael E.]

volkard schrieb:

Schreib mal einen englischen Text, ohne "a" oder "the" zu benutzen.

Diese beiden Probleme sind nicht gerade gleich schwer

Das ist bei weitem keine nötige Denkweise.

Mit "nötige Denkweise" meine ich die Denkweise, ein Problem in der Art anzuschauen, dass man einen Algorithmus aufstellen kann, den man anschließend in einer Sprache implementiert. Diese Denkweise ist sehr wohl wichtig und wird mit dieser Aufgabe geschult.

[volkard]

Michael E. schrieb:

volkard schrieb:

Schreib mal einen englischen Text, ohne "a" oder "the" zu benutzen.

Diese beiden Probleme sind nicht gerade gleich schwer

Das ist bei weitem keine nötige Denkweise.

Mit "nötige Denkweise" meine ich die Denkweise, ein Problem in der Art anzuschauen, dass man einen Algorithmus aufstellen kann, den man anschließend in einer Sprache implementiert. Diese Denkweise ist sehr wohl wichtig und wird mit dieser Aufgabe geschult.

Dazu gäbe es aber bessere Aufgaben, nicht so seltsam-beschneidende, daß man am Edne gar nicht mehr weiß, was man machen soll.

[volkard]

Michael E. schrieb:

volkard schrieb:

Schreib mal einen englischen Text, ohne "a" oder "the" zu benutzen.

Diese beiden Probleme sind nicht gerade gleich schwer

Siehe mein erster Code. Es war nicht verlangt, daß der Text besonders lang ist.

[berniebutt]

Volkhard: Bleiben wir beim Sinn und Zweck von Übungsaufgaben. Diese können meiner Meinung nach nur zwei Zielrichtungen haben, nämlich zu zeigen:

1. so macht man das --> hir nicht erfüllt
2. So ist ein algorithmischer Weg für andere komplexere Aufgaben --> erkenne ich auch nicht

Bitte andere Aufgaben ausdenken, die den Lernenden nicht sofort verwirren und andere - wie mich - nicht sagen lassen Das ist eine saublöde Aufgabe!
Übungsaufgaben zur Programmierung sind wichtig zum Lernen, daran besteht kein Zweifel. Nur totaler Blödsinn sollten sie auch nicht sein!

[Michael E.]

berniebutt schrieb:

Volkhard: Bleiben wir beim Sinn und Zweck von Übungsaufgaben. Diese können meiner Meinung nach nur zwei Zielrichtungen haben, nämlich zu zeigen:

1. so macht man das --> hir nicht erfüllt
2. So ist ein algorithmischer Weg für andere komplexere Aufgaben --> erkenne ich auch nicht

Bitte andere Aufgaben ausdenken, die den Lernenden nicht sofort verwirren und andere - wie mich - nicht sagen lassen Das ist eine saublöde Aufgabe!
Übungsaufgaben zur Programmierung sind wichtig zum Lernen, daran besteht kein Zweifel. Nur totaler Blödsinn sollten sie auch nicht sein!

Manchmal zweifle ich an deinem Textverständnis. volkard findet die Aufgabe auch blöd. Ich bins, der die Aufgabe nicht schlecht findet, auch wenns sicher nicht meine Lieblingsaufgabe ist. Aber um das weiter sinnlos auszudiskutieren, fehlt mir die Lust.

[volkard]

berniebutt schrieb:

Volkhard:

Nenn mich doch dein Einfachheit halber Volkard.

berniebutt schrieb:

Bitte andere Aufgaben ausdenken, die den Lernenden nicht sofort verwirren

Ich denke, das habe ich anno 1999 schon zu Genüge getan.

[berniebutt]

volkard schrieb:

berniebutt schrieb:

Bitte andere Aufgaben ausdenken, die den Lernenden nicht sofort verwirren

Ich denke, das habe ich anno 1999 schon zu Genüge getan.

Dann zeige den Zugang zu deinen Beispielen den jetzt lernenden bitte! Wie finden sie, was du 1999 bereits von dir gegeben hast? Ein Verweis darauf zum Nachlesen gehört hier dahin. Mache eine eigene Homepage, damit man das lesen kann! Vielleicht kann ich auch noch etwas lernen?

[Bashar]

berniebutt schrieb:

Volkhard: Bleiben wir beim Sinn und Zweck von Übungsaufgaben. Diese können meiner Meinung nach nur zwei Zielrichtungen haben, nämlich zu zeigen:

1. so macht man das --> hir nicht erfüllt
2. So ist ein algorithmischer Weg für andere komplexere Aufgaben --> erkenne ich auch nicht

Ich denke schon, dass 2. hier zutrifft. Man nimmt ein einfach zu verstehendes Problem und beschränkt die zur Verfügung stehenden Mittel, um den Lösungsweg so vorzugeben, dass das Lehrziel erreicht wird. Man könnte natürlich auch ein schwieriges Problem hernehmen, bei dem die Mittel auf natürliche Art und Weise beschränkt sind, aber dann sitzen die Schüler "etwas länger" daran.

[skullyan]

Danke an alle. Welche Übungen würdet Ihr mir denn empfehlen?

(Ich lerne C++ nebenbei)

[wxSkip]

Mal ganz nebenbei, wieso nicht so:

#include <iostream>
int main()
{
    int result = 1;
    for(int i = 1; i<=10; i++) result = result / (1 / (double)i);
    cout << result;
}

[volkard]

wxSkip schrieb:

Mal ganz nebenbei, wieso nicht so:

#include <iostream>
int main()
{
    int result = 1;
    for(int i = 1; i<=10; i++) result = result / (1 / (double)i);
    cout << result;
}

Genau!
Und was haben wir algorithmisch gelernt?

[µngbd]

So gehts auch:

// C99
#include <stdio.h>
#include <math.h>

int main()
{
    printf("%.0f\n", exp(lgamma(11)));
}

Nur weiss ich leider nicht, wie die Gamma-Funktion in C++ heisst.

[schlaukopf]

volkard schrieb:

wxSkip schrieb:

Mal ganz nebenbei, wieso nicht so:

#include <iostream>
int main()
{
    int result = 1;
    for(int i = 1; i<=10; i++) result = result / (1 / (double)i);
    cout << result;
}

Genau!
Und was haben wir algorithmisch gelernt?

Dass a / ( 1 / x ) = a * x ist. Besser diese mathematische Erkenntnis, als gar keine Erkenntnis

[Shade Of Mine]

volkard schrieb:

Michael E. schrieb:

Was habt ihr gegen die Aufgabenstellung? Es ist ein einfaches Problem, zu dem ein einfacher Algorithmus gefunden werden soll. Das find ich gut, um Programmieranfängern die nötige Denkweise näherzubringen.

Schreib mal einen englischen Text, ohne "a" oder "the" zu benutzen.

Kurz vorweg, das ist eine Aufgabe aus meinem Tutorial.

Die Idee dahinter ist:
Eine Aufgabe zu stellen deren Lösung ich selber leicht als richtig Beweisen kann. 1*2*3*4*... ist leicht nachzurechnen.
Zu diesem Zeitpunkt im Tutorial sind Funktionen aber noch unbekannt. Einfache zählschleifen wurden schon gemacht und dies sollte jetzt die komplexität erhöhen.

Im Prinzip hätte ich auch 1 hoch 2 hoch 3 hoch 4... als Aufgabe geben können, da der Leser pow() nicht kennt, würde es auf das selbe hinauslaufen (multiplikationen). Aber da kommen so furchtbare zahlen raus...

Ich finde es aber auch nicht sonderlich gemein eine multiplikation zu verbieten. Denn der effekt ist, dass die Aufgabe mathematisch leicht überschaubar ist, aber dennoch praxisrelevant. Denn ersetze * durch eine komplexe Operation die du eben nicht direkt abbilden kannst, zB pow. Ein bisschen später kommt nämlich genau diese Aufgabe nochmal, nur dass man eigene funktion multiply() schreiben muss.

Ich finde diesen simplen Ansatz einfach besser - da ihn jeder verstehen kann. Dafür bekomme ich vermutlich keine Stilpunkte, aber die meisten Leute verstehen es trotzdem (und nur darum geht es mir).

[wxSkip]

Man könnte ja die Aufgabenstellung so für verschiedene Schwierigkeitsgrade erweitern:
1. Schreibe ein Programm, das 10! mit + berechnet (leicht)
2. Schreibe ein Programm, das 10! mit - berechnet (leicht)
3. Schreibe ein Programm, das 10! mit / berechnet (leicht)
4. Schreibe ein Programm, das 10! mit C-Funktionen berechnet (schwer)
5. Schreibe ein Programm, das 10! mit STL-Funktionen berechnet (schwer)

Dann ist tricksen nämlich mal so gut wie ausgeschlossen

[Nexus]

wxSkip schrieb:

5. Schreibe ein Programm, das 10! mit STL-Funktionen berechnet (schwer)

Oh, mit std::multiplies() ist das aber auch nicht wahnsinnig schwer...

[Samyboy]

Nexus schrieb:

wxSkip schrieb:

5. Schreibe ein Programm, das 10! mit STL-Funktionen berechnet (schwer)

Oh, mit std::multiplies() ist das aber auch nicht wahnsinnig schwer...

Nunja, wenn man noch nie was von STL gehört hat und noch nie eine Funktion verwendet hat... ^^

[Nexus]

Okay, das stimmt, aber dann liegt der Schwerpunkt halt nicht mehr im Algorithmischen. Ansonsten (ich wollte wieder mal reine STL benutzen :)):

int filler()
{
	static int i;
	return ++i;
}

int main()
{
	std::vector<int> vec(5);
	std::generate(vec.begin(), vec.end(), &filler);
	int result = std::accumulate(vec.begin(), vec.end(), 1, std::multiplies<int>());
}

[µngbd]

Shade Of Mine schrieb:

Dafür bekomme ich vermutlich keine Stilpunkte, aber die meisten Leute verstehen es trotzdem (und nur darum geht es mir).

Ich finde das gut so. Nachher führst du ja auch noch Funktionen ein, damit sieht das gleiche Programm fast genauso aus wie man es mit dem * schreiben würde. Da ist das Ergebnis dann schon ein alter Bekannter. Den kann man wieder besuchen, wenn man Rekursionen durchmacht und die unumgängliche Fakultät bringt. Ich finde das ist guter Stil.

[Shade Of Mine]

wxSkip schrieb:

Dann ist tricksen nämlich mal so gut wie ausgeschlossen

Wobei ich natürlich kein Problem habe wenn man trickst.

volkards
std::cout << 3628800 << "\n";
ist zB eine korrekte Lösung. Man hat damit eine wichtige Lektion gelernt. Sofern man natürlich selber darauf gekommen ist. Zwar nicht die Lektion die man lernen hätte sollen, aber es ist ja kein Test wo ich mich als Tester profilieren will, sondern der Leser soll etwas lernen. Wenn er etwas lernt, dann ist das Ziel erreicht. Auch wenn er andere Sachen lernt als ich ursprünglich geplant hatte.

zB könnte der Leser ja auch einen Code von mir sehen und sagen "nein, schlechtes Tutorial" auch damit hat er etwas gelernt - besser als wenn er sich stundenlang reinbeisst und nichts rauskommt.