nicht angemeldet
Camping_RIDERAloha ;)
Es fängt schon damit an, dass ich einen Knoten in den Kopf bekomme wenn ich deine Debug-Helper sehe. Die Semantik von to und from ist genau vertauscht, ist das deine Art, ein Rätsel auf lustige Art noch rätselhafter zu machen? Aber das kann man immerhin noch schnell ändern.
Ich halte sowas für verzeihbar und einfach kompensierbar. Wie soll eine Konvention da aussehen - je nachdem wie man die Sache dreht wird's entweder "richtig" oder "falsch".
Die hier zugrundegelegte Logik war wohl: from konvertiert vom Objekt-Datentyp zum primitiven Typ, und to konvertiert zum Objekt-Datentyp vom primitiven Typ. Ob das jetzt intuitiver ist als andersrum, oder ob das andersrum intuitiver ist, darüber lässt sich wahrlich streiten - denn es waren ja auch keine Objekt-Methoden, sondern einfache Funktionen.
Zum Tragen kommt das eh nur in der (Test-)Ausgabe.
Aber wenn an so einer einfachen Stelle schon unsere geistige Inkompatibilität beginnt, muss ich mich nicht wundern, wenn danach ganz Schluss ist.
Spätestens bei natE frage ich mich, was das überhaupt grundsätzlich soll. Eine rekursive Funktion, die dazu dient, Rekursion durch Induktion zu ersetzen - äh, wie? Ich fühle mich ver...gackeiert.
Der erste Aufgabenteil ist eine Standard-Aufgabe - kam bei mir genau so vor mit Haskell in den Übungen zur Standard-Vorlesung zur Einführung in funktionale Programmierung. Das ist weder ein Konglomerat aus Unsinn, noch Raketenwissenschaft, sondern Grundlagenwissen für Informatiker.
Der zweite Aufgabenteil ist eine Abstraktion und funktioniert mit Hirnschmalz gut, wenn man den ersten Aufgabenteil geknackt hat. multE ist mit einem nur kleinen Hindernis einfach zu finden. Für facE brauchts Hirnschmalz, vielleicht Zettel und Stift, und einen kreativen Umgang mit der relativ unspezifischen Definition von natE (das nur als kleiner Hinweis in die richtige Richtung).
Probiers doch einfach mal aus - einfach die verlinkte Vorlage forken und dann mal drauflosprobieren!
Grüße,
RIDER
Rolf B