Hallo EE, schön, dass ihr wieder erreichbar seid

Ich habe endlich mein erstes etwas größeres Projekt in Delphi (verglichen mit den den mini-Projekten aus der Schule) fertiggestellt. Natürlich heißt das nicht, dass es nicht noch oft überarbeitet werden wird.

Im Grunde ist es ein Sortieralgorithmen-Visualisierer. Ich weiß, dass es hunderte davon gibt - aber (Sortier-)Algorithmen sind eben gerade Thema in Info ^^
Und selber machen ist eh viel toller

Ich habe neben dem Stupiden 'Visualisiere mir den Algorithmus' noch zwei weitere Funktionen implementiert:

1. Anzeigen der Stabilität während Visualisierung (Voraussentzung: 'allow doubles' bei Listengeneration aktiviert)
Sortierte Elemente werden grün, nichtsortierte rot und 'instabile' Elemente blau gefärbt. (von der Liste abhängig, nicht, was vom Algorithmus als sortiert betrachtet wird)

2. Vergleich beliebig vieler Algorithmen durch Parallelisierung (einfach mehre Algorithmen in der Liste auswählen)
Jeder Algorithmus bekommt einen Abschnitt auf der Bitmap zugewiesen. Die Abschnitte werden in einem Quadrat angeordnet (mit Rows := Math.ceil(sqrt(num)))

Das ganze wird auf einer einzigen Bitmap gezeichnet, die auf die Paintbox gerendert wird, wenn alle Algorithmen gezeichnet haben.
Wenn ein Algorithmus schon gezeichnet hat, aber noch nicht gerendert wurde, wartet dieser darauf bevor er wieder zur Zeichenfunktion durchgelassen wird.


Wie bereits erwähnt, ist das mein erstes größeres Delphi-Projekt. Es wäre also schön, wenn mir mal ein paar von euch einige Tipps gäben bzgl:

- Umsetzung
speziell was die Parallelisierung, vielleicht auch die jeweiligen Grafik-Bibliotheken angeht.
OpenGL hab ich zB. in ein extra Fenster packen müssen, weil das automatisch auf der ganzen Form Zeichnet.

- Geschwindigkeit
Das größte Problem ist wie immer die Grafik. Ich habe mir deshalb einige andere Grafik-Bibliotheken herausgesucht und weitere Versionen in den Anhang gepackt. Zurzeit wären das:
- die standard 'Graphics' Unit
- die 'Graphics32' Unit (github.com/graphics32/graphics32)
- der 'OpenGL' header (github.com/SaschaWillems/dglOpenGL)

Zum Vergleich habe ich mal bei HeapSort mit beiden Versionen Wertetabellen aufgenommen, und mit meinem GTR angenäherte t(n) funktionen errechnen lassen: (t in millisekunden, n: Listenlänge)


- Plattformkompatibilität (der Interesse halber)
Ich spreche von der Kompatibilität zwischen verschiedenen Windows Systemen, 16/32/64 bit und verschiedenen Architekturen wie Intel, Arm und was es da sonst noch so gibt - ich kenne mich da nicht so aus.

Wenn das auf Linux laufen soll brauche ich bestimmt eine Kostenpflichtige Delphi-Version mit einem entsprechenden Compiler - Das meine ich erstmal nicht mit Kompatibilität


Natürlich bin ich auch für andere Hinweise offen, zB. was die GUI angeht - aber das soll jetzt erstmal nicht im Vordergrund stehen.

Vielen Dank im Vorraus für alle Hinweise und Software-Tester reviews

LG,
Symbroson


Edit 1: Version 4.5:
- Thread-Objekte werden jetzt korrekt zerstört
- 'Reset' Button hinzugefügt (ersetzt alle Listen durch die zuletzt generierte)
Edit2: Verion 4.6:
- Fix kleiner bugs
- OpenGL-Version hinzugefügt
Edit 3:
- Info-Bild in .exe eingebunden
Edit4: Verion 4.8:
- GUI umstrukturiert
- animation auf 'fast','realtime' und 'none' einstellbar, anstatt nur animation an/aus
- verschiedene Farben ausschaltbar (kleiner aber spürbarer performanceschub)
- fast_algorithm (ohne Animation) wieder eingefügt (vmtl durch umstrukturierung bei 4.6 verlorengegangen)
- std und g32 auf 4.8 aktualisiert

