[Merge-Sort] Problem mit Vergleich zweier Arrays

dubstep · Beiträge: 72 Win XP, Win 7 C# (VS 2010)

Hallo!
Ich arbeite seit ca. 9 Monaten mit C# - mittlerweile bin ich bei der objektorientierten Programmierung angelangt und beschäftige mich nebenbei mit diversen Sortieralgorithmen.

Die Aufgabenstellung: Folgendes Array soll mit Merge-Sort sortiert werden

markieren

C#-Quelltext

1:	ArrayList arrayListe = new ArrayList() { 5, 2, 4, 7, 1, 3, 2, 6, 10, 0, 2, 8, 5 };

Mein Lösungsansatz: Das Array in 2 Arrays aufteilen. Im ersten Array stehen dann die Zahlen 5,2,4,7,1,3. Im zweiten ....
Diese beiden Arrays dann wieder aufspalten. Letzendlich erhalte ich dann folgende Arrays:
Array1: 5
Array2: 2,4
Array3: 7
Array4: 1,3
Array5: 2
Array6: 6,10
Array7: 0,2
Array8: 8,5

Ist es möglich die Arrays mit 2 Zahlen nocheinmal aufzuspalten und dann alle Arrays miteinander zu vergleichen?
z.B. if (array1 < array5)
Hier ergibt sich nur ein Problem - System.Collections.ArrayList verbietet mir den Einsatz von Operatoren (weder == noch <,> sind möglich)
Wenn jedenfalls der Vergleich glücken würde, dann könnte man die Arrays in eine Reihenfolge (der größe nach) bringen und dann wieder vereinen.
... mein anderer Vorschlag wäre, die Zahlen in den Arrays miteinander zu verleichen (z.B. if(array2[0] < array2[1])...), aber auch dies funktioniert nicht.
Das Problem hierbei ist, dass ich Arrays ungleicher Größe habe (Arrays mit einer Zahl und Arrays mit zwei Zahlen) und ich keine Ahnung habe wie ich diese miteinander vergleichen und dann wieder vereinen soll.

Das Problem:
1. Das ursprüngliche Array hat eine ungerade Anzahl an Zahlen - das macht die Aufgabe nicht gerade einfach.
2. Der Vergleich von Zahlen in einem Array funktioniert nicht wirklich

Moderiert von Christian S.: C#-Tags hinzugefügt

Xion · Verfasst: Mi 26.05.10 22:14

Du teilst dein Array einfach stur immer durch 2

markieren

Quelltext

1:
2:
3:
4:

4 5 2 3 8
4    5 ||| 2    3   8
4 || 5 ||| 2 || 3   8
4 || 5 ||| 2 || 3 | 8

Jetzt hast du nur noch einelementige Listen. Ich habe mal die Schritte mit verschiedener Anzahl an | dargestellt.

Jetzt fügst du es umgekehrt wieder zusammen

markieren

Quelltext

1:
2:
3:
4:

4 || 5 ||| 2 || 3 | 8
4 || 5 ||| 2 || 3   8
4    5 ||| 2 3 8
2 3 4 5 8

Soweit ich weiß wird das normal rekursiv programmiert nach dem Schema

markieren

Quelltext

1:	prozedur MergeSort (L: array) = Combine( MergeSort(Hälfte1) , MergeSort(Hälfte2) )

_________________
a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)

Kha · Verfasst: Mi 26.05.10 22:46

dubstep hat folgendes geschrieben :

Das Problem hierbei ist, dass ich Arrays ungleicher Größe habe (Arrays mit einer Zahl und Arrays mit zwei Zahlen) und ich keine Ahnung habe wie ich diese miteinander vergleichen und dann wieder vereinen soll.

Hast du dir die Merge-Prozedur bei Wikipedia schon einmal angesehen? Ob die Arrays die gleiche Länge haben oder nicht, spielt dabei eigentlich keine Rolle.

_________________
>λ=

dubstep · Beiträge: 72 Win XP, Win 7 C# (VS 2010)

Danke für eure Hinweise.

Kha hat folgendes geschrieben :

