Programmieren - alles kontrollieren 4.937 Themen, 20.662 Beiträge

DOS-Programm: Sortier-Ergebnisse weichen von einander ab

dromedar / 14 Antworten / Flachansicht Nickles

Immer noch arbeite ich an und mit einem DOS-Programm, erstellt mit Turbo-Pascal 7.0. (Leider kenne ich nichts, was eine Umstellung auf Windows (Delphi) halbwegs automatisch ermöglicht.)
Auf meinem neuen Computer (Windows XP Prof.) stelle ich nun fest, dass Sortier-Ergebnisse, Ablauf mit denselben Daten auf demselben Weg, von einander abweichen: Mal sind sie in Ordnung, mal ist die Sortierung fehlerhaft. Kann die Ursache dafür sein, dass der Computer wegen seiner höheren Geschwindigkeit die Ursache dafür ist? Wenn ja: Wie kann ich diese für DOS-Programme drosseln? Oder wo kann die Ursache sonst liegen?
Für Hilfe wäre ich sehr dankbar.

bei Antwort benachrichtigen
Andreas42 dromedar „Hallo Helfer, vielen Dank für Eure Antworten. Hier die zu meiner Frage...“
Optionen

Hi!

Ich gehe mal auf meine Rückmeldungen ein.

Der Punkt Patch der Zeitmessung in der Runtime-Libray von TurboPascal ist z.B. hier beschrieben:
http://www.webplain.de/turbopascal/error200.php

Die ursprüngliche Version der CRT-Bibliothek brach mit einem Error 200 auf CPUs mit mehr als 200MHz ab.

Ich setze einen Patch aus der c't ein:
http://www.heise.de/ct/hotline/Nicht-schon-wieder-Runtime-Error-200-307662.html
Bzw. ich nutze Borland Pascal 7.0 da war der Quelltext der CRT-Bibliothek im Lieferumfang und man konnte die Stelle entsprechend ändern und neu kompilieren.

Meinen zweiten Beitrag mit der theoretischen Betrachtung kannst du igrnorieren. In solchen Fällen kommt man mit der Theorie nicht weiter, da muss man die reale Implementierung betrachten.
Oder um es noch etwas überspitzter zu formulieren: es gibt keinen Programmfehler, der sich für Theorien oder Verträge interessiert und diese in seinem Verhalten berücksichtigt. ;-)

Danke für den Quelltext. Das erleichtert die Betrachtung.

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}

Auf den ersten Blick ist allerdings nichts zu erkennen, was da zu Unschärfen führen sollte. Eine Anmerkung habe ich allerdings: ich finde es ungünstig, das die Parameter von VglRS untypisierte Zeiger sind und dann der zugewiesene Speicher mehr oder weniger "blind" in echte Objekte (oder Records) kopiert wird.

Ich hätte p10 und p20 als Zeiger vom Typ v_ispieler_m deklariert, da hätte man sich die Kopieroperation mit move(..) sparen können. Damit umgeht man jede Typprüfung von TurboPascal. Da könnte ich jetzt nicht garantieren, dass das wirklich CPU- und plattformunabhängig klappt. Es sollte, aber wer weiss das schon wirklich?

VglRS := t(rue) ist die Vorbelegung bzw. initialisierung des Rückgabeergebnisses.
Das wird zurück gegeben, wenn der Vergleich ein Kleiner zurückliefert (-1) oder wenn das Ergebnis Gleich ist. Für die restlichen Ergebnisse (also +1) wird f(alse) zurückgegeben.

OK, das würde passen. Bei kleiner oder gleich muss nicht getauscht werden. (Ich vermute du nutzt ein Bubblesort das darauf basiert zwei Objektinstanzen zu vergleichen und bei Bedarf zu vertauschen.)


Was genau meinst du mit dem "Datensatz mit ZIP"? (ZIP-Postalcode?) Sortierst du da Adressen und Namen? Ist das reproduzierbar?


Deine Funktion VglRS(..) scheint mir bisher einfach nur die Funktion KzlKleiner(..) zu kapseln. (Sie ist eine Funktion, die einen Grösser/Kleiner-Vergleich durchführt udn dazu eine Funktion aufruft, die einen Grölsser/Kleiner-Vergleicht durchführt aufruft.)

Falls das Problem im Grösser/Kleiner-Vergleich liegt, dann müsste man sich die Funktion KzlKleiner(..) ansehen.

Die Funktion Swap(..) dürfte zwei Elemente tauschen, vermutlich nach dem Vergleich. Ein Bubblesort erfordert ja bei n zu sortierenden Elementen, n Durchläufe durch den Array. Zu Beschleunigungszwecken geht man dann davon aus, dass nach jedem Durchlauf (i) die ersten i-1 Elemente bereits korrekt sortiert sind und fängt daher mit dem i-ten Element in der Liste an (vergleicht es mit dem Element i-1) und arbeitet sich zum Ende der Liste durch.
Wenn da das Startelement des jeweiligen Durchlaufs falsch bestimmt wird, dann kann es "vergessene" Element in der resultierenden Liste geben.

Wie genau arbeitet deine Sortierung?

Bis dann
Andreas

Hier steht was ueber mein altes Hard- und Softwaregedoens.
bei Antwort benachrichtigen