Ich kenne zumindest eines dieser Deiner Programme. Und ich weiß, in welcher Beziehung Du zum Forumsmitglied "Mathematiker" stehst. Mithin nehme ich an, daß Dir auch meine seit Jahren leidenschaftliche, ja besessene Beschäftigung mit dieser Materie bekannt ist.

Interessant sind Deine Programme für mich allemal, vielleicht kann ich etwas davon für mein Hauptprojekt "stiebitzen".

Symbroson hat folgendes geschrieben :

1. Anzeigen der Stabilität während Visualisierung Sortierte Elemente werden grün, nichtsortierte rot und 'instabile' Elemente blau gefärbt. (von der Liste Abhängig, nicht, was vom Algorithmus als sortiert betrachtet wird)

Damit komme ich nicht so recht klar. (In-)Stabilität bezieht sich auf die Beibehaltung der Reihenfolge gleichgroßer Elemente im Verlaufe der Sortierung zueinander. Stabilität ist nicht dasselbe (bzw. das gleiche) wie Sortierung. Deshalb ist mir unklar, wie "instable" (m.E. unstable) als dritte Option zu "sorted" bzw. "wrong number" stehen kann.

Reduziere mal in meinem "einschlägigen" Programm die Anzahl verschiedener Elemente auf 1. Da gibt es nichts mehr zu sortieren. Dennoch bewegen manche Sortieralgorithmen die Sortierelemente. Dann ist im Verlaufe der Sortierung, vor allem aber erst recht danach zu erkennen, ob ein Sortieralgorithmus stabil ist oder nicht (abgesehen davon, daß mein Programm das auch "ermitteln" und nach der Sortierung mit anzeigen kann).

Symbroson hat folgendes geschrieben :

[b]2. Vergleich beliebig vieler Algorithmen durch Parallelisierung Jeder Algorithmus bekommt einen Abschnitt auf der Bitmap zugewiesen. Die Abschnitte werden in einem Quadrat angeordnet (mit Rows := Math.ceil(sqrt(num)))

Die "nichtprogrammierte" Umsetzung ist Dir schon jetzt klar, aber das ist eigentliche Problem geht erst danach los: Threadprogrammierung. Nutze dazu Michael Puffs Anleitung dazu, ggf. auch seine Beispiele. Nicht zuletzt darfst Du bei meinem Amateurprojekt aus dem vollen schöpfen, denn es ist ja quelltextoffen ohne vehemente Urheberrechtsschaft. Ganz unbescheidenerweise darf ich feststellen, daß von derlei Programmen, von denen es ja (angeblich) "hunderte" gibt (bin mir da nicht so sicher, aber etliche gewiß), meines das erste mir bekannte ist, daß sich an der animierten Sortierparallelisierung versuchte.

Viel Glück und Erfolg, und halte das Forum bitte auf dem laufenden!

Gruß Delphi-Laie

Edit: Also, die Grundlagen der Threadprogrammierung scheinen Dir doch schon bekannt zu sein, Kompliment! Aber lernen und probieren kann man dabei kaum genug.

Edit 2: Die Menge der Sortierelemente - vor der Sortierung und danach, Linien oder Quadrate - läßt sich mit einem anderen Formular "wegwischen". Das ist unschön. Könnte man mit einem Neuzeichnen-Ereignis neu zeichnen lassen. Ein wenig irritiert mich die etwas "laue" Verarbeitungsgeschwindigkeit auch in der Fast-Version, auch ohne ein Delay.

Hallo Delphi-Laie,

Um ehrlich zu sein verwirrt mich deine Antwort ziemlich.

Zitat:

Ich kenne zumindest eines dieser Deiner Programme

Um welche Programme handelt es sich dabei? Ich habe bisher nie ein anderes (Delphi) Programm veröffentlicht

Zitat:

