Delphi-Laie - Do 08.10.09 21:23
Titel: Sortierkino - Visualisierung diverser Sortieralgorithmen

---

Hallo Delphianer und vor allem diesmal konkret Sortierfreunde!

Es ist mal wieder soweit, hier ist das Ergebnis meiner Hobbyprogrammiererei der letzten Monate: Visualisierte (oder noch genauer: animierte) Sortieralgorithmen.

Bekannt sind diese Algorithmen natürlich (und das Thema mag so mancher als abgedroschen empfinden), jedoch gefiel mir die graphische Umsetzung derselben, die ich bislang fand, nicht.

So wird zum einen oft der Bildschirm nicht ausgenutzt, was die mögliche Elementanzahl verringert. Zum anderen halte ich Balken-/Liniendarstellungen für prägnanter als schnöde Pixel. Dann liegen oft nur Zufallspermutationen (einer aufsteigenden Menge) oder Zufallszahlen als zu sortierende Startmengen zugrunde. Das alles habe ich etwas erweitert, um ein wenig „Kinogefühl“ aufkommen zu lassen. Die Bedienung des Programmes ist m. E. so simpel und intuitiv möglich, daß es nicht weiter beschrieben werden muß.

Mein Interesse lag zuvörderst bei solchen Sortieralgorithmen, bei denen die Visualisierung wenigstens halbwegs erkennen läßt, was intern abläuft. Die temporäre Nutzung zusätzlichen Speichers wie bei den klassischen Mergesorts und bei den Bucketsorts wird nicht visualisiert, sondern eben nur das, was in und mit der „Hauptmenge“ geschieht. Desweiteren beschränkte ich mich wegen der Darstellungsorientierung auf die Sortierung linearer, d.h. eindimensionaler Datenmengen, also Arrays (die Werte werden, entsprechend ihrer Größe, natürlich als verschiedenlange Balken dargestellt).

Einbezogen habe ich alle Komplexitätsklassen dieser Algorithmen, was sich auch in der Laufzeit bemerkbar macht, ohne jedoch die Algorithmen nach Komplexitätsklasse vorzuselektieren oder zu ordnen (nur alphabetisch nach Namen). Eingeweihte wissen ohnehin bescheid. Das wären:

1. Die absolute Katastrophe: Erst (jeweils zwei Elemente) tauschen, dann die gesamte Elementemenge auf Sortierheit prüfen. Doch auch diesem Vorgehen ist letztlich die Systematik nicht abzusprechen und führt - genug Zeit und Ausdauer vorausgesetzt - irgendwann sicher zum Ziele. Ich empfehle aber, für den Sortiererfolg es mit Elementeanzahlen maximal 10 zu versuchen, dann wird das Darstellungsfenster aber sehr klein. Vertreter: Bogo- und Bozosort.
   
   
2. Von der Laufzeit her schon um Größenordnungen besser, aber immer noch grottenschlecht sind bestimmte rekursive Algorithmen: Slow- und Trippelsort.
   
   
3. Die klassischen („elementaren“) Algorithmen, die letztlich, im maximalen Fall, jedes Element mit jedem (anderen) vergleichen (mit der Elementeanzahl quadratisch wachsende Vergleichsanzahl) und bei Bedarf tauschen (so z.B. Bubble-, Insertion-, Oet- und Shakersort). Ein wenig aus dem Rahmen fallen Selektion- und Plaselsort, die zwar auch zu dieser Klasse zählen, jedoch geschickterweise die Anzahl der Vertauschungen auf das nötige Maß minimieren, so daß deren tatsächliche Geschwindigkeit bei den im Vergleich zu in der Praxis zu sortierenden Mengen nur erklecklichen Elementeanzahlen, die Bildschirmspalten zulassen, erstaunlich hoch ist.
   
   
4. Verbesserte, d.h. asymptotisch gute Algorithmen wie z.B. Shell-, Gap- und Shearsort.
   
   
5. Asymptotisch optimale Sortieralgorithem wie z.B. Quick-, Heap- und Mergesort. Vom Heapsort habe ich Dijkstras Smoothsort und von den diversen Mergesorts auch bitonische und Varianten mit iterativen „In-Place“-Veschmelzungen dabei (die benötigen also kaum zusätzlichen Speicherplatz, vor allem keinen Stack), s.u. .
   
   
6. Die schnellsten Algorithmen sind spezielle Sortieralgorithmen (Bucketsorts), kommen ohne Vergleiche aus, setzen jedoch voraus, daß die Anzahl der möglichen Werte endlich ist (das ist z.B. bei Integervariablen der Fall): Beadsort, Distribution Counting und - mit deutlichen Abstrichen wegen mehrerer, bitbezogener Schleifendurchläufe - Strait Radix Sort.
   

Als Schmankerl habe ich optional bei Mergesort und Naturalmergesort das “In-Place-Mergen” nach der Idee Siegfried Sielaffs („Simplewapsort“) implementiert, mich jedoch mit der Rekursion desselben nicht zufriedengegeben, sondern es nach der Idee Robert Sedgewicks analog seinem Quicksort iterativ umgestaltet, wobei ein eigens dafür genutztes Datenfeld namens Stack letztlich den Stack emuliert und der deshalb als Namenspatron herhalten mußte, jedoch deutlich weniger (Haupt-)Speicher, als was vom Stack benutzt würde, verbrauchen und zudem laufzeitgünstiger sein dürfte:

Somit enthält mein Programm einen Sortieralgorithmus, der bei dem heutigen Softwareniveau (meine ich positiv!) als optimal angesehen werden kann:

• allgemeingültig i.d.S., daß alle Werte (und eben nicht nur integre) können sortiert werden,
  
• stabil (d.h., wertgleiche Elemente werden nicht vertauscht, deren ursprüngliche Reihenfolge bleibt also im Verlaufe der Sortierung enthalten),
  
• (vermutlich, wäre noch nachzuweisen) laufzeit- bzw. geschwindigkeitsoptimal (n*log(n)), vielleicht aber doch nur asymptotisch gut analog Bitonic Sort,
  
• „intelligent“ genug, (vor-)sortierte Mengen zu „erkennen“, indem er darauf mit einer Laufzeitverkürzung „reagiert“,
  
• nur iterativ, keine Rekursion und
  
• (fast) kein zusätzlicher Speicher wird benötigt, insbesondere der etwas heikle Stack wird geschont.

All' diese Eigenschaften besitzt das Natural Mergesort mit dem iterativen In-Situ-Verschmelzen.

Die langsam(st)en Algorithmen lassen sich mit ESC abbrechen, während die optionale Bremse bei den schnell(st)en Algorithmen eingefügt wurde. Wessen Computer andere Geschwindigkeiten hat/haben, der kann und möge das natürlich entsprechend anpassen, Quelltexte liegen ja mit bei.

Angefangen hatte ich mit Delphi-2 (igitt), bei dem die Arrays im Quelltext entsprechend den einmal einzugebenden Bildschirmkoordinaten (bei mir 1600x1200) vor der Compilierung statisch zu dimensionieren sind. Das ist natürlich völlig veraltet, so daß ich in Richtung Delphi 4 aufbohrte: Eines mit einmaliger Arraydimensionierung während des Startes und eines, das die Arrays entsprechend der eingestellten Darstellungsfenstergröße automatisch während der Laufzeit anpaßt (was aber nicht optimal sein soll).

Meine wichtigsten Quellen der Algorithmen waren das Werk „Algorithmen und Datenstrukturen“ von Robert Sedgewick sowie die sehr umfangreiche Internetseite zu Sortieralgorithmen von Peter Weigel: http://home.arcor.de/peter-weigel/sortieralgorithmen (die schaltete er dankenswerterweise privat wieder frei, nachdem die von ihm vor einigen Jahren abgegebene http://www.sortieralgorithmen.de seit Monaten nicht mehr erreichbar ist). Zusätzlich fand ich im Internet noch die eine und andere gute Idee. Von mir stammen nur die trivialen Varianten (nicht das Original) des Bozosorts sowie die Nach-Delphi-Portierung des In-Place-Mergens. Deshalb ist das Programm natürlich komplett frei. Sollte noch jemand eine gute Idee für einen visualisierungswerten Algorithmus haben, dann her damit, oder er baut ihn sich selbst ein.