Hast du dir die Merge-Prozedur bei Wikipedia schon einmal angesehen? Ob die Arrays die gleiche Länge haben oder nicht, spielt dabei eigentlich keine Rolle.

Wie Merge-Sort anschaulich arbeitet war/ist mir (bis auf die Länge des Arrays ...) klar.

Ich habe mir diesbezüglich auch einige C#-Codes zu Merge-Sort im Internet angesehen, jedoch sehen die alle ziemlich umfangreich aus, wobei sie alle nur, der im Wikipedia-Artikel beschriebene Implementierung folgen - also dürfte es nichts kürzeres oder einfacheres geben.

Eine Möglichkeit den Code transparenter zu gestalten wäre, die Arrays wie vorhin aufzuspalten (bis nur mehr 2 Zahlen drinnen sind) und die Zahlen in diesem Array dann zu sortieren mit arrayname.Sort();.
Mit allen anderen Arrays geht man ebenfalls so vor. Dann fügt man immer jeweils zwei sortierte Arrays mit arrayname.AddRange(arrayname); zusammen. Dieses wird dann wieder sortiert und mit einem weiteren zusammengefügt - bis man dann nach n-Schritten wieder ein großes Array hat.
Ich habe nur die Befürchtung, dass dies zwar zum Ziel führt (ein sortiertes Array), aber absolut nicht der Notation des Merge-Sort entspricht - es ist irgendein Sortieralgorithmus (ein höchstwahrscheinlich sogar total ineffizienter, da man das ursprüngliche Array ja ohne zu teilen einfach mit arrayname.Sort(); sortieren lassen könnte), aber kein Merge-Sort.

Xion hat folgendes geschrieben :

Soweit ich weiß wird das normal rekursiv programmiert nach dem Schema

Ja stimmt, es soll rekursiv sein.

Xion · Verfasst: Do 27.05.10 14:30

dubstep hat folgendes geschrieben :

Ich habe nur die Befürchtung, dass dies zwar zum Ziel führt (ein sortiertes Array), aber absolut nicht der Notation des Merge-Sort entspricht - es ist irgendein Sortieralgorithmus (ein höchstwahrscheinlich sogar total ineffizienter, da man das ursprüngliche Array ja ohne zu teilen einfach mit arrayname.Sort(); sortieren lassen könnte), aber kein Merge-Sort.

Da hast du allerdings recht. Es ist immer eine dumme Idee array.Sort zu verwenden wenn man einen Sortieralgorithmus machen will.

Scheinbar hast dus doch nicht so ganz verstanden wie Merge Sort funktioniert.

Denn die Arrays zusammenzufügen und .Sort ist ja sinnlos (wie schon von dir erkannt). Der Witz an Merge Sort ist, dass es schneller geht, 2 sortierte Arrays zusammenzuführen als beide Hälften auf einmal zu sortieren. Du machst also mit dem .Sort den ganzen Sinn kaputt.

Beim 2-elementigen Array kannst du vielleicht .Sort verwenden, das mag gut gehen. Ne einfache if-Abfrage tuts aber auch.

Wenn du 2 Arrays zusammenführen willst, dann geht das mit 2 Indizes, die beide Arrays durchlaufen. Das ist schneller als sortieren, daher der Vorteil von Merge-Sort. Es ist einfacher 2 halbe Stapel Karten zu sortieren und zusammen zu fügen, als den ganzen Stapel auf einmal zu sortieren. So sortiert man z.B. einen Satz Karten erst nach Typ (König, Bube, Dame, Ass) und danach die einzelnen Könige nach Farbe.

Beispiel: Zusammenfügen von 2 3-elementigen Arrays

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:

4 6 9
^
1 5 7
^

1<4?

=>
4 6 9
^
1 5 7
  ^
= 1

4<5?

=>
4 6 9
  ^
1 5 7
  ^
= 1 4


6<5?

=>
4 6 9
  ^
1 5 7
    ^
= 1 4 5

...

_________________
a broken heart is like a broken window - it'll never heal
In einem gut regierten Land ist Armut eine Schande, in einem schlecht regierten Reichtum. (Konfuzius)

dubstep · Beiträge: 72 Win XP, Win 7 C# (VS 2010)

