Autor Beitrag
Symbroson Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 382
Erhaltene Danke: 67

Raspbian, Ubuntu, Win10
C, C++, Python, JavaScript, Lazarus, Delphi7, Casio Basic
BeitragVerfasst: Di 31.10.17 23:53 
Ok. Ich sehe, es gibt (in der Theorie) noch viel zu tun. Aber erstmal zu den Fragen:

Zitat:
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.

Der einfachheit halber belasse ich es bei der aktuellen, festgelegten Anordnung. Es bringt überhaupt keinen Vorteil, diese veränderbar zu machen.

Zitat:
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 ließe sich noch relativ einfach umsetzen, ist aber dann evtl unschön, wenn die ganzen fixierten Buttons in der Ecke verbleiben, und nur die Paintbox skaliert wird. Mal sehen, was sich da machen lässt...

Zitat:
Während des Sortierens ist "allow doubles" anklick- bzw. umschaltbar.

Ja das habe ich in der tat vergessen - blöder Fehler

Zitat:
Was bedeutet "draw pointers"?

Das sind diese weißen Balken, die anueigen, wo der Algorithmus gerade etwas macht.

Zitat:
Vor allem aber lebt ein solches Programm von diversen Startmengen und zuvörderst natürlich Sortieralgorithmen

Ich habe nicht vor hunderte verschiedener Startmengen auswählbar zu machen. zum Einen verliert man die Übersicht, zum Anderen weiß dann keiner, was was ist. Ich belasse es bei den drei bisher verfügbaren Modi.
Sortieralgorithmen werden natürlich weitere implementiert, aber nicht Zeitnah. Kommt ein wenig darauf an, was wir in Info machen.
Ich habe ja noch paar andere Projekte am laufen, wozu zB auch die BELL gehört, die bei mir jetzt eigentlich im Vordergrund stehen sollten.
So gesehen ist AlgoSort nur ein kleines Randprojekt, zum besseren 'Kennenlernen' von Delphi.

Zitat:
Parallele bzw. simultane Sortieralgorithmen haben "ihren ganz eigenen Reiz", sowohl optisch als auch von der Programmierherausforderung her

Das läuft in etwa auf dasselbe hinaus. Ich werde es bei gelegenheit mal ausprobieren.

_________________
most good programmers do programming not because they expect to get paid or get adulation by the public, but because it's fun to program. (Linus Torvalds)
Symbroson Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 382
Erhaltene Danke: 67

Raspbian, Ubuntu, Win10
C, C++, Python, JavaScript, Lazarus, Delphi7, Casio Basic
BeitragVerfasst: Do 02.11.17 18:34 
Ich hab jetzt die OpenGL Version fertig. Ich musste doch ein extra Fenster machen, weil OpenGL auf der ganzen Form zeichnet. Dafür hab ich die 'Resize' Funktion hinzugefügt ;)
Der QT istleider bisschen durcheinander gekommen - aber es funktioniert irgendwie ^^

Insgesamt ist OpenGL schneller als die standard Graphics Unit, aber langsamer als Graphics32. Hängt vermutlich daran, dass OpenGL alles rendert, GR32 aber nur geänderte Pixel. DoubleBuffering ändert da auch wenig.

schönen Abend noch und lG,
Symbroson

_________________
most good programmers do programming not because they expect to get paid or get adulation by the public, but because it's fun to program. (Linus Torvalds)

Für diesen Beitrag haben gedankt: Delphi-Laie
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1600
Erhaltene Danke: 232


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Fr 24.11.17 23:17 
Hallo Symbroson, derzeit habe ich ein wenig "Luft", um mich wiederum diesem Deinem Projekt zuzuwenden.

Beim Sichten Deines Quelltextes - der "reinen" Delphi-Version - stelle ich fest, daß Du beim Beschreiben des Bitmaps zwecks Erzeugung der Balken (Prozedur "TSortThread._drawArray" in Datei "drawing.inc") eine Fallunterscheidung machst:

ausblenden Delphi-Quelltext
1:
2:
3:
if (bWidth) < 3
then bitmap.canvas.Polyline([Point(x, y), Point(x, cpos[2] + cpos[4])])
else bitmap.canvas.Rectangle(x, y, x + bWidth - 1, cpos[2] + cpos[4]);


Darf ich fragen, warum?

Ich vermute, daß es geschwindigkeitsbedingt ist.

Desweiteren ist mir aufgefallen, daß, wenn man keine Duplikate erlaubt und damit die sortierte Menge ein schönes rechtwinkliges Dreieck ergeben muß, dann in der Open-GL-Version (die mit dem zusätzlichen Darstellungsfenster) die Hypothenuse leider keinen sauberen Verlauf, sondern "kleine Unebenheiten" hat. Das ist in der reinen Delphi- und in der Graphik-32-Version anders, nämlich in Ordnung, mit glatter Hypothenuse. Da die dahinterstehenden Sortieralgorithmen wahrscheinlich dieselben sind, dürfte das nur ein Darstellungsproblem sein.
Symbroson Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 382
Erhaltene Danke: 67

Raspbian, Ubuntu, Win10
C, C++, Python, JavaScript, Lazarus, Delphi7, Casio Basic
BeitragVerfasst: Sa 25.11.17 00:10 
Zitat:
Beim Sichten Deines Quelltextes - der "reinen" Delphi-Version - stelle ich fest, daß Du beim Beschreiben des Bitmaps zwecks Erzeugung der Balken (Prozedur "TSortThread._drawArray" in Datei "drawing.inc") eine Fallunterscheidung machst:

Es macht ja nur Sinn ein Rechteck zu zeichnen, wenn es mehr als ein Pixel breit ist. Zudem lasse ich zwischen Rechtecken immer noch eine Pixelspalte Platz, deswegen 3.

Warum OGL das nicht ganz sauber zeichnet, kann ich dir auch nicht sagen. Ich vermute aber, dass es was mit FloatingPoint zu tun hat, also Rundungsfehler - da ja OpenGL - warum auch immer - grundsätzlich mit Reellen Zahlenwerten rechnet.

_________________
most good programmers do programming not because they expect to get paid or get adulation by the public, but because it's fun to program. (Linus Torvalds)

Für diesen Beitrag haben gedankt: Delphi-Laie
Symbroson Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 382
Erhaltene Danke: 67

Raspbian, Ubuntu, Win10
C, C++, Python, JavaScript, Lazarus, Delphi7, Casio Basic
BeitragVerfasst: So 26.11.17 01:41 
Hab vorhin bemerkt, dass die fast_algorithmen anscheinend bei der Umstrukturierung bei 4.6 verloren gegangen sind. Hab die jetzt wieder eingebaut.
Außerdem sind noch paar andere Dinge geändert und hinzugefügt worden. Steht alles im ersten Post unter Version 4.8.
Hab allerdings nur die std und g32 Version aktualisiert, weil die ogl Version zwei Formulare nutzt und somit die Aktualisierung etwas aufwändiger wäre.
Generell müsste die ogl Version mal etwas aufgebessert werden merk ich grade ^^ aber nicht jetzt und heute

LG

_________________
most good programmers do programming not because they expect to get paid or get adulation by the public, but because it's fun to program. (Linus Torvalds)
Symbroson Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 382
Erhaltene Danke: 67

Raspbian, Ubuntu, Win10
C, C++, Python, JavaScript, Lazarus, Delphi7, Casio Basic
BeitragVerfasst: Mi 29.11.17 00:08 
Ich hab versuchtden TList.Sort algorithmus zu visualisieren - aber irgendwie hab ich da einen ungültigen Zeiger. Seht ihr da auf die Schnelle nen Fehler? Ich hab nen Breakpoint in der Vergleichsfunktion gesetzt und die Zeiger ausgegeben...
Danke im Vorraus,
Symbroson
Einloggen, um Attachments anzusehen!
_________________
most good programmers do programming not because they expect to get paid or get adulation by the public, but because it's fun to program. (Linus Torvalds)