Trotz aller akribischer Proben und Kontrollen kann ich bei Programmen dieser Größe Fehler leider nicht ausschließen, würde mich aber über diesbezügliche Rückmeldungen dankend freuen.

Auch als Demonstrationsprogramm z.B. für den Informatikunterricht kann ich mir dieses Programm gut vorstellen. Zudem sind Sortieralgoritmen die im wahrsten Sinne des Wortes offensichtliche Widerlegung der immer noch zu findenden pauschalen und damit falschen Behauptung, Algorithmen seien „Rechen- bzw. Berechnungsvorschriften“.

Kleiner Tip: Swirlsort mit der Werteerzeugung "natürliche Zahlen (je einmal) und der Startmengenstruktur „Aufsteigend, größtes Element vorn“ starten - ich wette, daß so etwas noch niemand von Euch je gesehen hat!

Viel Spaß!

Delphi-Laie

Edits bitte unter http://www.delphipraxis.net/141427-sortierkino-visualisierung-diverser-sortieralgorithmen.html nachlesen, weil die hiesige Forensoftware sonst mit der Größe dieses Beitrages nicht klarkäme.

Delphi-Laie - Di 20.10.09 23:05

---

Und jetzt die Zugabe - die Farbvariante der drei o.a. Programme!

Damit schleppt jeder Wert im Verlaufe der Sortierung anhand seiner Farbe seine (ungefähre) Startposition mit sich umher.

Auf diese Weise ist es möglich, die (In-)Stabilität mancher Sortieralgorithmen optisch wahrzunehmen. Dazu empfehle ich die letzte Startmenge - die mit zwei konstanten Teilmengen, abfallend.

Achtung: Diese Farbzuordnung funktioniert nicht bei den speziellen Sortieralgorithmen (Bucketsorts): Beatsort, Distribution Counting und Straight Radix Sort, d.h. konkret, die Farbzuordnung bleibt im Verlaufe der Sortierung nicht erhalten/enthalten. Die Endfärbung der sortierten Menge ist gleich kontinuierlich wie die Startfärbung.

Vielleicht meldet sich ja diesmal ein glücklicher Finder irgendeines (oder mehr als eines) Fehlers.

Viel Spaß erneut oder weiterhin!

Delphi-Laie

Edit: Beide Quicksorts beschleunigt: Tausch nur noch nach Schlüsselvergleich. Damit vermischen beide Algorithmen die Elemente gleichgroßer Schlüssel auch nicht mehr unkontrolliert, sondern werden wenigstens „invers stabil“ (=bei Elementen gleichgroßer Schlüssel wird deren Reihenfolge invertiert).

Edit 2: Borderstyle vom Sortierformular so geändert, daß es nunmehr ein echtes Fenster (also mit Rahmen) ist. Mit dem Setzen des Formstyles des Sortierformular auf fsStayOnTop sollen zudem die störenden Neuzeichnungen anzahlig zurückgedrängt werden.

Edit 3: Swirlsort korrigiert (Farbinformation blieb im Verlaufe der Sortierung nicht erhalten).

Edit 4: Subtilen Fehler bei der Bestimmung der maximalen Spalten- und Zeilenanzahl im Fenstermodus beseitigt (?). Funktionierte nicht richtig, nachdem das Formular 2 (zum Sortieren) schon mal visible war bzw. benutzt wurde.

Edit 5: Insertionsort beschleunigt (zyklisches Verschieben anstatt häufigen Vertauschens). 2 weitere Insertionsorts hinzugefügt (Variante 3 zeigt ziemlich selten einen nicht reproduzierbaren Fehler). Das Sortierformular, sofern als Fenster benutzt (also mit Rahmen), behält nunmehr seine Position, zu der es verschoben wurde (vorher immer Bildschirmzentrierung desselben).

Edit 6: Subtilen Fehler bei der Generierung der Startmenge „2 separate absteigende Teilmengen“ korrigiert. Dynamische Längenanpassung der (zu sortierenden) (Haupt-)Menge korrigiert.

Edit 7: Anhänge gelöscht, weil beide Programmversionen verein(ig)t wurden - siehe vorherigen Beitrag.

Horst_H - Mi 21.10.09 16:37

---

Hallo,

das sieht ja mächtig bunt aus und manchmal ist es auch stabil.
Vielleicht habe ich es übersehen, aber wäre ein Zähler für Vergleiche und Vertauschungen machbar?
Vielleicht in einer Unterabteilung als Vergleich verschiedener "vernünftiger" Sortierverfahren.
Wenn Du es richtig eilig hast, könnte das Zeichnen horizontaler, statt vertikaler, Linien schneller sein.

Gruß Horst

Delphi-Laie - Mi 21.10.09 22:59

---

Danke!

Horst_H hat folgendes geschrieben :

das sieht ja mächtig bunt aus

Mächtig bunt? Mächtig bunt sind die Haribobtüten aus Redmond.

Ich verwandte von den Basisfarben die beiden dunkleren mit zwei gegenläufigen Gradienten, um die (ungefähre) Startposition zu erhalten. Das ist nicht mehr bunt als nötig! Für „mächtig bunt“ fehlt die dritte Grundfarbe! Ansonsten die Schwarz-Weiß-Variante, die diese Informationen aber nicht bieten kann (und man damit die (In-)Stabilität nicht verfolgen läßt).

Horst_H hat folgendes geschrieben :

und manchmal ist es auch stabil.

Manchmal? Wann und wann nicht? In welcher Weise „nicht stabil“? Das ist mir für eine Fehlerbeschreibung viel zu unsubstantiiert.

Falls Du die Störungen im Bildschirmaufbau meinst, dazu schrieb ich am andern Ort:

„Vermutlich ein von Windows verursachten Neuzeichnen. Habe mich damit wirklich lang beschäftigt. Also, ein solches Ereignis sollte die bis dato temporär sortierte Menge (von mir programmiert) neuzeichnen lassen, so meine Idee. Dazu hätte das Sortieren unterbrochen werden müssen. Ein extra Thread drängte sich geradezu auf (meine erste Begegnung mit Threadprogrammierung). Nur, zwei Threads, die auf ein Formular zugreifen, benötigen Synchronize (sonst Abstürze oder anderes unkontrollierbares Verhalten). Der Sortierthread ist jedoch voll ausgelastet, und Synchronize lähmt damit auch den anderen, eigentlich das Ereignis überwachenden (und ggf. die Sortiermenge neuzeichnenden) Thread. Pustekuchen, damit war ich mit meinem Latein am Ende. Sonst hatte ich bis Delphi immer meine Wünsche erfüllt bekommen, doch das war das erste Mal, daß ich an dessen Grenzen geriet (oder kennt jemand eine Lösung?). So blieb es beim Neuzeichnen der Sortiermenge nach Ende des Sortierens.“

Horst_H hat folgendes geschrieben :

Vielleicht habe ich es übersehen, aber wäre ein Zähler für Vergleiche und Vertauschungen machbar?

Bläht den Quelltext deutlich auf, für das Laufzeitverhalten allerdings eher irrelevant. Einen Schleifenzähler fügte ich nur den beiden schlimmsten Algorithmen, dem originalen (d.h. unbeschleunigten) Bogo- und dem ziemlich ähnlichen orginalen, also ebenso unbeschleunigten Bozosort hinzu.

Doch nicht alle Sortierungsalgorithmen sind so simpel, nur auf Vergleichen und Vertauschungen aufzubauen, Stichwort: Spezielle Sortieralgorithmen, aber auch Heap- und Smoothsort. Besser wäre es wohl auch nicht mit AVL- und B-Sort, die ich nicht implementiert bekomme. Nicht umsonst habe ich Prozeduren namens Verschiebe und Einzelwertverschiebe dabei!