Und ich weiß, in welcher Beziehung Du zum Forumsmitglied "Mathematiker" stehst

Muss ich also davon ausgehen, dass du mich kennst? Ich zumindest kann dich aus deinem Alias nicht indentifizieren.

Zitat:

Mithin nehme ich an, daß Dir auch meine seit Jahren leidenschaftliche, ja besessene Beschäftigung mit dieser Materie bekannt ist

Nein, da ich dich erstens wie gesagt nicht indentifizieren kann und 2. erst seit ca einem Monat in der EE bin.

Zitat:

Damit komme ich nicht so recht klar. (In-)Stabilität bezieht sich auf die Beibehaltung der Reihenfolge gleichgroßer Elemente im Verlaufe der Sortierung zueinander. Stabilität ist nicht dasselbe (bzw. das gleiche) wie Sortierung. Deshalb ist mir unklar, wie "instable" (m.E. unstable) als dritte Option zu "sorted" bzw. "wrong number" stehen kann.

Ich habe das gelöst, indem ich ein 'Node' record angelegt habe mit 'value' und 'index'. Mit 'index' prüfe ich die Stabilität

Zitat:

Reduziere mal in meinem "einschlägigen" Programm die Anzahl verschiedener Elemente auf 1.

Entschuldigung, von welchem Programm sprichst du? Mathematiker hatte mal was von einem Sortierkino hier in der EE erzählt - ich hab es mir ehrlichgesagt noch nicht genauer angeschaut.

Bitte bring etwas Licht in mein Dunkel
LG,
Symbroson

Symbroson hat folgendes geschrieben :

Um welche Programme handelt es sich dabei? Ich habe bisher nie ein anderes (Delphi) Programm veröffentlicht

Eines der beiden hier veröffentlichten. Das erste. Ist auch egal. Viel interessanter ist für mich das zweite, das wohl mit Delphi 7 compiliert wurde, jedenfalls legt das das Programmsymbol nahe. Ich versuche just, diese Graphikbibliothek in ihrer Minimalversion auf bzw. mit Delphi 7 zum Laufen zu bringen. Es sieht trüb damit aus...

Symbroson hat folgendes geschrieben :

Muss ich also davon ausgehen, dass du mich kennst? Ich zumindest kann dich aus deinem Alias nicht indentifizieren.

Nicht mit bürgerlichem Namen. Das schrieb ich auch nicht. Sondern, in welchem Verhältnis Du zum "Mathematiker" stehst. Und ich freue mich, daß er zumindest dann und wann echtes Interesse wecken kann, das sich dann auch hier im Forum bemerkbar macht.

Symbroson hat folgendes geschrieben :

Nein, da ich dich erstens wie gesagt nicht indentifizieren kann und 2. erst seit ca einem Monat in der EE bin.

Nun, ich war mir sicher, daß Du seine Seite "mathematikalpha" schon durgestöbert hast. Auch hat er einen Verweis zu mir. Und in meinem Profil ist mein eigentlicher Internetauftritt ebenfalls leicht zu finden.

Symbroson hat folgendes geschrieben :

Ich habe das gelöst, indem ich ein 'Node' record angelegt habe mit 'value' und 'index'. Mit 'index' prüfe ich die Stabilität

Das hast Du richtig getan. Um die Stabilität festzustellen bzw. wahrzunehmen, sind neben den Sortierschlüsseln weitere Informationen an die Sortierelemente "anzuheften". Nur sehe ich keinen Bezug zur Stabilität bei Deinem Programm.

Symbroson hat folgendes geschrieben :

Entschuldigung, von welchem Programm sprichst du? Mathematiker hatte mal was von einem Sortierkino hier in der EE erzählt - ich hab es mir ehrlichgesagt noch nicht genauer angeschaut.

Bingo! Den Rest kennt auch "Tante Google".

Gruß Delphi-Laie

Zitat:

Nur sehe ich keinen Bezug zur Stabilität bei Deinem Programm.

Wenn die Indizes zweier Elemente nicht aufsteigend sortiert sind, werden diese blau gefärbt
-> sind am Ende der Sortierung blau gefärbte Elemente zu sehen, ist der Algorithmus instabil.