Nach ein bisschen Recherche bezüglich MergeSort bin ich es jetzt folgendermaßen angegangen:
Man hat zwei Methoden. Eine die MergeSort heißt und das Array (egal wie groß das ursprüngliche Array ist), in zwei neue Arrays aufteilt (genannt z.B. ArrayList rechts und ArrayList links).
Und eine zweite Methode Merge, welche für den Sortiervorgang verantwortlich ist und aus einer while-Bedingung, sowie mehreren verschachtelten if-Abfragen besteht.

habe ich jetzt statt array.Sort folgenden Sortiervorgang implementiert:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

if (((IComparable)links[i]).CompareTo(rechts[j]) > 0)
{
ergebnis.Add(rechts[j]);
j++;
}

else
{
ergebnis.Add(links[i]);
i++;
}

Die paar Zeilen Code würde ich folgendermaßen interpretieren:

Vergleiche ob das Item in der Arraylist "links" oder ArrayList "rechts" größer ist - dazu:
Wenn ArrayList „links“ an der Stelle i größer ist, als ArrayList „rechts“ an der Stelle j (i muss nicht gleich j sein), dann füge die Zahl an aus ArrayList „rechts“ an der Stelle j in die ArrayList „ergebnis“ ein. Weiters erhöhe den Index j um 1. Es wird um eine Stelle in ArrayList „rechts“ weiter vorgerückt – ArrayList „links“ hingegen behält seine Position. Beim nächsten Durchlauf wird dann wider verglichen.

Wenn ArrayList „links“ an der Stelle i kleiner ist, als ArrayList „rechts“ an der Stelle j (i muss nicht gleich j sein), dann füge die Zahl aus ArrayList „links“ an der Stelle i in die ArrayList „ergebnis“ ein. Weiters erhöhe den Index i um 1. Es wird um eine Stelle in ArrayList „links“ weiter vorgerückt – ArrayList „rechts“ hingegen behält seine Position. Beim nächsten Durchlauf wird dann wider verglichen.

Noch ein paar Fragen haben sich ergeben:
Stimmt das? > IComperable ist eine Standardsortierreihenfolge. IComperable macht den Vergleich von Objekten während der Sortierung. CompareTo gehört ebenfalls zu IComperable

Was sagt das "CompareTo(... > 0)" aus?

Ist ein Array das selbe wie eine ArrayList?

Edit: C#-Quelltext eingefügt

JüTho · Verfasst: Do 03.06.10 09:18

Hallo,

da ich mich mit Sortierung nicht befasse (ich benutze sie einfach), halte ich mich aus der eigentlichen Diskussion heraus. Aber ein paar Hinweise habe ich:

Zitat:

Ist ein Array das selbe wie eine ArrayList?

Nein. Ein Array ist eine Liste von Elementen eines bestimmten Typs, z.B. Integer-Array; die Anzahl der Elemente wird bei der Erzeugung vorgegeben und kann eigentlich nicht mehr geändert werden. Eine ArrayList ist eine Liste von Elementen beliebigen Typs (nämlich vom Typ Object), der Elemente hinzugefügt oder entnommen werden können.

Damit sind die wesentlichen Unterschiede deutlich:
* Array: starr, aber für jedes Element ist der Typ bekannt und kann sofort genutzt werden.
* ArrayList: in der Größe flexibel, aber jedes Element muss erst konvertiert werden, bevor es als Objekt eines bestimmten Typs benutzt werden kann.

Deshalb gilt auch die allgemeine Regel: ArrayList gehört in die Mottenkiste und sollte wie alle untypisierten Collections aus System.Collections nicht mehr benutzt werden. Verwende stattdessen List<T> und alle anderen typisierten Collections aus System.Collections.Generic.

Gruß Jürgen

dubstep · Beiträge: 72 Win XP, Win 7 C# (VS 2010)

Noch eine Frage, die leider nur indirekt etwas mit MergeSort zu tun hat.