Aussagekräftig wären solche Werte nur, wenn man sie vergleicht. Also erstmal irgendwo abspeichern. Von einer Messagebox aus lassen sie sich nicht kopieren. Also in ein Editfeld oder, noch besser, in ein Memo oder eine Stringliste hineinschieben? Mir alles viel zu umständlich - es sprengt den Rahmen eine Sortierdarstellungs- bzw. visualisierungsprogrammes bei weitem!

Horst_H hat folgendes geschrieben :

Vielleicht in einer Unterabteilung als Vergleich verschiedener "vernünftiger" Sortierverfahren.

Für Lehrzwecke ist alles „vernünftig“. Als Nichtinformatiker lehne ich mich nicht so weit hinaus, hier Festlegungen zu treffen. Die Anforderungen an Sortieralgorithmen sind in der Praxis auch unterschiedlich, so daß es hinsichtlich der Umgebung(sbedingungen) geeignetere und weniger geeignete gibt.

Horst_H hat folgendes geschrieben :

Wenn Du es richtig eilig hast, könnte das Zeichnen horizontaler, statt vertikaler, Linien schneller sein.

Wenn man es eilig hat (keine günstige Voraussetzung für ein „Kurzfilmkino“!), bricht man ab und verkleinert das Fenster vor der nächsten Darstellung. Da Monitore eher breit als hoch sind, schränkt, Dein Vorschlag angewandt, das die Maximalanzahl darstellbarer zu sortierender Elemente (darauf kam es mir an, s.o.) unnötig ein.
Unsere Augen (Gesichtsfeld) als auch unser Gehirn sind zudem für die Wahrnehmung horizontaler Bewegungen besser geeignet.

Gruß Delphi-Laie

Delphi-Laie - Fr 23.10.09 15:59

---

Nach diversen kleinen Fehlerbehebungen habe ich meinen Programmen nunmehr eine kleine funktionale Erweiterung spendiert: Beim Sortierformular änderte ich den Borderstyle so, daß es nunmehr ein echtes Fenster (also mit Rahmen) ist.

Wird die Anzahl der Zeilen und Spalten hinreichend klein gewählt, sodaß das Formular auch mit Rahmen in den Bildschirm paßt, dann wird der Fenstermodus automatisch, also immer zugeschaltet (was mir auch sympathischer ist). Ist das Sortierformular gleich groß oder nur unwesentlich kleiner als der Bildschirm, sodaß der Fensterrahmen eigentlich nicht mehr hinzupaßt, dann läßt sich der Fenstermodus jedoch erzwingen - was dann aber geringfügig zu Lasten der verfügbaren Spalten- und Zeilenanzahl und damit der Anzahl der zu sortierenden Elemente geht. Der (logischerweise rahmenlose) Vollbildmodus ist also weiterhin möglich.

Delphi-Laie - Sa 07.11.09 18:35

---