Symbroson hat folgendes geschrieben :

Zitat: Nur sehe ich keinen Bezug zur Stabilität bei Deinem Programm. Wenn die Indizes zweier Elemente nicht aufsteigend sortiert sind, werden diese blau gefärbt -> sind am Ende der Sortierung blau gefärbte Elemente zu sehen, ist der Algorithmus instabil.

Klar, natürlich. Jetzt fällt es mir wie Schuppen von den Augen. Dazu muß man natürlich "allow doubles" aktivieren, damit die (In-)Stabilität überhaupt infragekommt.

Ein kleines logisches Dilemma ergibt sich damit aber dennoch: Wenn 1B und 1A nach der Sortierung in dieser Reihenfolge vorliegen, gibt es nicht ein instabiles Element oder zwei, sondern die Instabilität ergibt sich aus der Reihenfolge beider zueinander. Das ist nicht eindeutig. Man könnte nämlich z.B. behaupten, 1B ist richtig und "nur" 1A nicht - oder umgekehrt.

Wie wolltest Du z.B. die Reihenfolge 1C, 1A und 1B farblich kennzeichnen?

1A und 1B sind hier ja in der stabilen Reihenfolge, und nur 1C ist aus dieser Sicht falsch - dann aber wiederum zu beiden, 1A und 1B. Umgekehrt könnte man argumentieren, daß 1C richtig liegt und "nur" 1A und 1B nicht, weil diese hinter das 1C geraten sind. Je mehr gleich(groß)e Elemente vorliegen, desto schwieriger wird es, "stabile" von "instabilen" Elementen zu unterscheiden, weil das eben keine Eigenschaft einzelner Elementepositionen und damit einzelner Elemente ist.

Ich hoffe, daß das halbwegs verständlich ausgdrückt war.

Deshalb ist die (In-)Stabilität auch kein Schand-/Merkmal einzelner Elemente(gruppen), sondern schlichtweg eine Binäreigenschaft der sortierten Menge und des Sortieralgorithmus': Ist auch nur ein einzelnes Paar gleich(groß)er Elemente nach der Sortierung vertauscht, ist die Sortierung nicht mehr stabil.

Edit: Man könnte es so lösen, daß man alle Elemente, die i.S.d. Stabilität nicht an ihrem richtigen Platze sich befinden, einfärbt. Dennoch halte ich es z.B. für ungerecht, daß bei einer Reihenfolge z.B. 1Z, 1A, 1B, ..., 1Y dieses eine deplacierte Anfangselement alle anderen in die Instabilität hineinreitet. Ist aber im Hinblick auf Deine weiteren Ziele wohl nicht so wichtig.

Indem ich nir benachbarte Elemente einer Werteklasse vergleiche, ist am Ende der Urspring der Instabilität klar. Das ist der einzige Hintergrund.

Andere Frage: Da du dich ja anscheinend durch dein Sortierkino schon ziemlich viel mit Sortierung beschäftigt hast, könntest du ja mal über mein vergleichsweise kleines Programm schauen und mir einige Tipps und Anregungen geben. Das Sortierkino scheint ja ziemlich umpfangreich zu sein - deswegen gehe ich davon aus dass du mir in der Hinsicht mehr weiterhelfen kannst als ich dir.
Ich wäre dir wirklich sehr verbunden

LG

Naja, ich habe mir doch schon einen ersten Überblick und Eindruck verschafft. Und Dein Programm gefällt mir.

Tips und Anregungen? Schau einfach, was Dir an meinem Programm gefällt, was nicht, läßt Du logischerweise unter den Tisch fallen. Ich habe einfach all' das umgesetzt, was mir an anderen Programmen gefiel und was ich vermißte. Deine Wünsche kannst doch nur Du wissen bzw. formulieren. Klar, Fehler, die man findet, sollte man immer jemandem mitteilen.