Ist folgende Behauptung korrekt?
MergeSort: Ist ein stabiler (rekursiver) Sortieralgorithmus (warum eigentlich stabil - vielleicht weil sich die Laufzeit mit einer guten Wahrscheinlichkeit vorhersagen lässt?) und hat nie eine längere Laufzeit als O(n*log(n)) bei einer Eingabegröße von n, was ja eigentlich ganz akzeptabel ist. Im besten Fall hat MergeSort Laufzeit n (lineare Laufzeit) bei einer Eingabegröße von n.
Wann tritt nun der beste Fall ein? Eventuell wenn die Zahlenfolge gar nicht mehr sortiert werden muss? Der schlechteste Fall tritt ein, wenn alle Elemente gemergt werden müssen?

QuickSort: Ist ein instabiler (rekursiver) Sortieralgorithmus. Instabil, weil die Angabe der Laufzeit nur sehr schwer vorhergesagt werden kann? (Wenn ja, warum eigentlich? - Eventuell weil der WorstCase durchaus auch oft eintreten kann?)
BestCase: f(n) - wenn nicht mehr sortiert werden muss; WorstCase: f(n²) - quadratische Laufzeit, wenn jede Zahl getauscht werden muss und sich der Index i oder j ganz am Ende oder Anfang des geteilten Arrays befindet?

Unterschied im Ablauf von MergeSort und QuickSort:
MergeSort teilt ein Array mit Zahlen immer durch zwei - damit hat man dann zwei Arrays - diese werden dann aber nicht mehr geteilt, sondern nur noch in sortierter Reihenfolge (mit Methode "Merge") in ein neues leeres Array geschrieben.
QuickSort sucht sich erst mal eine Stelle, an der das Array geteilt wird. Das kann an jeder Position sein, am besten ist es jedoch, wenn beide dann geteilten Arrays gleiche Größe haben, wobei das linke Teilarray nie größer als das rechte sein darf. Im schlechtesten Fall wird das Array so geteilt, dass ein Array z.B. eine Zahl hat und das andere n-Zahlen hat - Also von total unterschiedlicher Größe sind. Dann durchläuft ein Index nämlich (z.B. j) von der rechten zur linken Seite des rechten Teilarrays und benötigt dafür ziemlich viel Zeit, während der linke Index (z.B. i) sofort fertig ist, weil er ja nur eine Stelle zu durchlaufen hat - dies wäre dann der WorstCase. Jedenfalls hat man bei QuickSort zwei mal Index (i und j) - wovon i am Anfang beginnt und das Array bis zum Ende durchläuft und j zeitgleich wie i beginnt das Array zu durchlaufen, jedoch am Ende beginnt und es bis zum Anfang durchläuft.

Ich hoffe da waren jetzt nicht einige Aussagen falsch - wenn doch bitte ich um Korrektur. Vielen Dank für eure Hilfe!

elundril · Verfasst: Sa 05.06.10 20:07

Tut mir leid aber so ziemlich alle deine aussagen sind falsch. Am besten ist wenn du dir nochmal die wikipedia-artikel durchliest:

de.wikipedia.org/wiki/Quicksort
de.wikipedia.org/wiki/Mergesort
de.wikipedia.org/wik...les_Sortierverfahren

Grundlagen:
de.wikipedia.org/wik...che_%28Informatik%29

_________________

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril · Verfasst: So 06.06.10 02:54

Also, da dir bis jetzt noch immer keiner geantwortet hat und ich gerade mehr Zeit habe als am Nachmittag, beantworte ich die Fragen:

Stabil hat nichts mit der Laufzeit zu tun. Stabil hat was mit den Elementen zu tun die du sortierst. Ein stabiler Algorithmus tauscht Elemente nicht, wenn die Schlüssel gleich sind. Ein Beispiel: Du hast dem Namen nach alphabetisch sortierte Personendaten (Name, Telefonnummer) und du willst diese Daten jetzt nach der Telefonnummer sortiert haben. Bei einem stabilen Algorithmus werden jene Personen mit gleicher Telefonnummer auch in alphabetischer Reihenfolge gelassen (es werden keine unnötigen Vertauschungen durchgeführt), bei einem nicht stabilen Algorithmus ist das nicht der Fall.