So, zum (vorläufigen?) Finale die absolute Krönung: Die beiden (derzeit) schnellsten (allgemein anwendbaren) Sortieralgorithmen AVL- & B-Sort (vorgestellt von Peter Weigel auf Sortieralgorithmen(.de) [http://home.arcor.de/peter-weigel/sortieralgorithmen]) fügte ich in mein Programm ein!

Optisch sind diese zwar kein Hochgenuß/Leckerbissen, bedienen dafür aber alle Komplexitäts- und Geschwindigkeitsfanatiker. Schon die Visualisierung läßt erkennen, daß sie in einer anderen Liga als Heap-, Merge- und sogar Quicksort spielen und eher der Geschwindigkeit der speziellen Sortieralgorithmen bzw. Bucketsorts entsprechen.

Auch an dieser Stelle danke ich dem Forum http://www.planet-quellcodes.de, dort speziell der Delphi/Kylix-Rubrik, wo das schon vor Jahren mal (erfolglos?!)thematisiert wurde, ich das deshalb dort wieder aufgriff und man mich bei der Portierung von C nach Objektpascal massiv unterstützte.

Niko S. - So 15.11.09 14:54

---

Weiß nicht ob das jetzt schon genannt wurde, ist auch nur ein visueller fehler,
Der Beadsort hat irgendwie einen schönen farbverlauf wenn er fertig mit sortieren ist anders als die anderen Verfahren ;x
Bei Distribution Counting das selbe
Bei Strait Radix ebenfalls
Bei Slowsort friert das programm ein

Horst_H - So 15.11.09 17:37

---

Hallo,

ich möchte nur anmerken, dass die Laufzeit der Verfahren nicht unbedingt etwas mit der Laufzeit der visuellen Darstellung zu tuen haben, da nur Tauschungen dargestellt werden.
Selection-Sort ist von der Laufzeit her quadratisch in n, läuft aber fixer als heap-Sort in der Visualisierung, da ja genau einmal pro Durchgang getauscht wird, ist also von daher also optimal.
Die Vergleiche fehlen.
Beim AVL Baum sieht die Visualisierung aus, wie Selection-Sort.Da erkenne ich keinen inneren Ablauf des Verfahrens bei der Visualisierung.
Vielleicht ähnlich:
http://www.inf.ethz.ch/personal/staerk/algorithms/SortAnimation.html

Also neben jedem Wert eine Spalte, sodass zum Beispiel neben dem Wert1 gegen den gerade verglichen wird, ein gelber Strich auftaucht und neben Wert2 ein grüner.Der rote Strich neben dem Wert der fertig positioniert ist.Das müsste bei Quick-Sort das Partitionieren noch anschaulicher machen können.

Aber Heap/AVL lässt sich auch schlecht darstellen, da ja die Baumstruktur nicht zu sehen ist.

Übrigens sieht OetSort bei mir einfach phantastisch aus :-)

Gruß Horst

Delphi-Laie - So 15.11.09 18:09

---

Danke für Eure Reaktionen!

Niko S. hat folgendes geschrieben :

Weiß nicht ob das jetzt schon genannt wurde, ist auch nur ein visueller fehler, Der Beadsort hat irgendwie einen schönen farbverlauf wenn er fertig mit sortieren ist anders als die anderen Verfahren ;x Bei Distribution Counting das selbe Bei Strait Radix ebenfalls

Das schrieb ich oben, ist aber zugegebenermaßen bei der Fülle der Informationen (wer liest das?) leicht zu überlesen: Die speziellen Sortieralgorithmen können die Farbinformation nicht behalten. Das ist weder ein Fehler in meinem Programm noch in den Algorithmen, sondern liegt am Wesen dieser Algorithmen selbst. Mit der Schwarz-(Weiß-)Variante (Farbe abschalten) ist diese gewisse Fehlerhaftigkeit natürlich beseitigt. Ich kann natürlich die Option automatisch umschalten (lassen), doch dann muß der Nutzer danach den - anzunehmenderweise eher gewünschten - Farbverlauf explizit wieder zuschalten. Hat also alles zwei Seiten.

Niko S. hat folgendes geschrieben :

Bei Slowsort friert das programm ein

Nein, tut es nicht, ganz im Gegensatz: Es ist intern, im Hintergrund (nämlich in Form ständiger Stackbeschäftigung) tüchtig am Rödeln und Werkeln, doch das wirkt sich nicht erkennbar auf den Sortierungsfortschritt aus. Es hat doch eine selbsterklärende Bezeichnung. :wink: Für derartige Algorithmen am besten wesentlich kleinere Auflösungen (konkret Spaltenanzahl), als der Bildschirm bietet, wählen!

Zu Horst:

Ich hatte AVL- und B-Sort aus Sportsgründen später mit eingefügt. Eingangs schrieb ich, daß ich mich auf die Algorithmen konzentriere, bei denen man halbwegs nachvollziehen kann, wie die funktionieren, was intern abläuft. Da müssen Algorithmen, die die Daten intern in Baumstrukturen anordnen, natürlich passen. Nur bezüglich der Geschwindigkeit sind Sie doch anschaulich.

Apropos Geschwindigkeit. Ja, ich weiß, daß das Laufzeitverhalten letztlich eine Funktion über der Anzahl, der Menge, der Größe, der Komplexität der Eingangsdaten ist. Select(ion)sort ist auch nur elementar und damit von quadratischer Laufzeit, jedoch mit einer sehr geringen Konstante, so daß bei einer Elementeanzahl, die im Bereich der Bildschirmspalten liegt, keine solche Quadrazität gefühlt wird.

Die Zielstellung temporären Farbdarstellungen dürften an der Geschwindigkeit scheitern. Sobald man allerdings die Bremse ein wenig überzieht (deswegen mein diesbezüglicher warnender Hinweis auf dem Formular), wird es quälend langsam. Mag sein, daß man Quicksort damit noch anschaulicher gestalten kann, nur ist es das Ziel meines Programmes, eine möglichst große Bandbreite von Sortieralgorithmen darzustellen: Nicht alle Algorithmen funktionieren auf der Basis von Vergleichen und/oder Vertauschungen.

Delphi-Laie - Fr 25.02.11 15:50

---

Horst_H hat folgendes geschrieben :

Hallo, das sieht ja mächtig bunt aus

Richtig bunt ist es (erst) ab heute. Auch ansonsten tat sich (bzw. ich) mit dem Programm in der geraumen Zwischenzeit noch so einiges, wenn nicht gar eine ganze Menge...

Horst_H - Sa 26.02.11 12:27

---

Hallo,

jetzt weiß ich wenigstens, warum die Farben manchmal so schön bleiben, Bei beadsort und countsort ..
Dort wird nur der Wert/Schluessel rekontruiert, aber nicht die startpos, die für die Farbe verantwortlich ist, was dort ja auch grundsaätzlich nicht geht.
Ich habe mal eine Versuch gemacht, indem statt startpos der Schluessel die Farbe bestimmt.
Ich habe den Record von Menge um col==Farbe erweitert, damit das nur einmal gerechnet werden muss und bei linie_zeichnen einfach genutzt werden kann.
Ich erstelle eine aufsteigend sortierte Folge.

die anschliessend ala Fisher-Yates? gemischt wird.
Alle Sortierverfahren, die die procedure tausche(x,y) nutzen, sortieren dann farblich anschaulich richtig.
Dabei sieht man auch, das AVL-sortiert nicht "stabil" ist, weil gleiche Werte ihre Reihenfolge gewechselt und damit die Farbfolge irgendwie nicht passt. wohingegen selectionsort "stabil" ist.
Um das noch anschaulicher zu machen habe ich bei der Farbauswahl nur schwarz einfach alternierend grün/rot genommen.

Gruß Horst

Delphi-Laie - So 27.02.11 19:16

---

Hallo Horst, danke! Schön, daß wenistens Du mir die Treue hältst!

Horst_H hat folgendes geschrieben :

Hallo, jetzt weiß ich wenigstens, warum die Farben manchmal so schön bleiben, Bei beadsort und countsort ..

Ich schrieb das bereits oben (allerdings ist es zugegebenermaßen doch sehr viel Text geworden): Die speziellen Sortieralgorithmen zählen einfach nur, von welchem - vorher bekannten!, weshalb es sie wohl (fast?) nur bei integren Größen gibt - Wert jeweils wieviele Exemplare existieren. Damit sind Sortierelement gleichbedeutend mit Sortierschlüssel. Zusätzliche Informationen der Sortierelemente können nicht mit transportiert werden.

Ich sehe aber ein, daß die Farbverläufe bei jenen nach der Sortierung zu Irritationen und Fehlervermutungen führen können, weshalb die Sortierung dieser speziellen Sortieralgorithmen nur noch in/mit Schwarz visualisiert wird. Ich probierte es früher schon, kam aber nicht weiter. Nunmehr gelang es mir aber doch, das so zu implementieren/programmieren, daß es plausibel erscheint (vorher erzeugte die Neuzeichnenprozedur wiederum farbige Balken, was ebenso irritierend gewesen wäre). Leider waren auch in meiner neunen Version wiederum doch einige Fehler (komischerweise auch solche, die eigentlich schon korrekt erstelltem Programmcode entsprachen). Nun müßte es wiederum etwas besser sein, falls nein, freue ich mich über jeden Fehler- oder anderweitigen Verbesserungshinweis. Allmählich wage ich die Vermutung, daß es weltweit kaum noch bessere Sortieralgorithmenvisualisierungen gibt (geben dürfte).

Horst_H hat folgendes geschrieben :

Ich habe mal eine Versuch gemacht, indem statt startpos der Schluessel die Farbe bestimmt. Ich habe den Record von Menge um col==Farbe erweitert, damit das nur einmal gerechnet werden muss und bei linie_zeichnen einfach genutzt werden kann. Ich erstelle eine aufsteigend sortierte Folge. Delphi-Quelltext 1: 2: 3: 4: 5: For x := 0 to pred(Spaltenanzahl) do begin   Menge[x].Startpos := x;   Menge[x].Schluessel := x * Zeilenanzahl DIV Spaltenanzahl;// Da Zeilenzahl meist kleiner Spaltenzahl , ergeben sich doppelte Werte ( bei mir 1080 /1920 also etwa 44 % )   Menge[x].col := f(Schluessel, Ausgewähltes Farbspectrum);   end; die anschliessend ala Fisher-Yates? gemischt wird.

Du gehst ja vehement an diese meine Sache.... Alle Achtung....wenn ich mal diese Ausdauer und Voraussetzungen hätte, mich in fremder Leute Quelltexte einzulesen.... Diese ständige und teilweise eigentlich redundante Rechnerei vor jedem Liniezeichnen gefiel mir auch von Anfang an nicht (allerdings sind das alles doch ziemlich schnelle Integeroperationen), aber die Farbe mitzutransportieren, ging ich als Herausforderung noch nicht an. Allerdings dürfte das Tauschen der Sortierelemente, wenn diese größer werden, die Algorithmen auch eher verlangsamen. In der Praxis sind die Sortierelement meistens ziemlich groß und komplex, so daß i.d.R. wohl nur die Zeiger bzw. Indizes verändert/getauscht/verschoben werden. Doch um 'all das ging und geht es mir nicht, sondern um die Visualisierung. Bei einem Programm dieser Größenordnung - mit dem man allerdings "mitwächst" - bin ich als Laien-Freizeit-/Hobby-Programmierer ohnehin immer an der oberen Grenze meines Könnens und meiner Überschaufähigkeiten, so daß ich jede weitere Verkomplizierung und Quellcodevergrößerung vorher ernstlich bedenke und abwäge.

Delphi-Laie - Mo 28.02.11 20:58

---

Hallo Horst!

Zufallspermutationserzeugung nach Fisher-Yates sowie die Farbberechnung nunmehr schon bei der Erzeugung der Startmengen (es bleibt dabei: Jedem Balken seine eigene Farbe) sind jetzt implementiert. :D

Danke für diese Deine Anregungen!

Horst_H - Di 01.03.11 09:00

---

Hallo,

das ist noch nicht so,wie ich mir das vorstellte.
Am Ende sollte die Sortierung farblich harmonisch sein ;-)
In der procedure Mischen hab ich direkt zu Beginn die Farben zugeordnet.
Die Farbzuordnung zum Schluß kann dann weg.

Mit Fisher-Yates soll es dann gemischt werden, das ist schon dann schon Zufall.

Die Lazarusversion bleibt bei mir oft hängen :-(
Ab Version 9.29 ? muss in der *.lpr
//{$IFDEF WIN32}{$R Sortierkino_Lazarus_statische_Arrays.rc}{$ENDIF}
auskommentiert werden.

Gruß Horst

Delphi-Laie - Di 01.03.11 12:05

---

Horst_H hat folgendes geschrieben :

Hallo, das ist noch nicht so,wie ich mir das vorstellte. Am Ende sollte die Sortierung farblich harmonisch sein ;-) In der procedure Mischen hab ich direkt zu Beginn die Farben zugeordnet. Die Farbzuordnung zum Schluß kann dann weg.