Dafür vermisse ich heute noch etwas an meinem Programm: Bei kleinen Elementeanzahlen wird mein Sortierformular sehr klein, weil ich bis heute nicht so recht weiß, wie ich es umrechnen muß, wenn ich zwar wenige Elemente habe, aber dennoch ein akzeptabel großes Formular behalten möchte (das macht stattdessen das Programm "sound of sorting"). Klar, daß ich dann Balken statt Linien als graphische Elemente verwenden muß. Da die sehr kleine Elementeanzahl aber ohnehin nur bei den Bogo- und Bozosorts wirklich interessant ist - nur bei denen kommen diese Verfahren realistischerweise zu einem Ende - habe ich mich nie ernsthaft damit beschäftigt. Ansonsten war mir ganz im Gegensatz dazu eine möglichst große Anzahl zu sortierender Elemente wichtig - aber auch nicht mehr als darstellbar, weil für die Animation keinen optischen Mehrwert mehr bietend. Und was die Anzahl der Sortieralgorithmen anbetrifft, darf jedermann aus dieser "Datenbank" aus dem vollen schöpfen, auch Du. Es werden noch weitere hinzukommen, ich habe noch einige "in petto". Mein Programm ist zudem "minimalistisch", d.h., es kommt mit möglichst wenig Delphi (ab 4 compilierbar, dann aber mit "nicht so dollem" Multithreadingverhalten) und ohne zusätzliche Bibliotheken aus.

Vielmehr könntest Du mir ja helfen, wie Du diese Graphics32-Bibliothek zum Laufen gebracht hast, vielleicht bekomme ich damit ja noch eine Beschleunigung hin. Mehr als es als Package zu installieren - dann leider ohne zusätzlichen Tabulator, ohne VCL-Elemente, gibt's wohl nicht - habe ich bisher nicht geschafft. Aber es geht ja hier um Dein Programm und daß Dir geholfen wird.

Gerade sehe ich, wie man in Deinem Programm gleichzeitig mehrere Algorithmen gleichzeitig laufen lassen kann. Das ist ja fein! Es war allerdings eine Zufallsentdeckung (!) meinerseits, daß man mehr als einen Algorithmus am Beginn aktivieren kann. Allzu aussagekräftig ist das zwar nicht (weil Windows nach eigenem Gusto, also reichlich "ungerecht" die Threads abarbeitet), aber im Hinblick auf Futter für die Augen etwas ganz besonderes. Großes Lob, Du bist der nächste mir bekannte, der Multithreadingsortierung animiert bzw. Sortieranimation parallelisiert (abgesehen von dieser Webseite, und auf Youtube sah ich auch mal eine Parallelisierung).

So, jetzt habe ich aber doch einen echten, wenn auch nicht offensichtlichen Fehler entdeckt.

Betrachte mal den Eintrag für Dein Programm im Taskmanager - die Spalte "Threads " (eigentlich Threadanzahl) muß dabei aktiviert sein. Und dann selektiere und deselektiere einzelne oder mehrere Einträge in der Algorithmenliste. Es werden ständig neue Threads (beim Anklicken) erzeugt, ohne (beim Deselektieren) wieder zerstört zu werden. Auch nach dem Sortierende geht die Threadanzahl nicht wieder zurück. Das darf nicht sein, ist zumindest "sehr unsauber", da unnötig ressourcenbeanspruchend. Mein Programm ist zwar diesbezüglich auch kein Kind von Traurigkeit - teilweise laufen sogar mehrere Hundert Threads gleichzeitig, konkret beim simultanen Mergesort - aber die werden alle wieder beendet und verschwinden dann wieder.

Ja also vielleicht sollte ich das nochmal explizit in das Konsolen-Memo schreiben. Da hab ich sowiso geplant noch paar abdere Infos außer der Versionsnummer reinzuschreiben.

Danke für den Hinweis mit den Threads - ich hab glaube ich vergessen 'FreeOnTerminate' auf true zu setzen. Kommt darauf an was genau er freigibt, er sollte nämlich nicht das ganze Objekt zerstören, da die Liste ggf nach dem beenden/unterbrechen des Algorithmus weiterverwendet werden soll. Also muss ich beim erstellen neuer Threads und beim Beenden die alten komplett zerstören.

