Studying the methods of solving problems,
we perceive another face of mathematics.

— George Polya ¹⁾

Ein Problem haben wir dann, wenn wir erkennen, dass uns der direkte Weg zur Lösung versperrt ist. Denken heißt erkennen, dass das Wissen zu Ende geht. Die Aufgabe wurde informell gestellt. Sie erfordert mehr Wissen als im Text mitgeteilt wurde.

Mathematisch vorbelastete Menschen würden diese Aufgabe etwas formaler stellen:

gegeben: F … Anzahl der Fahrzeuge, R … Anzahl der Räder
gesucht: A … Anzahl der Autos, M … Anzahl der Motorräder
Lösungsweg: Bestimme den Zusammenhang der Größen F, R, A und M.

Manche können den Zusammenhang recht schnell finden und niederschreiben. Andere können es nicht auf Anhieb. Das mag manchen überraschen. Müssen jene, welche in 10 Schuljahren Mathematikunterricht ständig "Kreide holen waren", deshalb aufgeben? Nein. Diese haben nur "vergessen" oder es wurde ihnen in der Schule abgewöhnt, selbst nach Lösungswegen zu suchen. Wenn es kompliziertere Zusammenhänge zu erkennen gilt, sind auch die "Leistungsstärkeren" auf die Techniken des spielerischen Probierens ("trial and error" und systematische Suche) angewiesen.

Wäre die Aufgabe mit konkreten Zahlen gestellt worden, käme die Lösung möglicherweise sofort. Mancher ist dann gar nicht in der Lage zu erklären, wie er die Lösung gefunden hat, sie ist "einfach da". Aber es geht ja um eine ganze Klasse von Aufgaben, um eine allgemeine Lösung. Es gilt das zu finden, was englische Mathematiker mit dem deutschen Lehnwort "ansatz" bezeichnen. Eine Tafel mit Lösungen konkreter Aufgaben, günstig sortiert, kann helfen, den Zusammenhang zu bestimmen.

Software-Ingenieure bezeichnen den in dieser Tabelle an Beispielen dargestellten Zusammenhang als "Fachwissen des Problembereichs". In dieser Aufgabe ist dies nicht mehr als Alltagswissen. Es könnte aber auch das Wissen sein, wie viele Muttern M10 in einem VW Phaeton verbaut sind. Gerald Weinberg²⁾ beschreibt in einen solchen Zusammenhang bei einem Autohersteller, der ein Programmiererteam an den Rand der Verzweiflung brachte.

In deutschen Worten lautet die aus dem Fachwissen gegebene Begründung so:

Sowohl Autos als auch Motorräder sind Fahrzeuge.
Jedes Auto hat vier Räder.
Jedes Motorrad hat zwei Räder.

Es gilt, dieses Fachwissen in einen handhabbaren Rahmen zu halten. Ein Fortsetzen der Tabelle wäre zwar möglich, aber nicht hilfreich. Es sind verallgemeinerbare Regelmäßigkeiten in der Tabelle versteckt:

Mit jedem Auto wächst die F um eins, R um vier.
Mit jedem Motorrad nimmt F um eins, R um zwei zu.

Mathematiker verdichten solche Zusammenhänge zu Formeln und nennen das algorithmische Kompression.

I) F = A + M
II) R = 4*A + 2*M

Nachdem der Zusammenhang so notiert ist, wird auch deutlich, wo das Problem liegt (oder lag). Es ist "unsymmetrisch". Sind A und M vorgegeben, lassen sich F und R einfach ausrechnen. Die umgekehrte Richtung übersieht man nicht so schnell. Es handelt sich um ein lineares Gleichungssystem mit 2 Unbekannten A und M. Zu seiner Lösung muss es erst umgestellt werden.

Durch Umstellen der Gleichungen können die gesuchten Größen auf der linken Seite isoliert werden, etwa so:

R = 4*(F-M) + 2*M wegen A = F - M
R = 4*F - 2*M
M = (4*F - R)/2

Mit dem umgestellten Gleichungssystem ist die Aufgabe nun durch einfaches Rechnen lösbar:

II') M = (4*F - R)/2
I') A = F - M

Dabei ist die Reihenfolge wichtig. Zuerst muss die Gleichung benutzt werden, auf deren rechter Seite alle Größen bekannt sind.

Wenn Du Dich an den Quelltext-Editor setzt, hast Du schon einen Plan im Kopf, was der Reihe nach im Programm geschehen muss. Von Vorteil ist, dass der Plan auch in der Muttersprache aufgeschrieben werden kann. Deutsch in Stichworten, durchsetzt mit einigen Rechenformeln, ist auch so etwas wie eine Programmiersprache:

