Styleguide für Algorithmen Thema ist als GELÖST markiert

[Stefan Kottwitz]

Vom Cookbook kann ich Dir ein kostenloses Rezensions-Exemplar durch den Verlag schicken lassen, das machen die weil es gerade neu erschienen ist. Wenn Du möchtest, schick mir gern eine email an stefan@latex.org.

In dem Algorithmus würde ich die langen sprechenden Variablen-Namen in typewriter belassen, kgv eigentlich als mathematischen Operator sehen (upright serif/roman) sofern nicht selbst definiert, typewriter mix in Formeln hingegen finde ich schwierig. len1 finde ich schwerer lesbar als L₁ und L₂. Bei direktem Bezug zu Code-Variablen, vielleicht ja. Bei Code-Implementierung kann man aber auch eine kurze Liste mit Variablen haben, wie len1 repräsentiert L₁ etc.

Sind auch nur meine Meinungen, vielleicht ist das eine oder andere moderne mathematisch basierte Algorithmen-Buch auch eine gute Referenz wie man es machen kann.

Stefan

[Mephisto]

Da bin ich nochmal

Ich muss nochmal um Hilfe fragen.
Ich habe meinen Algorithmus nun folgendermaßen dargestellt:

Nun frage ich mich folgendes (möglicherweise Haarspalterei, aber ich brauche mal deine Meinung)_
Ich gebe ja die Variablen a und n ein.
Da das ganze Zahlen / natürliche Zahlen sind, schreibe ich sie in der Ein- und Ausgabe oben kursiv.
Im Pseudocode wiederum schreibe ich sie im typrewriter. Das habe ich deshalb gemacht, weil ich ja auch mal "faktor" als Variable habe. Die wollte ich nicht kursiv setzen, das sah schlimm aus.
Aber wenn ich nach dem Algorithmus im Fließtext diese Schritte erkläre und schreibe beispielsweise "nun wird a zurückgegeben", dann ist es schon "inkonsequent", denn a habe ich einmal als ganze Zahl (kursiv) und einmal als Variable (typewriter).
Was rätst du mir?

[Stefan Kottwitz]

Hallo,

Haare spalten ist doch gut, wenn dabei ein besonders gutes Ergebnis herauskommt. Tatsächlich geht "faktor" kursiv gar nicht, mehrbuchstabige Variablen sehen nicht nur schlimm aus sondern wären verwechselbar mit Produkten aus Einzel-Variablen. Es ist ja auch eine Code-typische Variable und typewriter ebenso angemessen wie bei Funktionsnamen.

Wie wäre dieser Ansatz?

• Mathematische Variablen, die in Text und Erklärungen bzw. Ein-/Ausgabe verwendet werden, im originalen mathematischen Kursiv-Erscheinungsbild, konsequent.
• Programm-interne Variablen in Typewriter, weil hier ist es definitiv Code. Wenn man im Text auf faktor und interne Code-Variablen Bezug nimmt, auch typewriter. Bei Mathe-Variablen Mathe-Font.
• Im Preface vllt. eine kurze Erläuterung von Konventionen im Dokument, was bedeutet was, wo man das kurz erwähnt. Da sieht auch durchdacht und seriös aus als Service für den Leser. (Falls der Prof meint, im finalen Dokument lieber streichen, dann hat er es wenigstens gelesen und verstanden, dass Du diesen Stil so gründlich erarbeitet hast und kann Feedback geben.)

Hier ist, wie ich es den letzten Punkt in meinem Buch gemacht habe:

Stefan

[Mephisto]

Stefan, ich danke dir ganz herzlich für diesen Hinweis.
Ich werde mich jetzt direkt daran begeben und würde gerne im Anschluss ein "komplettes" Beispiel darlegen. Also Pseudocode und etwas vom anschließenden Text. Ich würde mich sehr freuen wenn du mir dazu nochmal ein Feedback gibst.
Die Idee das zu erklären werde ich übrigens umsetzen, das hört sich sehr gut an für mich.
Der Prof wird die Arbeit vor der Abgabe nicht nochmal lesen... daher mein Nervenflattern

[Mephisto]

Oh, vielleicht doch noch etwas vorher.

Ich prüfe ja zum Beispiel eingangs, ob a gerade ist. Sprich: Das "mathematische" a wird geprüft, ob es gerade ist. Dafür hat die Mathematik ja die Kongruenz mod 2.

Nun prüfe ich im weiteren Verlauf aber ja auch, ob die Variable a gerade ist. Aber beim Programmieren kann ich ja nicht mit Restklassen arbeiten, sondern mit dem wirklich Rest bei Division durch 2, also 0 oder 1 in diesem Fall.

Aber wenn ich einmal schreibe "a kongruent zu 0 mod 2" (mathematisch, also mit Kongruenzzeichen dazwischen)
und danach
"a mod 2 == 0"
dann ist es wieder inkonsequent,...

[Stefan Kottwitz]

Aber wenn ich einmal schreibe "a kongruent zu 0 mod 2" (mathematisch, also mit Kongruenzzeichen dazwischen) und danach "a mod 2 == 0" dann ist es wieder inkonsequent,...

Dann schreibe es in beiden Fällen mathematisch. Es ist ein Algorithmus, der mathematisch ist und entsteht bevor es überhaupt Code-Zeilen gibt und sogar bevor die Programmiersprache entschieden ist, selbst die Notation == finde ich fragwürdig wenn es doch um den Algorithmus geht und nicht um Code-Syntax.

Im Jakobi-Symbol würde ich übrigens die Variablen größer machen, so dass sie innere Höhe den Klammern entspricht (oder nur minimal kleiner).

Stefan

[Mephisto]

Danke sehr, Stefan, ich bearbeite jetzt meinen Code und poste ihn in ein paar Minuten hier

[Mephisto]

Hier nun mein Code und der anschließende Test.
Hier frage ich mich, ob Zeile 8 im Code noch alternativ geht. Denn hier muss ich ja wirklich den Rest zuordnen.

Ich will mich nochmal svielmals für die ewige Geduld bedanken!!

[Stefan Kottwitz]

Sieht sehr gut aus!

Für meinen Geschmack ein sehr großer Text-Block, nicht so leicht zu verdauen, ich würde ihn in vllt. 3 Absätze zerlegen, immer dort wo ein weiterer Aspekt beginnt ("In den beiden darauffolgenden if-Blöcken...", "Sollte bis zu dieser Stelle...").

Stefan

[Mephisto]

Irgendwie ging mir das genauso ohne dass ich das realisiert habe...