Bubblesort Problem

[Delphi-Laie]

Zitat:

Zitat von EWeiss (Beitrag 1395450)

Zitat:

Ehrlich gesagt, habe ich Dein Problem bis jetzt nicht verstanden.

Ist auch schwierig zu verstehen.. bzw. schwer zu erklären ohne das man das Projekt in Aktion sieht.

Nun, es ist wohl eher ein Problem, eine genaue Reihenfolge zu definieren.

Ein Bubblesort-Problem, wie die Überschrift ankündigt, ist es sicher nicht. Dieser Sortieralgorithmus ist nämlich so simpel, daß sich nahezu immer jemand im Forum findet, beim bloßen Anblick des Quellcodes den Fehler zu entdecken.

Ist die gewünschte Reihenfolge erstmal klar, kann man nämlich (nahezu) jeden Sortieralgorithmus auf jedes Sortierproblem loslassen.

Zitat:

Zitat von EWeiss (Beitrag 1395450)

Kurz gesagt die Objekte werden in der Reihenfolge (ZOrder) nicht richtig gezeichnet.

Und, bist Du Dir sicher, daß es daran liegt, daß die definierte bzw. gewünschte Reihenfolge nicht der tatsächlichen enspricht?

[madas]

Zitat:

Zitat von madas (Beitrag 1395458)

Zitat:

Zitat von EWeiss (Beitrag 1395453)

Zitat:

Zitat von TiGü (Beitrag 1395452)

Lös dein Problem doch erstmal auf Papier, dann kann man über eine Umsetzung reden.

Versuche es gerade mit Pappe.
Oder sollte ich vielleicht doch Papier nehmen.. Hmmm :idea:
Sehe schon komme hier nicht weiter aber wird schon vielleicht bekomme ich noch einen Geistesblitz.

gruss

Meinst Du mit Z-Index sowas hier?

Wenn Du Dir nun z.B. durch die beiden Kugel mit Z-Index 0 drauf die X-Achse denkst,
sollten alle Kugeln mit einem Y-Wert größer 0 einen negativen bzw. kleinen Z-Index bekommen
und alle Kugeln mit einem Y-Wert kleiner 0 einen positiven bzw. hohen Z-Index.
Nun sollte Dir auffallen, dass Du als Z-Index auch einfach den gleichen Wert, wie für den
der Y-Achse nehmen kannst bzw. den negierten Wert davon.

Beispiel (X, Y):

rote Kugel hat die KOs (50, -25), dann wäre der Z-Index einfach 25.
links orange hat die KOs (25, -12,5), dann wäre der Z-Index einfach 12,5.
links gelb hätte die KOs (8, 0), dann wäre der Z-Index einfach 0.
links mint-grün hätte (25, 17), dann wäre der Z-Index -17.
hinten türkis hätte (50, 25), dann wäre der Z-Index einfach -25.

usw.

hängt davon ab, wie Dein KO-System gestrickt ist.

madas

[EWeiss]

Genau so soll es sich drehen (bzw. die Anordnung sein) wie in deinem Bild gezeigt
Na ja werde mal schaun habe noch andere Baustellen.

gruss

[EWeiss]

Zitat:

Ist die gewünschte Reihenfolge erstmal klar, kann man nämlich (nahezu) jeden Sortieralgorithmus auf jedes Sortierproblem loslassen.

Leicht dahin gesagt..

Meine Reihenfolge wird in dem Quelltext definiert.
Welche werte dann im einzelnen entstehen ist abhängig von der Berechnung. (Position der Sprites im Raum)
Noch deutlicher kann man es nicht zeigen.

Wenn deine Aussage zutrifft "(nahezu) jeden" dann frage ich mich warum es dann nicht funktioniert.
Werde mich damit nochmal auseinandersetzen wenn ich meine anderen Baustellen beseitigt habe.

Die Realität ist nicht gleichzusetzen mit Vermutungen!

gruss

[himitsu]

Das Sortieren funktioniert vollkommen korrekt, entsprechend deinem Vergleichskriterium.

Da arbeiten alle Sortieralgorithen erstmal gleich.
Einen Unterschied gibt es nur beim Tempo, der Anzahl der Vergleiche, der Anzahl der Verschiebungen/Tauschungen und ob das Sortieren "gleicher" Werte stabil ist.

stabil = gleiche Werte bleiben in gleicher Reihenfolge.
-> Frank mit 10 Punkten war vor Thomas mit 10 Punkten und ist es nach dem Sortieren immernoch
Und nur auf dieses "stabil" bezog sich das "nahezu",

Wie dein Vergleich arbeitet, das musst du definieren und auch "richtig" implementieren
und schon funktioniert es auch.

[hoika]

Hallo,

Delphi-Quellcode:

for i:=0 to high(numbers)-1 do
begin
  for k:=i+1 to high(numbers) do
  begin
    if numbers[i]>numbers[k] then
    // Tausche

Um noch mal auf die Grundfrage zu kommen.

Bau dir doch mal ein paar Beispiel numbers Arrays und teste deinen Sortieralgorithmus.

Also: Unit-Test

[EWeiss]

Zitat:

Wie dein Vergleich arbeitet, das musst du definieren und auch "richtig" implementieren

Nach meinem Verständnis ist es richtig implementiert.
Siehe den Codeabschnitt.

Ich sehe kein Kriterium im Quelltext der dem widerspricht.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1395570)

Zitat:

Wie dein Vergleich arbeitet, das musst du definieren und auch "richtig" implementieren

Nach meinem Verständnis ist es richtig implementiert.
Siehe den Codeabschnitt.

Ich sehe kein Kriterium im Quelltext der dem widerspricht.

gruss

Hast du denn mal die Variablen Angle, AnglePi und zorder[K] geloggt?

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1395570)

Zitat:

Wie dein Vergleich arbeitet, das musst du definieren und auch "richtig" implementieren

Siehe den Codeabschnitt.

Welchen?

Antwort #6 ... joar, stimmt soweit.

Delphi-Quellcode:

for i := 0 to High(numbers)-1 do
  for k := i+1 to High(numbers) do
    if numbers[i] > numbers[k] then
      Tausche(i, k)

Das

Delphi-Quellcode:

if ... then

musst du natürlich noch richtig implementieren, denn was man hier aus dem Wirrwarr rauslesen kann, ist dein Vergleich ein scheinbar bissl "anders".



Die Generics gibt es schon seit 2009 und 2010 ging es dann "besser".
k.A. ob Generics.Collections.TArray.Sort bei dir schon verfügbar ist.
fand es nicht, aber in der Hilfe fehlte damals auch noch Vieles http://docwiki.embarcadero.com/RADSt...ulltext=Search
Aber auch hier, musst du den Vergleich anpassen.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1395571)

Zitat:

Zitat von EWeiss (Beitrag 1395570)

Zitat:

Wie dein Vergleich arbeitet, das musst du definieren und auch "richtig" implementieren

Nach meinem Verständnis ist es richtig implementiert.
Siehe den Codeabschnitt.

Ich sehe kein Kriterium im Quelltext der dem widerspricht.

gruss

Hast du denn mal die Variablen Angle, AnglePi und zorder[K] geloggt?

Nein.
Was mit jetzt ein Log da bringen würde entschließt sich mir.
Aber wie gesagt bin bereit jemanden das Projekt zu schocken damit er es mal testen kann.
Was nicht bedeuten soll das er meine Arbeit tun soll ;)

gruss