Was Graphics32 betrifft - die einbindung in Delphi verläuft meist nicht ganz fehlerfrei - bei mir war das auch nicht der Fall. Ich empfehle einfach mal ein bisschen im WWW zu suchen - das ist ein bekanntes Problem. Aber viel gehört eig. nicht dazu das zum laufen zu bekommen. Meiner Erinnerung nach muss man nur was kleines ändern/auskommentieren und es läuft.

Ich hab mal in deinen Quelltext reingeschaut und muss zugeben, dass ich da nicht wirklich durchblicke. Hab auch leider gerade keinen geeigneten Delphi source-code formatter zur hand.

Symbroson hat folgendes geschrieben :

Ich hab mal in deinen Quelltext reingeschaut und muss zugeben, dass ich da nicht wirklich durchblicke. Hab auch leider gerade keinen geeigneten Delphi source-code formatter zur hand.

Völlig normal, geht jedem, also auch mir beim ersten Blick in fremdes Hoheitsgebiet genauso.

Die größte Prozedur ist eine Ereignisbehandlungsroutine (Klick auf Button) und dient der Verarbeitung (Sortieren bzw. Mischen).

Die zweitgrößte (namens Mischen) dient der Erzeugung der jeweiligen Startmenge.

Die drittgrößte ("Sortierende") der Ausgabe der Sortierergebnisse.

Und dann verließen sie mich.

Ich hoffe, daß das ein klein wenig hilft. Ansonsten weiter fragen, und vor allem viel debuggen, um die Schritte zu erkennen!

Hallo,

Apropos Quelltextformatierung.

Zitat:

Delphi source-code formatter

In Lazarus-ide ( zumindest 1.6.4 ) ist der eingebaut.Offenbar gibt es den aber auch eigenständig.
jedicodeformat.sourceforge.net da sind auch andere Programme weiter unten angegeben.

Gruß Horst

Ich plane noch eine dritte Grafik-Bibliothek auszuprobieren - OpenGL. Hab damit schonmal in c gearbeitet - mal schauen wie ich das in Delphi umsetzen lässt.
Ich glaube mich zu erinnern, dass OpenGL in nem extra Fenster lief - nicht gerade optimal, aber vllt günstiger für Vollbild. Mal schauen was sich dazu finden lässt^^
Interessant für mich ist ja eigentlich der Vergleich verschiedener Bibliotheken

Zusätzlich dazu kann ich ja mal wegen den Abhängigkeiten schauen - bisher hab ich mir die 'uses' Zeile nicht genauer angeschaut, weil die ja automatisch beim Erstellen eines Programms hinzugefügt wird, und da eig. alles wichtige dabei ist.

Horst_H hat folgendes geschrieben :

Hallo, Apropos Quelltextformatierung. Zitat: Delphi source-code formatter In Lazarus-ide ( zumindest 1.6.4 ) ist der eingebaut.Offenbar gibt es den aber auch eigenständig. jedicodeformat.sourceforge.net da sind auch andere Programme weiter unten angegeben. Gruß Horst

Ohne jetzt zu sehr vom Thema abweichen zu wollen, aber die Vorstellungen anderer auf diese Weise übernehmen zu sollen, empfinde ich als Gängelei und Bevormundung. Deshalb halte ich von so etwas ziemlich wenig.

Symbroson hat folgendes geschrieben :

Ich plane noch eine dritte Grafik-Bibliothek auszuprobieren - OpenGL. Hab damit schonmal in c gearbeitet - mal schauen wie ich das in Delphi umsetzen lässt. Ich glaube mich zu erinnern, dass OpenGL in nem extra Fenster lief - nicht gerade optimal, aber vllt günstiger für Vollbild. Mal schauen was sich dazu finden lässt^^

Muß das evtl. gekapselt werden (Wrapper?!)?

Symbroson hat folgendes geschrieben :

Interessant für mich ist ja eigentlich der Vergleich verschiedener Bibliotheken

Zustimmung. Das passiert in meinem Langzahlentaschenrechner. Leider komme ich nur sehr sporadisch dazu, daran weiterzuwerkeln.