Gut, das Prinzip klar. Eben war ich noch fast geneigt, das als (Farb-)Spielerei abzutun, besann mich aber daran zurück, warum ich die Farbvariante einführte. Analogieschluß: Dann kann man vor der Sortierung schon erkennen, wo das Sortierelement am Ende der Sortierung stehen sollte, besser muß, und hat dann am homogenen Farbverlauf eine zusätzliche Bestätigung der Korrektheit des (jeweiligen) Algorithmus' (man sieht das aber auch an der oberen Linie). Doch das kann man doch anhand der Länge, die symbolisch und und als Maß für die Größe des Sortierschlüssels steht, schon erkennen. Mir ging es ursprünglich darum, daß das Sortierelement die Information über seine Startposition im Verlaufe der Sortierung behält ("mit sich herumschleppt"). Da die Längen der Balken das nicht können, blieb die positionsabhängige Einfärbung als einzig mir noch möglich erscheinende Visualisierungsinformation übrig.

Also, das entspricht nicht meiner Intention, aber da ich meinen Quelltext zur Verfügung stelle, sind Veränderungen/Erweiterungen jederzeit möglich.

Horst_H hat folgendes geschrieben :

Die Lazarusversion bleibt bei mir oft hängen :-( Ab Version 9.29 ? muss in der *.lpr //{$IFDEF WIN32}{$R Sortierkino_Lazarus_statische_Arrays.rc}{$ENDIF} auskommentiert werden.

Was bleibt hängen - das Compilieren oder das Laufenlassen der Compilate?
Version 0.28.2 compiliert bei mir tadellos, die - bei mir funktionierenden - Compilate liegen bei. Jedoch schafft es keine der mir vorliegenden 64-Bit-Versionen (und ich habe schon die (immer noch?) aktulle, das zu kompilieren, die Compilierung bleibt hängen, und zwar wegen der von Dir schon zitierten Zeile (wie ich in mühevoller Suche herausfand). Deshalb änderte ich den Compilerschalter auch von "Windows" nach "Win32", womit der Befehl dann natürlich ignoriert wird und nichts mehr hängebleibt. Also, Ikonen bekommt Lazarus 64 Bit immer noch nicht eingebunden. Natürlich hätte ich ikonenfreie Compilate beilegen können, doch sind die 64-Bit-Compilate ja noch ca. 1,5mal so groß wie ihre 32-Bit-Pendants.

Nach Lazarus portierte ich diese Programme, um zwei Fragen beantwortet zu bekommen, die ich beide nur mit Augenmaß (fast im wahrsten Sinne des Wortes) und "gefühlt" beantworten kann:

1. Sind Lazarus-Compilate langsamer als die des Delphis? Wann ja, dann nur geringfügig.
2. Sind 64-Bit-Compilate schneller als ihre 32-Bit-Pendants? Das untersuchte ich bisher noch weniger, aber vom ersten Eindruck her, eher noch weniger, als sich Frage 1 mit gewisser Treffsicherheit beantworten läßt.

Horst_H - Di 01.03.11 21:16

---

Hallo,

vielleicht sollte man die Startknöpfe blockieren, damit man nicht mehrere Sortiervorgänge aufruft.
Ich habe mal eine andere Art der Sortieranimation, möglichst langsam ;-)

Gruß Horst

Delphi-Laie - Di 01.03.11 21:42

---

Horst_H hat folgendes geschrieben :

Hallo, vielleicht sollte man die Startknöpfe blockieren, damit man nicht mehrere Sortiervorgänge aufruft.

Wie, was, bei meinem (meinen) Sortierkino(s)?

Dort wird doch vor dem Start der Sortierung das Sortierstartformular ausgeblendet, sodaß keine Sortierung erneut aufgerufen werden kann, solang man die alte nicht abbricht bzw. diese beendet ist.

Horst_H - Mi 02.03.11 09:57

---

Hallo,

ich kam nur drauf, weil bei mir bei der Programmausführung der Lazarusversion mit dem merkwürdigem stockendem Verhalten kam.
Die Darstellung der unsortierten Menge zu Beginn wandert gemütlich von links nach rechts. Wenn ich dann auf der Fläche klicke, wird ja wieder gewechselt,. Wenn ich dann sofort wieder auf Darstellung drücke, wird es dann mal schnell, mal garnicht mehr gezeichnet, oder eben sehr langsam.Nach klicken lande ich im Hauptmenue.
Der Thread von Form2/unit2 ist irgendwie nicht zu stoppen.

Irdgendwann ist die Zeichnerei ins Nichts beendet und es piept dann mehrfach.

Die Delphiversion macht das nicht, mit dem Klick ist die Menge auch schon angezeigt.
Einen großen Vorteil Deiner Farbgebung= Stratpos.Es ist mir erst bei der gemischten Folge zweier Werte aufgefallen.
Man sieht ob es stabil ist.Einmal AVl und einmal Heapsort.




Gruß Horst

Delphi-Laie - Mi 02.03.11 10:11

---

Hallo Horst, danke erneut!

Dieses "merkwürdige Verhalten" kann ich mit meinen Lazarus-Compilaten nicht nachvollziehen, probiertest Du meine beiligenden Compilate aus, oder ließest Du selbst compilieren? Die Darstellung der unsortierten Startmenge erfolgt bei mir in einem Augenblick, auch bei zugeschalteter Bremse (eben extra noch einmal kontrolliert, auch das mußte ich im Verlaufe der Programmierung irgendwann lösen).

Das einzige, was FPC komplett überfordert, ist das "Rumgemache" mit den Größen width/clientwidth und heigth/clientheight der Formulare, womit ich den Fenstermodus bei Bildschirm(fast)ausnutzung nicht so elegant wie in den Delphicompilaten vom Benutzern zu-/abschalten lassen kann - meine diesbezüglichen Fehlerberichte im Lazarus-Bugtrucker verliefen ergebnislos und die Menge aller meiner Fehlerberichte aus meiner Sicht immerhin noch zu geschätzen 80-90% nicht zu meiner Zufriedenheit. Deshalb ist die entsprechende Checkbox "disabled". Vielleicht schafft das auch FPC irgendwann einmal. Ansonsten haben die Compilate denselben Funktionsumfang und auch (fast) das gleiche Verhalten.

Die Stabilität sieht man am besten bei den beiden konstanten Teilmengen, die voneinander getrennt sind, und zwar links die größere und rechts die kleinere, also mit gespiegelter Startmenge.

Einen Beweis, daß ein Sortieralgorithmus auch bei beliebigen Elementeanzahlen und gar verschieden strukturierten Startmengen immer stabil ist, kann diese Veranschaulichung natürlich nicht bringen/ersetzen.

Gruß

Delphi-Laie

Horst_H - Mi 02.03.11 11:06

---

Hallo,

ich habe es extra nochmal mit den beibefügten Kompilaten getestet. Funktiniert genaus so , oder eben nicht ;-)

Zur Veranschaulichung der Stabilität reicht es.Beweisen kann man mit tausend Bildern nichts.
Wenn die Startpos in Sortierelement mit gespeichert ist, kann man aber bei beliebiger Ausgangsmenge bam Ende der Sortierung überprüfen, ob dem so war.



Gruß Horst

Delphi-Laie - Di 25.10.11 14:02

---

Horst_H hat folgendes geschrieben :

Hallo, das ist noch nicht so,wie ich mir das vorstellte. Am Ende sollte die Sortierung farblich harmonisch sein ;-)

Genau das (und noch andere Dinge) sind jetzt implementiert.

Sinnvoll ist es m.E. nicht, aber es ist schönes Futter für die Augen. :wink:

Gruß

Delphi-Laie

Mathematiker - Do 04.10.12 19:27

---

Hallo Delphi-Laie,
ich habe Deine neue Programmversion getestet.
Dabei ist mir ein kleines Problem aufgefallen. Bei der Menge "Dreieckspermutation (Spitze oben)" und binärer Vorsortierung meldet das Programm eine ungültige Zeigeroperation.
Klickt man diese weg und sortiert, so beendet sich das Programm automatisch nach dem Sortieren.
Als ich den Fehler nochmals reproduzieren wollte, ging alles gut, bis nach dem Sortieren. Dann kam eine Zugriffsverletzung bei Adresse 00401C30 und das Programm konnte nur noch über den Taskmanager geschlossen werden.