MergeSort hat immer die Laufzeit n * log(n), weil immer die bestehende Folge durch 2 dividiert wird, solange bis nur noch ein Element in der bestehenden Teilfolge ist. Also die Folge wird immer in der Mitte geteilt. Dadurch ist dieser Algorithmus im Worst-Case-Verhalten besser, weil er immer n * log(n) bleibt, egal wie die Folge von Schlüsseln ausschaut die du reingibst. Demnach merken wir uns: Bei MergeSort ist Worst-Case = Average-Case = Best-Case = n * log(n). (Wie wir daraus sehen können, gibt es hier keinen besten und schlechtesten Fall, alle sind gleich)

Ohoho, bei Quicksort müssen wir aufpassen. Quicksort hat nämlich die fiese Angewohnheit einen Worst-Case-Fall zu haben wenn die Eingabefolge schon sortiert ist! In der Implementierung nach Wikipedia (und auch in meinen Uniskriptum) wird als Pivotelement immer das rechteste Element genommen. Da jetzt das Pivotelement eigentlich die Folge in 2 teile spalten sollte, funktioniert das bei einer schon sortierten Folge nicht. Aus dem Grund fällt immer nur das Pivotelement aus der Liste und wir haben n*n Schritte beim Sortieren. Blöde Sache, weil wir dadurch eine Worst-Case-Laufzeit von n² haben. Eindeutig schlechter als bei MergeSort.
Das blöde ist nun das Average-Case und Best-Case jeweils auch nur n * log(n) hat. Wo ist dann der Vorteil gegenüber MergeSort, wenn der doch auch im Worst-Case n*log(n) hat und QuickSort n²? Einfach weil es bestimmte Variationen von QuickSort gibt, bei denen man diese Worst-Case-Laufzeit verbessern kann. Außerdem ist seine Laufzeit in der inneren Schleife kürzer, was ihn schneller macht und er arbeitet In-Place.
In-Place, was ist das nun wieder für ein Blödsinn? In-Place bedeutet das er nur konstant viel Speicher zum arbeiten braucht, weil er die Elemente innerhalb der Liste sortiert, wenn man es richtig macht.

Deine letzte Zusammenfassung versteh ich nicht. Beide Algorithmen teilen die Folgen immer in zwei Teilfolgen. Am besten ist wenn du dir die Grafiken bei Wikipedia anschaust. Da siehst du das sowohl MergeSort als auch Quicksort die Folgen immer in zwei Teile teilen. Der Unterschied ist das MergeSort seine Folgen immer in der Mitte spaltet, also beim element an der Stelle "Länge-der-Folge / 2".
Quicksort hingegen teilt seine Folgen auf Grund des Wertes im Pivotelement. Das heißt, dass alle elemente die kleiner sind als das pivotelement auf die linke seite kommen und alle die größer sind auf die rechte seite (und an letzter stelle steht das pivotelement). Dann wird der erste Wert der größer ist als das Pivotelement mit dem Pivotelement getauscht und der spass geht erneut los nur halt jetzt mit der linken seite (dort wo alle elemente kleiner sind als das pivotelement). Auch hier ist die Grafik von Wikipedia hilfreich.

ich hoff das ich halbwegs die fragen klären konnte.

lg elundril

_________________

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

dubstep · Beiträge: 72 Win XP, Win 7 C# (VS 2010)

elundril hat folgendes geschrieben :

Ich hoff das ich halbwegs die fragen klären konnte.

Ja danke, das hilft mir sehr! Ich war etwas enttäuscht von meiner anscheinend total falschen Auffassung der Sortieralgorithmen - ich hatte mir nämlich schon bevor ich meinen Text ins Forum schrieb, die Wikipedia-Artikel durchgelesen.
Eine kurze Frage noch: Auf Wikipedia steht zu InsertionSort, dass dieser im BestCase eine lineare Laufzeit (=n) aufweist und im WorstCase eine quadratische Laufzeit. In meinem Skript steht: "Es gibt ein c2, sodass die Laufzeit von InsertionSort bei allen Eingaben der Größe n immer höchstens c2n² ist. Es gibt ein c1, sodass für alle n eine Eingabe "In" der Größe n existiert bei der InsertionSort mindestens die Größe c1n² besitzt."
So wie ich das jetzt herauslese, wird hier behauptet, dass InsertionSort sowohl im BestCase, als auch im WorstCase die Laufzeit n² hat - dies würde jetzt aber irgendwie dem Wikipedia-Artikel widersprechen. "c" sollte denke ich die systemabhängige unbekannte Konstante sein, welche aufgrund ihrer unbekannten Größe ebenfalls ein Risiko darstellt.