Symbroson hat folgendes geschrieben :

Zusätzlich dazu kann ich ja mal wegen den Abhängigkeiten schauen - bisher hab ich mir die 'uses' Zeile nicht genauer angeschaut, weil die ja automatisch beim Erstellen eines Programms hinzugefügt wird, und da eig. alles wichtige dabei ist.

Leider oft viel zu viel. Da das teilweise die Größe der Compilate unnötig erhöht, ist "Ausmisten" angesagt.

Ich hab eben bis Mittwoch keinen Rechner zur Hand
aber ich habe einen möglicherweise funktionierenden Ansatz gefunden:
entwickler-forum.de/...penGL-in-Delphi-Form

In neueren Delphiversionen, dazu zählt auch die kostenlose Starter Edition, ist die Hardwarebeschleunigung bereits direkt verfügbar. Einerseits mit Firemonkey, andererseits mit einem Direct2D-Canvas, der hier beschrieben ist:
docwiki.embarcadero.com/RADStudio/Tokyo/de/Die_Direct2D-Zeichenfläche

Beides ist sehr viel einfacher als direkt mit der OpenGL oder DirectX API zu arbeiten. Es gibt alternativ natürlich auch noch 2D Grafikengines, aber auch das ist etwas komplizierter als die direkt in Delphi verfügbaren Varianten.

Danke für den Hinweis, ich werde mir die definitiv auch mal anschauen und ausprobieren
Am ende hab ich dann 10 Versionen mit 10 verschiedenen Grafik-Bibliotheken

So, ich habe jetzt Version 4.5 hochgeladen, die die Thread Objekte korrekt zerstört.
Außerdem ist der Log rechts mit paar mehr Infos aufgestockt, und ein Reset-Button ist dazugekommen.

LG,
Symbroson

Na, das wird doch langsam, aber sicher immer besser!

Wenn man nur zwei Algorithmen laufen läßt, ist es doch unnötig, diese beiden in die oberen Hälfte der Verarbeitungsfläche zu quetschen. Einer könnte oben, einer unten laufen.

Desweiteren könnte ein frei zoombares Formular auch mehr Elemente ermöglichen (Du merkst, ich bin von meinem eigenen diesbezüglichen / einschlägigen Programm geprägt).

Das nächste ist ein Bedienbarkeitsfehler: Während des Sortierens ist "allow doubles" anklick- bzw. umschaltbar. Damit bringt man irgendetwas an den Sortiermengen durcheinander, das Sortierergebnis wird inkonsistent. Anscheinend wird die Startmenge neu erzeugt. Also sollte das während der Animation deaktiviert sein.

Was bedeutet "draw pointers"?

Vor allem aber lebt ein solches Programm von diversen Startmengen und zuvörderst natürlich Sortieralgorithmen. Es ist in dieser Hinsicht "nach oben hin offen", ja fast eine unendliche Geschichte (das ist als halbe Vorwarnung gemeint). Ich wußte damals vor 8 Jahren, als ich mit diesem Thema erneut begann, nicht, worauf ich mich einlasse, und hätte es dann wohl eher bleibengelassen. Aber einmal Blut geleckt, überwog bis heute der "Suchtfaktor".

Noch ein Zusatz: Mir ist jetzt klar, warum ich mich nicht dafür erwärmen kann, zwei oder noch mehr Algorithmen simultan zu animieren: Man kann sich kaum auf einen konzentrieren. Lediglich die unterschiedlichen Ablaufgeschwindigkeiten bzw. Verarbeitungdauern stechen unmittelbar in's Auge.

Und da ich gerade wieder beim Multithreading bin: Parallele bzw. simultane Sortieralgorithmen haben "ihren ganz eigenen Reiz", sowohl optisch als auch von der Programmierherausforderung her (Du bist mit der Materie der Multithreadingprogrammierung ja durchaus schon vertraut). Ich begann mit Quicksort, und die ersten Ergebnisse waren Pleiten. Aber irgendwann lief es. Quicksort ist m.E. einer der simpelsten und vor allem offensichtlichsten parallelisierbaren Sortieralgorithmen.