Ansonsten ist die Menge der von Dir umgesetzten Sortieralgorithmen beeindruckend.

Beste Grüße
Mathematiker

Delphi-Laie - Fr 05.10.12 16:06

---

Hallo Mathematiker, besten Dank für Deinen Beitrag und auch Deine Mühe!

Zunächst einmal bin ich damit beschäftigt, einen Computer (Surf- und Programmierlaptop) neu einzurichten, weil mein treuer Rechenknecht gestern nach 6 Jahren seinen Geist aufgab. Das gröbste müßte aber nun(mehr) überstanden sein.

Beileibe bin ich niemand, der Fehler abstreitet (um sich so Arbeit vom Halse zu halten, um es sich nicht einzugestehen und so die Aura im Selbstbild nicht anzukratzen, was auch immer), aber es kommt auch jetzt so, wie es fast gesetzmäßig kommen muß: Ich kann es nicht reproduzieren und benötige mithin mehr Informationen!

1. Welche Programmversion zeigt dieses Fehlverhalten? Alle?
2. Wieviel Vorsortierschleifen schaltetest Du zu?
3. Bei welcher Sortieralgorithmus zeigt sich der Fehler? Oder ist das egal ("invariant"), d.h. bei jedem?
4. Evtl. noch wichtig: Bei welcher Auflösung?

Nach ca. 4 Jahren Programmierdauer werden die Fehler zum Glück allmählich selten, doch sie komplett, vollständig auszumerzen ist wie mit dem perfekten Umweltschutz, indem man alle Schadstoffe ausfiltert: Es ist nahezu unmöglich.

Dank im voraus und viele Grüße

Delphi-Laie

Mathematiker - Fr 05.10.12 16:42

---

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

1. Welche Programmversion zeigt dieses Fehlverhalten? Alle? 2. Wieviel Vorsortierschleifen schaltetest Du zu? 3. Bei welcher Sortieralgorithmus zeigt sich der Fehler? Oder ist das egal ("invariant"), d.h. bei jedem? 4. Evtl. noch wichtig: Bei welcher Auflösung?

Ich habe es gerade noch einmal getestet; Version D4 laufzeitflexible Längen.
Starte ich das Programm und klicke sofort Vorsortierung binär (eine Vorsortierschleife), so geht das Programm ohne Meldung einfach zu.
Wähle ich Dreieckspermutation und ebenfalls binäre Vorsortierung und sortiere mit dem 1.Verfahren AVL-Sort, so geht es gut, bis nach dem Sortieren. Dann kommt die Zugriffsverletzung, der Eingabedialog wird unsichtbar und nur nach ALT-F4 schließt das Programm.
Bei einigen Verfahren funktioniert alles ok. Wähle ich Heapsort, so sortiert es korrekt und beendet sich danach selbst.
Die Auflösung meines Computers ist 1280 x 800 Pixel mit Windows Vista.
Beste Grüße
Mathematiker

Delphi-Laie - Fr 05.10.12 17:14

---

Danke, ich bekomme es jetzt einigermaßen reproduziert.

In der Lazarus-Variante taucht dieser Fehler nicht auf, mit anderen Sortieralgorithmen auch nicht immer...das kann ja heiter werden.

Nichtdestoweniger werde ich als alter Pedant (sind wir Programmierer das nicht alle mehr oder weniger?) der Sache natürlich auf den Grund gehen.

Viele Grüße

Delphi-Laie

Delphi-Laie - Fr 05.10.12 21:31

---

So, Ursache des Problems gefunden und es (hoffentlich) beseitigt. Und natürlich danach die Verbesserung auch veröffentlicht.

Es war ein Array-Dimensionierungsfehler: Ein um 1 zu kleines Array. Merkwürdig nur, daß das parallele, fast quelltextgleiche Lazarus-Compilat (das ich auch gleich noch bereinigte) nicht zickte. Normalerweise ist Lazarus (und auch seine Compilate?) gegenüber Programmierfehlern empfindlicher.

Was ich auf meinem jetzigen Laptop wieder unangenehm wahrnehme (auch auf einem anderen Computer schon, nicht jedoch auf meinem Hauptcomputer bis gestern abend): Der Endpiep kommt vor dem Ende des Sortierens. Offensichtlich werden die Graphikbefehle (Linien zeichnen) an die Graphikkarte gesandt, von dieser geschluckt und damit der Graphikaufbau als schon erledigt betrachtet. Im Quelltext ist alles schön sequentiell. Wie diesem kleinen, aber unschönen Problem beizukommen ist, ist mir völlig rätselhaft.

Danke noch einmal, Mathematiker!

Mathematiker - Fr 05.10.12 22:21

---

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

So, Ursache des Problems gefunden und es (hoffentlich) beseitigt.

Funktioniert jetzt einwandfrei. Danke. :D

Zwei Wünsche hätte ich noch:
1. Durch die grafische Veranschaulichung ist eine reelle Zeitmessung nicht möglich. Dennoch wäre es nicht schlecht, wenn man eine ungefähre Zeitangabe hätte. Dann könnte man die Güte der Verfahren besser miteinander vergleichen.

2. Das Ini-File wird im Exe-Ordner abgelegt. In unserem Netzwerk gibt es dabei ein Problem, da nicht jeder Schreibrechte auf den Ordner hat. Vielleicht kann die Ini-Datei in den temporären Nutzerordner ausgelagert werden.

Ob das eine oder andere machbar ist, kann ich nicht einschätzen. Ich hoffe, dass es zumindest Anregungen sind.

Viel Erfolg beim weiteren Sortieren und beste Grüße
Mathematiker

Delphi-Laie - Fr 05.10.12 22:47

---

Die ich rief, die Geister....

Du hast ja vielleicht ein paar Sonderwünsche. ;-) Einige Anregungen "wehrte" ich schon ab, teils im Forum öffentlich und teils auch schon per PM bei einem mir altbekannten Forumsmitglied.

Das mit den Schreibrechten ist mir wohlbekannt, ich las dazu schon Luckies Ausführungen. Nur, wenn man das Recht hat, in irgendein Verzeichnis die Exe abzulegen, so nahm ich an, daß diese Exe dasselbe Recht hat, nämlich, ihre ini-Datei abzulegen. Ist dem nicht so? Nun, dann müßte ich mich damit beschäftigen, wo sie sonst abzulegen ist. Ein Verzeichnis, auf dem man nach meinem Wissen immer Schreibrechte hat (auch als ausgegrenztester Gast), ist das Temp-Verzeichnis. Nur, das kann man gelegentlich auch bereinigen (lassen).

Die Zeitmessung ist auch so eine Sache, weil nicht allzu aussagekräftig. Das Programm verzerrt die Sortiergeschwindigkeiten wegen der ständigen Ausgabe ohnehin.

Es gab z.B. auch den Wunsch, die Anzahl der Vergleiche und der Vertauschungen zu zählen und auszugeben. Teilweise gibt es aber Verschiebungen statt Vertauschungen (eine Vertauschung wären dann 3 Verschiebungen). Bei komplizierten Algorithen (AVL, B, Skiplist) werde ich damit wohl überfordert sein. Die speziellen Sortieralgorithmen vergleichen gar nicht. Oder eine farbliche Markierung/Hervorhebung der demnächst zu tauschenden Elemente (hier: Längslinien). Das geht aber so schnell, daß man es nicht erfassen kann (das weiß ich von einer anderen Sortieranimation). Vertikale Vertauschungen zu programmieren, macht nur mehr Arbeit, der Informationszuwachs ist gleich 0. Man könnte genausogut auch einige Algorithmen umgekehrt laufen lassen (sodaß z.B. Bubblesort nicht erst die kleinsten, also aufsteigend, sondern die größten Elemente zuerst, also absteigend, sortiert) oder gleich komplett invers (absteigend) sortieren (lassen). Irgendwann verliert man sich in tausenden Einzelheiten.

