Hi Hagen,
Zitat von
negaH:
Und genau das ist die falsche Sichtweise. Du versuchst die Anzahl an Zeilen zu optimieren statt sich darauf zu konzentrieren so viele Zeilen an Source zu schreiben wie es notwendig ist ein Problem auch deutlich und einfach verstehbar zu umschreiben. Deine Zielsetzung konzentiert sich auf ein Detail statt auf das gesammte Problem.
Mit der schwindenen Anzahl an Zeilen erhöht sich die Anzahl selbiger, die auf meinen Bildschirm passen und somit auch meine Effizienz beim Arbeiten
. Ich versuche nicht krampfhaft Zeilen zu optimieren, sondern dort, wo es für mich sinnvoll ist.
Zitat von
negaH:
Hä, hast du das editiert ? Ich kann mich erinnern das dort noch IsPrim() stand. Falls nicht, sorry, ändert aber nichts an der Aussage ansich
Es bezieht sich ja nicht persönlich auf dich sondern gilt eher allgemein.
Nein, hab' ich nicht editiert. Vielleicht kannst du aus dem Link meiner Signatur entnehmen, dass ich mich für die deutsche Sprache interessiere und daher auch vor Anglizismen erstmal zurückschrecke; mich erstmal frage, ob sich das nicht auch auf Deutsch genauso verständlich ausdrücken lässt.
Zitat von
negaH:
Doch bist du, sind wir alle.
Die Hardware basiert auf der Boolschen Algebra, und in der Programmierung ist es immer von Vorteil auch ein bischen Mathematik zu beherrschen.
Nein, da muss ich dir widersprechen. Mathematiker sind nicht gleich Programmierer (ich sage nicht Informatiker!) und auch nicht umgekehrt, da die einzelnen Gebiete doch sehr unterschiedlich sind, gerade wenn es um komplexe Fälle geht. Ich sehe mich jedenfalls definitiv nicht als Mathematiker, davon hab' ich viel zu wenig Ahnung.
Zitat von
negaH:
Davon abgesehen versucht, bei unserem speziellen Problem, ein Programmierer ein rein mathematisches Problem in eine Software umzusetzen. Es ist aber fatal eine Sichtweise an den Tag zu legen die im Grunde ignorant ist. Denn deine Aussage heist für mich persönlich das du eine mathemtische Aufgabe nicht deshalb mathematisch korrekt angehen möchtest weil du sagt "na und, ich bin Programmierer und kein Mathematiker". Das ist ignorant und meiner Meinung nach eben auch ein "schlechter Programmierstil". Programmierstil bedeutet nicht wie der Souce aussieht, nein das ist nur eine Wirkung der Ursache. Und die Ursache für einen guten Programmierstil ist die Frage WIE der Programmierer ein Problem lösst. Und handelt es sich um ein Problem der Mathematik dann sollte er es auch so angehen. An Hand des Sources kann man also durchaus erkennen ob ein Programmierer sachlich fundiert und sauber ein Problem angegangen ist. Ist dies der Fall dann ist der Source sauber formatiert, folgt einer Logik, ist nachvollziehbar und umschreibt das zu lösende Problem auch für Andere verständlich. Ein Source ist dann nicht nur ein Source sondern quasi ein Lehrbuch das mit eigener Sprache ein Problem erklärt.
Nun, ich möchte sie schon mathematisch korrekt angehen, ich sagte ja nicht, dass ich, weil ich kein Mathematiker bin, mir erlaube, einfach gewissenslos Fehler zu machen. Allerdings ist die Wahl der Variablennamen schon fast Geschmackssache und sollte meiner Meinung nach nicht unbedingt mathematischen Gepflogenheiten angepasst sein.
Zitat von
negaH:
Nicht nur. Ich meinte das man bei dieser schnellen "Eingangsüberprüfung" gleich nebenbei abprüfen kann
1.) ist Zahl ungerade ?
2.) ist Zahl größer 2 ?
Man schließt damit also implizit Zahlen aus die
1.) negativ sind
2.) gleich Null sind
3.) gleich Eins sind
4.) gleich dem Spezialfall der einzigsten gerade Primzahl 2 sind
5.) gerade Zahlen sind
Diese 5 Bedingungen werden mit
Result := Odd(N) and (N > 2);
abgefragt.
OK, das wurde mir aus deinem Post vorher nicht klar.
Zitat von
negaH:
Und wieder eine Form der Ignoranz. (ich würde sogar sagen Trotzigkeit).
Es sollte im Bestreben jedes Programmieres sein nicht mit Scheuklappen rumzurennen, sondern auch andere Programmiersprachen und deren Konzepte zu erlernen und zu beherrschen.
Ja, diesmal ist es Trotzigkeit. Ich muss mich in der Schule teilweise mit Turbopascal herumärgern und meine das wörtlich; was da alles fehlt, ist unglaublich, wenn man sich einmal an Delphi gewöhnt hat (dynamische Arrays, bequeme Klassen, Dateinamen größer 8.3 Zeichen (gut, das hat mehr mit der
IDE zu tun und den damals üblichen Beschränkungen)). Als Ersatz für Turbopascal bin ich nun auf Freepascal umgestiegen und komme damit ziemlich gut klar, für mich fällt das auch unter Delphi Language, was man damit kompilieren kann. Daher sage ich, dass ich kein Pascal schreibe, da mein Quelltext ja meist nicht abwärtskompatibel ist.
Zitat von
negaH:
Ja, das obige. Es enthält sogar 3 solcher Fälle:
Delphi-Quellcode:
Result := Odd(N) and (N > 2);
Result := N mod Candidate <> 0;
Result := N = 2;
statt
Delphi-Quellcode:
if Odd(N) then
if N > 2 then Result := True
else Result := False
else Result := False;
if N mod Candidate = 0 then
begin
Result := False;
Exit;
end;
Das eine ist eine mathematische Sichtweise, Denkweise als Formel. Das andere ist eine rein Algortihmische, ja fast schon Maschinen-denkweise.
OK, das macht klar, was du meinst. Ich behaupte allerdings, dass ich das nicht so extrem gemacht habe in meinem Beispiel. Bei mehreren Result:=true/false-Zuweisungen hintereinander schrecke ich meist auf und denke mir: Das könnte doch auch in einer Zeile mit einer geschickten Bedingung erledigt werden
.
Zitat von
negaH:
weil durch diese Anweisungen der aktuelle Programmblock irregulär verlassen oder weitergeführt wird.
Ein Exit zb. springt direkt aus dem aktuellen und hierarisch geschachtelten Programmblock und verlässt die komplette Funktion/Procedure. Exit zerstört also den grafisch hierarischen Source Aufbau, somit den Lesefluß eines anderen Programmieres und finally damit auch die Verständlichkeit.
Genau das bezwecke ich doch. Meinetwegen könnte man das exit ja in rot markieren, wenn es denn so deutlich werden muss, dass hier aus der Funktion ausgestiegen wird
. Jedoch halte ich Prüfungen nach der Schleife, ob man dann ab hier noch weiterarbeiten soll, sehr unsauber. In C gibt es break 2; beispielweise, damit steigt man aus der jetztigen und der übergeordneten Schleife aus. Sowas gibt es in Delphi meines Wissens nach nicht, wodurch sich exit für mich legitimiert.
Zitat von
negaH:
Siehst du: ein guter Programmierstil fördert die Verständlichkeit beim Lesen durch Andere.
Anscheinend habe ich da aber vollständig versagt
sonst hättest du meine Source auch verstanden und erkannt das der Fall 8 = gerade Zahl garnicht, nein niemals garnicht never, in der while Schleife auftreten kann.
Ja, das habe ich tatsächlich übersehen beziehungsweise unabhängig von deinem Punkt 8.) (war es doch, oder?) gesehen.
Ich sehe, dass man am Algorithmus selbst wohl noch ein bisschen 'was ändern kann, das auch der Performance ganz gut tut. Allerdings könnte sich der Threadersteller ja auch mal hier melden und bescheid sagen, ob er die ganzen Verbesserungen überhaupt benutzt oder ob er an so optimierten Funktionen interessiert ist.
cu