Hallo Helfer,
vielen Dank für Eure Antworten. Hier die zu meiner Frage gewünschten Ergänzungen.
Max Payne: Was genau sortierst Du denn?
"records", nämlich Datensätze mit Ergebnissen von sportlichen Wettbewerben. Zweck: Erstellung von Ranglisten nach den Erfolgen in den vorangegangenen drei Jahren - jeden Monat neu mit den Ergebnissen des letzten Monats.
Alle Ergebnisse eines Monats sind in einer Datei "file of record" gespeichert. Jeder "record" besteht aus mehreren String- und Zahlen-Datenfeldern mit Angaben zur Person des Teilnehmers und zu seinem Erfolg.
Der Teilnehmerkreis ist begrenzt, in der Regel im Bereich von 30 bis 200. Jeder Teilnehmer ist eindeutig gekennzeichnet durch ein Kürzel aus maximal fünf Großbuchstaben. Die Zahl der Wettbewerbe liegt monatlich meist im Bereich von 4 bis 25, deren jeweilige Teilnehmerzahl 12 bis 80.
PaoloP:
Warum ist denn er Umstieg auf Delphi nicht möglich?
Tausende IT-Unterricht Schüler in deutschen Grundschulen mussten mit Delphi programmieren
weil umfunktionierte Mathelehrer früher mal Pascal gelernt haben. Scheint zu gehen.
Anonsten musst du schon sagen was du da sortierst und welchen Sortieralgorithmus du verwendest.
Die exe-Datei des Programms passt gerade noch auf eine 1,4-MByte-Diskette, die Programmzeilen habe ich nicht gezählt. Begonnen habe ich damit vor 20 Jahren im Alter von >60. Sollte ich dann später für Windows in einer doch recht anderen Programmiersprache sozusagen ein neues Programm in Angriff nehmen?
Die Sortierung erfolgt auf der Basis der Chip-Spezial-Toolbox-Unit TREELIB, die wohl aus den Neunziger-Jahren stammt, in einer dynamischen Baumstruktur: Die Datensätze werden an die Unit übergeben und entsprechend dem maßgebenden Datenfeld in den Baum eingefügt.
Andreas42:
Der Code steht fix im Programm und die CPU führt ihn aus. Da kann es aus meiner Sicht keine Abweichungen in Sortierergebnissen geben, sofern die Sortierung im Programmcode erfolgt.
Einziges Problem ist die Zeitmessung bei Programmstart in der Standardbibliothek. Die musstest du ja vermutlich schon patchen.
Ich denke eher an die üblichen Fehler: man will alphabetisch sortieren, erwartet das Umlaute korrekt einsortiert werden, vergisst aber, dass die von ihrem CHR-Wert, ausserhalb des normalen Alphabets liegen.
Evtl. hat man die Umlaute auch berücksichtigt, aber dann nur für DOS-ASCII-Kodierung, nicht aber für die unter Windows verwendete ANSI-Kodierung.
Code: Das dachte ich auch. Aber muss das immer so sein?
Zeitmessung: Davon weiß ich nichts. Was muss ich dafür eventuell tun?
Alphabetisch: Das ist mir klar. Es stand aber beispielsweise bei der Sortierung nach den Namenskürzeln der Datensatz mit ZIP zwischen den mit N beginnenden Datensätzen.
Andreas42:
Wenn wir es auf diese allgemeine theoretische Betrachtungsweise angehen, dann müssen wir logisch schlussfolgern, dass die Programmierung bewirkt, dass die Sortierung auf schnelleren CPUs kein eindeutiges Ergebnis liefert. Die Ursache liegt daher der programmiertechnischen Umsetzung.
Dann lautet die Lösung natürlich: das Programm muss so geändert werden, dass das nicht passiert.
Ich hätte aber lieber konkrete Beispiele, was sortiert wird und dann wie rauskommt. Zudem natürlich den TurboPascal-Quelltext der Sortierung. Wer weiss schon, was wirklich passiert?
Ausgehend von meiner Person (und meiner ureigenen Schusseligkeit), wäre die naheliegende Ursache, dass die Ausgangsdaten beim groben Überfliegen gleich aussehen und auf den ersten Blick gleich verarbeitet werden, sich dann aber nach kräftigem Fluchen ("Himmel, Arsch und Zwirn!" - universeller hessischer Fluch) und Verwünschen ("Mist!", Zitat Bernd das Brot) herausstellt, dass sich die Ausgangsdaten doch unterscheiden und sie zusätzlich doch nicht gleich verarbeitet werden (weil irgendein Zusatzprogramm aufgerufen wird, dass unter XP etwas anders arbeitet als unter DOS). ;-)
Programm ändern: aber wie?
Quelltext: Als Beispiel von mehreren eingesetzten Funktionen hier die Entscheidungsfunktion für eine Sortierung nach Namenskürzeln:
function VglRS (p10, p20: pointer): boolean;
var kl : shortint;
v1, v2 : v_ispieler_m;
begin
VglRS := t;
Move (p10^, v1, SizeOf (v_ispieler_m));
Move (p20^, v2, SizeOf (v_ispieler_m));
kl := KzlKleiner (v1.ikzl, v2.ikzl);
if kl = -1 then Exit;
if kl = 0 then if KzlKleiner (v1.iclub, v2.iclub) = -1 then Exit;
VglRS := f;
end; {VglRS}
Es sind v1 und v2 die zu vergleichenden Datensätze und ikzl die Namenskürzel darin sowie iclub sekundäre Namenskürzel, die gegenwärtig noch nicht verwendet werden, also immer leer sind. Die Funktion KzlKleiner gibt zurück 1 für v1 > v2, 0 für v1 = v2 und -1 für v1 Die Baum-Unit umfasst 272 Zeilen mit den Prozeduren und Funktionen
FindNode, FirstNode, LastNode, NextNode, PrevNode, DelNode, PutBack, Swap, NewTree, InsVar, NewNode, FirstVar, LastVar, NextVar, PrevVar, FindVar, DelVar und DisposeTree.
Sind davon welche für die Beurteilung von Bedeutung?
Ausgangsdaten: Die sind hundertprozentig gleich, weil sie vor meinen Operationen jedes Mal vom Original- in den Verwendungs-Ordner kopiert habe. Und auch der Ablauf war jedes Mal gleich.
Gibt es eine Erklärung?
Schönes Wochenende!
(Morgen werde ich nicht an den Computer kommen.)
dromedar