Jedenfalls vielen Dank für deine Antwort!

Edit: Rechtschreibfehler ausgebessert

alzaimar · Verfasst: So 06.06.10 10:53

elundril hat folgendes geschrieben :

Ohoho, bei Quicksort müssen wir aufpassen. Quicksort hat nämlich die fiese Angewohnheit einen Worst-Case-Fall zu haben wenn die Eingabefolge schon sortiert ist!

Ab "..wenn die" wird's nicht ganz richtig.

Richtig ist: QS hat einen Worst-Case. Falsch ist "wenn die Eingabefolge schon sortiert ist". Der Worst-Case hängt von der Wahl des Pivot-Elementes ab. Wenn der Worst-Case in der Realität sehr unwahrscheinlich ist, muss ich mir darüber dann keine großen Gedanken machen. Das 'sortiert Listen' kein sehr unwahrscheinlicher Fall ist, würde ich also das Pivot-Element nicht so wählen, wie Du beschrieben hast.

Es gibt lustige Variationen, z.B. den, das Pivot-Elemtn per Random auszuwählen. Dann gibt es zwar einen Worst-Case, der aber m.E. nicht zu bestimmen ist.

_________________
Na denn, dann. Bis dann, denn.

Kha · Verfasst: So 06.06.10 11:06

dubstep hat folgendes geschrieben :

So wie ich das jetzt herauslese, wird hier behauptet, dass InsertionSort sowohl im BestCase, als auch im WorstCase die Laufzeit n² hat

Nein. Der erste Satz sagt aus, dass die Laufzeit nie größer als quadratisch ist, der zweite, dass dieser Fall auch wirklich eintreten kann, also tatsächlich die untere Grenze darstellt. Es wird also nichts über den Best Case, nur über den Worst Case ausgesagt.

_________________
>λ=

elundril · Verfasst: So 06.06.10 16:01

alzaimar hat folgendes geschrieben :

elundril hat folgendes geschrieben :

Ohoho, bei Quicksort müssen wir aufpassen. Quicksort hat nämlich die fiese Angewohnheit einen Worst-Case-Fall zu haben wenn die Eingabefolge schon sortiert ist!

Ab "..wenn die" wird's nicht ganz richtig.

Richtig ist: QS hat einen Worst-Case. Falsch ist "wenn die Eingabefolge schon sortiert ist". Der Worst-Case hängt von der Wahl des Pivot-Elementes ab. Wenn der Worst-Case in der Realität sehr unwahrscheinlich ist, muss ich mir darüber dann keine großen Gedanken machen. Das 'sortiert Listen' kein sehr unwahrscheinlicher Fall ist, würde ich also das Pivot-Element nicht so wählen, wie Du beschrieben hast.

Richtig, vielleicht hätte ich diesen Satz voranstellen soll, damit klar wird das ich die Implementierung meine bei der immer das rechteste Element nehme.

elundril hat folgendes geschrieben :

In der Implementierung nach Wikipedia (und auch in meinen Uniskriptum) wird als Pivotelement immer das rechteste Element genommen.

alzaimar hat folgendes geschrieben :

Es gibt lustige Variationen, z.B. den, das Pivot-Elemtn per Random auszuwählen. Dann gibt es zwar einen Worst-Case, der aber m.E. nicht zu bestimmen ist.

Das steht bei mir aber nicht mehr unter dem Schlagwort QuickSort sondern unter Randomisiertem Quicksort. (Was ich auch erwähnt habe)

So, soviel zu meiner Verteidigung. :mrgreen:

lg elundril

_________________

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

alzaimar · Verfasst: So 06.06.10 21:37

elundril,

Du hast alles richtig gemacht und auch erwähnt.
Ich wollte es nur auch mal gesagt haben.
So als Trittbrettfahrer sozusagen ;-)

_________________
Na denn, dann. Bis dann, denn.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme