[Python-de] Kleine Aufgabe, große Wirkung

Michael Janssen Janssen at rz.uni-frankfurt.de
Mon Apr 7 14:25:29 EDT 2003


On Sun, 6 Apr 2003, "Martin v. Löwis" wrote:

> Typisches Beispiel: Ein Dateibaum. Wurzelverzeichnis (C:\, oder /),

danke

> Es war eine Aufgabe aus nem Bewerbungstest (das war doch deutlich
> gesagt, oder?)

Stimmt. Deshalb bin ich auch davon ausgegegangen ;-)

> Sie ist allerdings weder unlösbar noch nicht vernünftig
> lösbar. Es gibt einen "üblichen" Lösungsweg, den man entweder kennt oder
> sich ableiten kann.
>
> Es ging bei diesem Test *nicht* um ein echtes Problem, sondern vielmehr
> die Schaffung von Datenstrukturen, um alle Knoten systematisch zu
> betrachten. Wichtig ist dabei, dass sich dieses Problem nicht (alleine)
> durch Rekursion lösen lässt (anders als die Tiefe-zuerst-Suche).
> Getestet wurde also, ob beim Kandidaten die Erkenntnis vorhanden war,
> das Algorithmen und Datenstrukturen austauschbar sind.
>
>  > Weil ich mich als open source Programmierer fühle,
> > brauch ich sowas nicht und würde eher t neu implementieren als mir über
> > dessen Sortierung den Kopf zu zerbrechen.
>
> Dürfen open source Programmierer keine wissenschaftlichen Methoden
> verwenden?

Tja, wenn man mich so fragt: Na gut!

Was ich meinte ist, dass die Aufgabe t wie angegeben zu durchsuchen (wobei
ich - um den Spott selbst über mich auszugießen, bevor es wer anders tut -
völlig verpeilt hatte was mit "Testfunktion, welche versucht, den
richtigen Knoten zurückzugeben" gemeint war und suchen flugs mit sortieren
verwechselt habe) *in den meisten Lösungswegen* bedeutet, die
verschachtelte Liste suksessive zu entschachteln (während zugleich
verarbeitete Inhalte entfernt werden). Das ist nicht verkehrt: es ist wie
man sehen kann elegant, es ist effizient (Zuweisungen sind in Python
billig).

Wenn es gleich eine Liste wäre könnte man die Suche mit geringem Aufwand
durchführen, daher sage ich, dass t für diese Aufgabe ungeeignet ist und
entweder mit elegantem Algorithmus entschachtelt wird oder mit
ausführlichem, fraktionierten code.

In einem Open Source Projekt, dessen code von anderen mitgeschrieben
werden soll und den auch Benutzern nachvollziehen können sollen (ich
spreche nicht von systemnaher Software), *dann* würde ich sagen, dass ein
Punkt erreicht ist, wo ein (ebenfalls wissenschaftlich fassbares)
Kommunikationsproblem relevanter als die algorithmische Aufgabe wird: die
interne Datenstruktur (die "mal so festgelegt" worden ist oder die für
ihren Kernjob die geeignetste ist)  kommt an einen Punkt, wo sie
umgemodelt werden muss. Hier würde ich mich für verbose code entscheiden
und das Problem in sehr ausführlichen Schritten niederringen (es steht ja
nicht zur Debatte, ob man die Suchaufgabe überhaupt lösen kann, sondern ob
es in 9 Zeilen und 15min geht). Ich würde die neue geeignete Datenstruktur
zugreifbar machen, damit jedeR einen Blick (ein print) darauf werfen kann.

Wo ich das jetzt so schön ausformuliert habe, sehe ich ein, dass ich
schreiben muss: "Ich schreibe (will schreiben) Open Source, die ihre
Struktur möglichst offen zeigt (und fange erst nach schlechten
profiler-Ergebnissen an, auf Effizienz zu optimieren ;-)".

Nein, ich sage nicht, dass the other way round schlechter ist oder
womöglich gar keine Open Source. Ich sage, man muss wissen wo man die
Schwerpunkte legt und wieviel und wie wenig mit Bewerbungstestaufgaben in
den Blick kommt.

Der ursprüngliche Beitrag hörte sich ein wenig danach an, als müsse jetzt
jedeR seinen code in 9 Zeilen und 15min schreiben (um es pointiert
auszudrücken).... Das etwas arg exzessiv geratene Gewinke mit
Berufsaussichten empfinde ich als ein zu starkes Geschütz, um zu
plausibilisieren warum und wie ein Problem gelöst werden muss. Hat aber
ne Menge an Interessantem zutage gefördert.


Grüße
Michael






More information about the Python-de mailing list