Mit dem Schreiberverzeichnis/-rechten sehe ich noch am ehesten eine Chance. Die Zeitmessung ist schon wesentlich weniger sinnvoll. Ich habe ja auch gemogelt: Um flüssiges Sortieren zu gewährleisten, krallt sich dieses Programm maximale Prozeßpriorität (Echtzeit ist nicht möglich, warum, weiß ich nicht) und maximale Threadpriorität. Allein dafür würden mich manche wahrscheinlich schon "lynchen". Für systematisches Eindringen in die Welt der Sortieralgorithmen ist mein Programm in dieser Form ungeeignet und wird es wegen der betonten Beschränkung auf die Darstellung des Verlaufes (Animation) auch nimmer werden.

Mathematiker - Fr 05.10.12 23:42

---

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Du hast ja vielleicht ein paar Sonderwünsche. ;-) Einige Anregungen "wehrte" ich schon ab, teils im Forum öffentlich und teils auch schon per PM bei einem mir altbekannten Forumsmitglied.

Es sind nur Anregungen!
Die Sache mit der Zeitmessung ist mir eigentlich klar; durch die grafische Darstellung unrealistisch. Muss ja auch nicht sein.
Das Problem mit der Ini-Datei ist weniger problematisch. Statt

müsste nur

mit

eingefügt werden, hoffe ich.

Beste Grüße und nichts für ungut, wenn meine Wünsche etwas extrem sind. :wink:
Mathematiker

Nachtrag: Ich habe es gerade getestet. Mein Vorschlag funktioniert nicht. Irgendwo habe ich einen Denkfehler.

Delphi-Laie - Fr 05.10.12 23:57

---

Nein, solche Wünsche sind beileibe nicht "extrem", es war schon heftiger (wie weiter oben erwähnt). Auf das Temp-Verzeichnis schreibend zugreifen zu lassen, ist mir allerdings ein klein wenig anders bekannt als bei Deiner hier vorgestellten Lösung.

Den Speicherort kann ich leider nicht in die ini-Datei (oder jede andere Datendatei) schreiben, denn an diese sicher zu gelangen, ja, sie überhaupt erst einmal zu erstellen, ist ja das eigentliche Problem. Also müßte das in die exe eincompiliert ("fest verdrahtet" ) werden und ich mithin weitere Programmversionen erstellen. Das wird mir eigentlich allmählich zu unübersichtlich. Alternativ kannst Du doch diese paar wenigen Zeilen, die Du hier vorstelltest, doch gleich in meinen Quelltext einfügen?!

Ich arbeite auf meinen privaten Computern grundsätzlich als Adminstrator ohne irgendwelche Konten und individuelle Anmeldung(szwänge) und lasse mich in der Beziehung auch von niemandem belehren. Schließlich heißt PC ja persönlicher Computer, und das nehme ich wörtlich. Deshalb bleiben mir solche Niederungen wie fehlende Schreibrechte (bei denen ich eigentlich einen dicken Hals bekomme, ich hatte diese ewigen Bevormundungen eigentlich satt, bin aber davon zum Glück seit Jahren nicht mehr betroffen) leider verborgen. Ich vermute, daß Du die exe auf einem Server liegen hast und diese von verschiedenen Clienten aus gestartet werden soll, nicht wahr?

Edit: Die Speicherung der Optionen in die ini-Datei war auch eine Anregung (von einem Teilnehmer eines externen Forums) und m.E. die einzige, die ich bisher umsetzte. Und die hatte es schon in sich (der Teufel steckte auch hier in vielen Details), weil ich einen Teil des Programmcodes dazu komplett überarbeiten mußte.

Edit 2: Das Temp(orär)verzeichnis ermittelte ich bis dato so:

Delphi-Laie - Sa 06.10.12 11:35

---

Mathematiker hat folgendes geschrieben :

Nachtrag: Ich habe es gerade getestet. Mein Vorschlag funktioniert nicht. Irgendwo habe ich einen Denkfehler.

Die Fehlermeldung brachte den Fehler an den Tag: Auf C:\Temp\C:\.....(Mein Temp-Verzeichnis und mein Speicherort der Exe-Datei) kann natürlich nicht geschrieben werden. Wir benötigen nur den Exe-Dateinamen ohne vorangestellten Pfad und ohne Dateiparameter.

Aber mit


(in der Initialisation)

und, nicht zu vergessen, mit


(im FormCreate)

scheint es tadellos zu klappen.

Ergänzung:

Deine vorgestellte Tempordnerfunktion scheint auch etwas vereinfacht:



gleichermaßen zu funktionieren. Das Verb "scheinen" ist bei meinen Aussagen zudem mein Lieblingswort.

Mathematiker - So 21.10.12 22:03

---

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Aber mit Delphi-Quelltext 1: IniFile:=TIniFile.Create(Gettemppfad+ExtractFileName(ChangeFileExt(ParamStr(0),'.ini'))) (in der Initialisation) und, nicht zu vergessen, mit Delphi-Quelltext 1: if Fileexists(Gettemppfad+ExtractFileName(ChangeFileExt(ParamStr(0),'.ini'))) then (im FormCreate) scheint es tadellos zu klappen.

Meine Rückmeldung kommt etwas spät.
Es funktioniert tadellos. Dein Programm läuft ohne Probleme im Netzwerk, jetzt auch auf den Terminals ohne Schreibrechte.
Beste Grüße
Mathematiker

Delphi-Laie - Mo 22.10.12 09:03

---

Mathematiker hat folgendes geschrieben :

Meine Rückmeldung kommt etwas spät.

Sie hätte auch gar nicht kommen müssen (ich weiß es ja per PN), aber danke! Und sogar, wenn sie zu spät gekommen wäre (was wäre in diesem Kontext "zu"?), macht alles nichts. Als Student hatte ich auch nicht immer Lust, pünktlich aufzustehen, und kam in einigen Fällen zu spät. Und das eine Jahr, in dem ich selbst vor Studenten stand, war es nicht anders. Ich sagte zu den Nachzüglern immer: "Besser zu spät als gar nicht." ;-) Aber übernimm diesen Spruch bitte nicht für Deine "Schöler"!

Mathematiker hat folgendes geschrieben :

Es funktioniert tadellos. Dein Programm läuft ohne Probleme im Netzwerk, jetzt auch auf den Terminals ohne Schreibrechte.

In die Temp(orär)-Verzeichnisse, nicht wahr? Ist nun die Frage, in das nutzerinterne, -spezielle oder das generelle für die jeweilige Windows-Installation? Im ersteren hätte jeder seine Einstellungen, im zweiten eben nicht. Spontan weiß ich natürlich nicht, welches aufgerufen wird, ja nicht einmal, ob es in der Beziehung zwei verschiedene Kategorien gibt.

Mathematiker - Mo 22.10.12 09:28

---

Hallo Delphi-Laie,

Delphi-Laie hat folgendes geschrieben :

Sie hätte auch gar nicht kommen müssen (ich weiß es ja per PN), aber danke! Und sogar, wenn sie zu spät gekommen wäre (was wäre in diesem Kontext "zu"?), macht alles nichts.

Ich habe mich nur an die Regeln gehalten.

Zitat:

4.7 Antworten IMMER ins Forum Wer in der EE fragt, liest auch in der EE! Deshalb: Antworten auf Fragen bitte IMMER im Forum posten. Antworten (ausschließlich) per Email/PN oder über andere nicht-öffentliche Kanäle sind nicht erwünscht, da wir Wissen nicht verstecken, sondern für spätere Leser mit ähnlichen Fragen oder Problemen bewahren wollen.

Oh je, jetzt kommt bei mir der (Be)Lehrer durch. :mahn:

Delphi-Laie hat folgendes geschrieben :

In die Temp(orär)-Verzeichnisse, nicht wahr? Ist nun die Frage, in das nutzerinterne, -spezielle oder das generelle für die jeweilige Windows-Installation?

Werde ich testen. Sobald ich es weiß, melde ich es hier im Forum. :mrgreen:

Beste Grüße
Mathematiker

Delphi-Laie - Mo 22.10.12 09:37

---