Eingabe: F, R
M = (4*F - R)/2
A = F - M
Ausgabe: A, M

Wenn die einzelnen Anweisungen jetzt noch mit Bleistift so eingerahmt werden, dass lauter gleich breite Rechtecke übereinander gestapelt sind, haben wir ein Struktogramm (Nassi-Shneiderman-Diagramm) erstellt. Bei einem so kleinen Programm wäre es nicht unbedingt notwendig, diesen Plan auf Papier zu notieren. Wir tun es trotzdem, erstens um zu zeigen, wie sowas überhaupt geht, zweitens, um diese Technik zu üben, drittens, um den Kopf frei zu haben, wenn wir mit dem Editor und der noch unbekannten Programmiersprache hadern.

Eine Idee ist dann gefährlich, wenn es die einzige Idee ist, die man hat. Das ist das Übel des Fundamentalismus. Eine optimistischere Lebenshaltung ist: Wenn diese eine Idee nicht funktioniert, dann probieren wir eine andere; vielleicht geht es dann auch nicht. Die obige Tabelle könnte auch zu einer ganz anderen Idee geführt haben. Schauen wir noch einmal hin:

Zuerst wird angenommen, auf dem Parkplatz stehen nur Autos, keine Motorräder. Diese "nullte Näherung" muss nachkorrigiert werden, wenn die daraus berechnete Reifenzahl zu groß ist.

Eingabe: F, R
A = F
M = 0
Solange R < 4*A + 2*M ist

vermindere A um eins
erhöhe M um eins

Ausgabe: A, M

Notiere diesen Programmplan als Struktogramm (Struktogrammelemente siehe steuern_svg.pdf).

Die Korrektur muss evtl. mehrmals erfolgen. Diese Wiederholung (Schleife, Iteration) kann der Computer sehr oft ausführen. Sind die Zahlen klein genug, wird die Verzögerung kaum bemerkt. Bei einem sehr großen Parkplatz voller Mopeds, ähm … Verzeihung, Motorräder (Motorradfahrertreffen in Augustusburg, Woodstock?), sieht das anders aus.

Je mehr Fahrzeuge mit zwei Reifen auf einem Parkplatz stehen, umso mehr Schleifendurchläufe sind erforderlich, bis die Antwort gefunden ist. Dagegen ist das Programm sehr schnell fertig, wenn nur Fahrzeuge mit vier Reifen auf dem Platz sind. Mit diesem Verhalten (Diskrimierung der Zweiradfahrer!) unzufrieden, denken wir wieder nach. Wären alle Fahrzeuge Autos, müssten viermal soviele Reifen registriert worden sein. Die tatsächliche Reifenzahl ist möglicherweise kleiner. Der Unterschied ist doppelt so groß wie die Anzahl der Motorräder. Die Korrektur kann auch gleich in einem Schritt erfolgen, ohne eine Schleife durchlaufen zu müssen:

M = (4*F - R)/2
A = F - M

Nanu, da haben wir ja wieder die Formeln vom ersten Ansatz! Wer die Aufgabe intuitiv durch Probieren löst, löst möglicherweise unbewusst das Gleichungssystem. Dies scheint die bestmögliche Lösung zu sein.

Über das Lösen mathematischer Probleme schreibt George Polya³⁾:

Four phases. Trying to find the solution, we may repeatedly change our pooint of view, our way of looking at the problem. We shift our position again and again. Our conception of the problem is likely to be rather incomplete when we start our work; our outlook is different when we have made some progress; it is again different when we have almost obtained the solution. In order to group conveniently the questions and suggestions of our list, we shall distinguish four phases of our work. First, we have to understand the problem; we have to see clearly what is required. Second, we have to see how the various items are connected, how the unknown is linked to the data, in order to obtain the idea of the solution, to make a plan. Third, we carry out our plan. Fourth, we look back at the completed solution, we review and discuss it.

Kommt Dir das irgendwie bekannt vor? Der Softwarezyklus besteht im Groben ebenfalls aus vier Phasen: Analyse, Entwurf, Implementierung, Test. Nebenher und nicht bloß nebenbei (!) entsteht die Dokumentation. Das wird oft, auch in der Praxis, unterschätzt.

Ohne Dokumentation verstehen wir evtl. unsere eigene Programme nicht mehr. Eine der wichtigsten Hirnfunktionen ist, vergessen zu können. Auch das wird manchmal unterschätzt. Außer bei ganz kleinen Programmen wirken auch andere Programmierer mit. Auch diese müssen unsere Entscheidungen nachvollziehen können. Notieren wir also den Entwurf.

Weiter: Teil 4.