Für fachliche Antworten trifft das zu, denn die helfen allen. Allein ein Dank erfüllt diese Anforderung nicht (überhaupt, ist vieler "smaller Talk" beim Extrahieren der eigentlichen Informationen natürlich hinderlich), ist aber auch öffentlich schön.

Was ich noch ergänzen wollte: In dem einen Jahr, in dem es nicht anders war (das Zuspätkommen), traf das Zuspätkommen natürlich nicht auf mich zu, da war ich ja geläutert und vorbildlich (hingen ja auch Anstellung und Einkommen davon ab). Ich meinte natürlich die Studenten. Die ändern sich eben nie... ;-)

Delphi-Laie - Fr 23.11.12 19:04

---

Hallo Mathematiker, das müßte auch einfacher funktionieren:



Damit muß die Funktion zum Ermitteln des Temp-Verzeichnisses nur einmal aufgerufen werden. Ich werde das in eine try-Anweisung packen, wie jüngst unter http://www.entwickler-ecke.de/viewtopic.php?t=110615 angeregt. Damit kann dieses mein Programm in sein eigenes Verzeichnis zu schreiben versuchen und, wenn das nicht klappt (z.B. bei Netzwerkbetrieb), in das für Schreibvorgänge n.m.W. immer empfängliche benuterspezifische Tempverzeichnis schreiben.

Mathematiker - So 24.11.13 15:06

---

Hallo Delphi-Laie,
ich habe Deine neue Version des Sortierkinos getestet und bin beeindruckt. :zustimm:
Zum einen ist die Menge der verschiedenen Sortierverfahren; einige kenne ich gar nicht; sehr groß, zum anderen ist es sehr schön, dass nun jeder Sortiervorgang problemlos unterbrochen werden kann.
Damit hast Du wohl eines der umfangreichsten Programme zum Sortieren.

Kleiner Hinweis: Bei den "Lazarus-Exen" überlappen sich die Auswahlfelder, so dass man es schlecht lesen kann.
Bei den "Delphi-Exen" ist alles perfekt.

Beste Grüße
Mathematiker

PS: Ich sehe gerade: 70 Bearbeitungen des Programms. Das ist ebenfalls beeindruckend.

Delphi-Laie - So 24.11.13 16:20

---

Danke für das Lob, aber bin ich jetzt gegenüber dem eigenen Produkt betriebsblind?

Mathematiker hat folgendes geschrieben :

Kleiner Hinweis: Bei den "Lazarus-Exen" überlappen sich die Auswahlfelder, so dass man es schlecht lesen kann.

Was überlappt sich da und kann schlecht gelesen werden?

Mathematiker hat folgendes geschrieben :

Damit hast Du wohl eines der umfangreichsten Programme zum Sortieren.

Ich hoffe, daß es schon das Umfangreichste ist, falls nein, dann arbeite ich weiter daran (und auch ohne diese Zielsetzung). ;-)

Mathematiker hat folgendes geschrieben :

Ich sehe gerade: 70 Bearbeitungen des Programms. Das ist ebenfalls beeindruckend.

Naja, waren nicht immer echte Neuerungen. Manchmal fand ich - natürlich erst nach dem Hochladen / Veröffentlichen - noch kleine Fehlerchen, die ich so natürlich nicht belassen konnte. Das meiste waren aber schon echte Neuerungen i.S. von Funktionserweiterungen.

Tastaro - Mi 22.02.17 12:57

---

Ich mag dein Sortierkino und finde es sehr hilfreich.
Danke dafür

Delphi-Laie - Mi 22.02.17 13:12

---

Tastaro hat folgendes geschrieben :

Ich mag dein Sortierkino und finde es sehr hilfreich. Danke dafür

Danke auch!

Nunja, jeder hat sein Steckenpferd, das für etliche andere wohl eher schon wie eine Macke, ein "Spleen" wirkt, was ich nachvollziehen kann. Algorithmen mochte ich schon immer, und die Sortieralgorithmen, die sich i.d.R. so schön visualisieren lassen, haben mich ganz in ihren Bann gezogen.

Das einzige, was mir an meinem Programm bis heute nicht so recht gefällt, ist das Layout des Bedienformulares. Es soll möglichst viel auf den ersten Blick erkennbar sein, jedenfalls kein unnötiges Herumgeklicke, um an die Optionen zu gelangen, verursachen (in den sog. "Menüs" läßt sich fast unendlich viel - dann verschachtelt - verstecken). Das ist meine Vorstellung von Softwareergonomie. Dann sollen die visuellen Komponenten einigermaßen logisch und geordnet angeordnet sein - weiter oben hinsichtlich der Sortiervorbereitung, weiter unten eher in Richtung Sortierdurchführung. Und dann soll das ganze auch noch platzsparend - ohne zu dicht gedrängt zu wirken - placiert sein, damit das Bedienformular möglichst kleingehalten und von der Startmenge im Hintergrund auch noch möglichst viel zu sehen ist.

Wer diesen Zielkonflikt besser als meine Wenigkeit gelöst, ja optimiert bekommt, dem gebe ich einen aus - versprochen!

Postscriptum: Ich entwickele unentwegt weiter, die Ideen, vor allem neue Algorithmen gehen mir nicht aus. Meistens gibt es im Wochenrythmus ein neues Update. In den nächsten Tagen soll u.a. ein weiteres Smoothsort [http://www.entwickler-ecke.de/posting.php?mode=quote&p=705571] hinzukommen.

Tastaro - Mi 22.02.17 14:04

---

Naja, die Einstellungen in dem Fenster betreffen
die Eingabe (Werteerzeugung, Vorsortierung, Anzahl der Elemente, ...),
die Verarbeitung (Algorithmus, Blocktauschalgorithmus, Bremsfaktor, ...),
die Ausgabe (Farben, Hintergrund, Ergebnisanzeige, ...) und
sonstige Einstellungen (Aktion nach Abbruch, nach Ende, ...)

Entsprechend würde ich sie im Fenster gruppieren und entweder mit GroupBox oder farbig/schattiert die Zusammengehörigkeit sichtbar machen.
Bei den heutigen Auflösungen kann auch ein "kleines" Fenster gerne 800x600 sein. Etwas mehr Platz würde die Vielzahl der Einstellmöglichkeiten hier mMn übersichtlicher machen.

Vielleicht hilft dir das. :)

Delphi-Laie - Mi 22.02.17 16:34

---

Tastaro hat folgendes geschrieben :

Vielleicht hilft dir das. :)

Nicht schlecht, Du bist ein heißer Kandidat für mein Versprechen, vielen Dank!

Die Groupboxen gefallen mir, weil man die visuellen Komponenten einfach nur "draufbebberln" muß, es kann alles sichtbar bleiben, was ich ziemlich favorisiere.

Nicht schlecht wäre alternativ auch ein TabbedNotebook, es wäre für die Bedienung nur wenige Klicks mehr erforderlich, das Formular könnte sogar verkleinert werden, was ebenfalls meine Sympathie weckt.

Logisch ganz sauber zu trennen sind Verarbeitung und Ausgabe aber nicht, siehe Bremsfaktor.

Delphi-Laie - Fr 24.02.17 23:09

---

Da wegen meiner jüngsten Nach-/Anfragen in diesem Forum das Interesse an diesem Programm wieder ein wenig auflebte, erlaube ich mir, ausnahmsweise darauf hinzuweisen, daß jetzt im ersten Beitrage eine neue Version zur Verfügung steht, die sich doch deutlich - nämlich sichtbar! - von den bisherigen unterscheidet. Einbezogen wurden die Ergebnisse aus den Hilfen da [http://www.entwickler-ecke.de/viewtopic.php?t=116211] und dort [http://www.entwickler-ecke.de/viewtopic.php?t=116218], für die ich noch einmal herzlich danke!

Ein ganz besonderer Dank gilt jedoch Tastaro [http://www.entwickler-ecke.de/user_Tastaro.html] in dieser Diskussion (oben auf dieser Seite) für seine Anregung(en)! Vielleicht meldet er sich ja noch per PN bei mir.