JWINF – Einführung Logische Verknüpfung - 3 Sterne?
Hallo zusammen!
Ich muss die folgende Aufgabe lösen, darf dafür aber maximal 25 Blöcke verwenden. Leider komme ich dabei nicht weiter, hat jemand eine Idee?
Danke im Voraus!
Solltest du die nicht allein lösen, aber naja
Es ist nur eine Trainingsaufgabe und ich würde gerne einen Denkanstoß haben, weil mir nicht wirklich einfällt, wie man das in weniger als 25 Blöcken lösen könnte.
3 Antworten
Also du siehst dort ja eine Art Muster, eine Treppe sozusagen. Am einfachsten wäre es, hätte der Roboter einen Sensor, dann könntest du einfach für 10 mal nach rechts und dann hoch und zehn mal nach links und alles einfärben, wo eine Markierung ist. Dann wieder nach oben. Und das fünf mal. In der letzten Reihe müsstest du noch 10 mal nach rechts.
Leider hat der Roboter keinen Sensor und du musst ihm sagen, welches Feld angemalt werden muss. Dafür kann der Roboter die Koordinaten der einzelnen Felder lesen.
Leider ist es a) umständlich den Roboter Schritt für Schritt die Richtung zum nächsten anzumalenden Feld zu sagen und ihn zu sagen, ob es sich um ein anzumalendes Feld handelt b) brauchst du dafür zu viele Blöcke.
Generell gibt es schon 33 anzumalende Felder, daher kannst du die Informationen über den Zustand eines Feldes nicht einzeln eintragen.
Allerdings muss der Zustand eines Feldes klar sein. Daher müssen diese Informationen komprimiert werden. Wie du leicht erkennen kannst, sind die anzumalende Punkte nicht wahllos verteilt, sondern in einer Art Treppe (vernachlässigen wir fürs erste mal die Lücke).
Wenn wir uns die Anordnung mal genauer ansehen, sehen wir, dass die unterste Reihe gar keine bepunkteten Felder enthält, diese müssen wir also eigentlich gar nicht durchlaufen. Sie ist sowieso leer.
Nun wenn wir das erste Mal nach rechts gehen, können wir auch alles anmalen, wenn wir nur rechtzeitig aufhören. (Ich überlass dir mal, dir zu überlegen, wie genau man beschreiben kann, wann der Roboter aufhören muss. Ein Tipp an der Stelle wo er aufhören muss, also am jeweils weitesten rechten bepunkteten Feld, herrscht eine bestimmte Relation zwischen der x und y Koordinaten. Quasi wie eine lineare Funktion. Deswegen die Treppe)
Aufgrund dieser Treppe, wäre es auch einfacher nun die Reihen nach rechts zu durchlaufen, danach wieder nach links und dann erst nach oben zu gehen. Damit du jeweils wieder in vergleichbaren Situationen kommst und effizienter herausfinden kannst, wie du zum rechtesten bepunkteten Feld kommst.
So sähe der Code dann ungefähr aus:
start;
gehe nach oben;
wiederhole (8) mal{
wiederhole (8) mal{
falls (reihe > spalte){
falls (reihe < 5 oder reihe > 7){
färbe Feld;
}
}
gehe nach oben;
}
}
Graphisch betrachtet entspricht die Zunahme der Reihennummer dem runter
Danke für die schnelle und ausführliche Antwort! Leider verstehe ich es trotzdem nicht wirklich, wie man oben die Treppe anmalen kann...
Vielleicht ist dir schon aufgefallen, dass für die Y-Koordinate (senkrechte Achse/die Zeilenreihen) der obersten markierten Felder gilt, dass sie den Wert der X-Koordinate (horizontale Achse/die Spaltenreihe) +1 sind. Also Y = X + 1. Als Beispiel das Feld (1|2), wobei 1 = x ist und 2 = y. Dort ist Y auch um eins größer als x. So ist das aufgrund der Stufen überall.
Jetzt ist noch offen, wie man mit dieser Information umgehen soll.
Und zwar musst du deine Code-Blöcke so nutzen, dass du zwei Schleifen hast. Eine äußere und eine die in der anderen Schleife drin ist.
Fangen wir mit der inneren an, diese sorgt dafür, dass du die einzelnen Spalten hoch und runter läufst. Oh, eigentlich müssen es auch zwei innere Schleifen sein. Die eine zum hochlaufen und die andere zum runterlaufen.
Jetzt kommen wir zum Kernproblem. Wie stellt man die Schleife zum Hochlaufen richtig ein? Tatsächlich wäre es am einfachsten, wenn du einfach bis ganz nach oben läufst, also NEUN mal. Warum nicht zehn mal? Weil du GANZ AM ANFANG am besten schon mal ein Feld hochläufst, damit du mit deinen Schleifen nicht die untere Reihe durchläufst. Dort sollst du ja bekanntlich nix markieren. (Wenn du dort mit Hilfe der Schleifen lang gehen würdest, müsstest du dir nämlich noch mal extra überlegen, wie du verhindert, dass diese Felder auch markiert werden.) Der Clue ist dann die falls-Verzweigung mit der Bedingung Zeile des Roboters > Spalte des Roboters. Innerhalb der falls-Verzweigung brauchst du dann die färbe Feld-Methode. Außerhalb der Verzweigung aber innerhalb der Schleife musst du dann noch nach oben gehen.
Die Schleife hätte dann folgende Auswirkung:
Ausgangsfeld: (2|10) (also zweite Reihe)
10 > 2 => ja, färbt das Feld
Geht hoch in Feld (2|9)
9 > 2 => ja, färbt das Feld
...
Geht hoch in Feld (2|3)
3 > 2 => ja, färbt das Feld
Geht hoch in Feld (2|2) welches nicht markiert ist
2 > 2 => nein, geht nur noch bis ganz oben.
Also im Prinzip ist eine normale Schleife zum hochlaufen, nur dass du innerhalb der Schleife noch vor dem hochlaufen eine weitere allerdings bedinkte Aktion hast.
Die Bedingung ist im Endeffekt, dass das aktuelle Feld markiert ist. Allerdings musstest du es halt so ausdrücken, dass man es nur mit Hilfe der Koordinaten entscheiden kann und dort gilt halt, wenn die Zahl der Reihe größer ist als die der Spalte, ist das Feld markiert. Das gilt nicht für die unterste Reihe, aber dadurch, dass wir nicht die unterste Reihe durchlaufen ist es egal. Übrigens gilt die erwähnte Regel auch nicht für Spalte 5 bis 7.
Die zweite innere Schleife ist, damit du wieder bis zum untersten markierten Feld zurückläufst. Jetzt müsstest du noch gucken, wie du mit der äußeren Schleife bewirkst, dass das nicht nur in einer, sondern allen relevanten Spalten passiert.
Edit:
Vielleicht ist dir schon aufgefallen, dass für die Y-Koordinate (senkrechte Achse/die Zeilenreihen) der rechtesten markierten Felder gilt, dass sie den Wert der X-Koordinate (horizontale Achse/die Spaltenreihe) +1 sind. Also Y = X + 1. Als Beispiel das Feld (3|4), wobei 3 = x ist und 4 = y. Dort ist Y auch um eins größer als x. So ist das aufgrund der Stufen überall.
Jetzt ist noch offen, wie man mit dieser Information umgehen soll.
Und zwar musst du deine Code-Blöcke so nutzen, dass du zwei Schleifen hast. Eine äußere und eine die in der anderen Schleife drin ist.
Fangen wir mit der inneren an, diese sorgt dafür, dass du die einzelnen Reihen nach links und rechts durch äufst. Oh, eigentlich müssen es auch zwei innere Schleifen sein. Die eine zum nach links laufen und die andere zum nach rechts laufen.
Jetzt kommen wir zum Kernproblem. Wie stellt man die Schleife zum nach links laufen richtig ein? Tatsächlich wäre es am einfachsten, wenn du einfach bis zum weitest rechts markierten Feld durchlaufen lässt, also ACHT mal. Ganz am Anfang solltest du allerdings ein Feld hochlaufen, damit wir die Schleife in der letzten markierten Reihe starten lassen. Dort sollst du ja bekanntlich nix markieren. (Wenn du dort mit Hilfe der Schleifen lang gehen würdest, müsstest du dir nämlich noch mal extra überlegen, wie du verhindert, dass diese Felder auch markiert werden.) Der Clue ist dann die falls-Verzweigung mit der Bedingung Zeile des Roboters > Spalte des Roboters. Innerhalb der falls-Verzweigung brauchst du dann die färbe Feld-Methode. Außerhalb der Verzweigung aber innerhalb der Schleife musst du dann noch nach rechts gehen.
Die Schleife hätte dann folgende Auswirkung:
Ausgangsfeld: (1|4) (also vierte Spalte)
4 > 1 => ja, färbt das Feld
Geht nach rechts in Feld (2|4)
4 > 2 => ja, färbt das Feld
Geht nach rechts in Feld (3|4)
4 > 3 => ja, färbt das Feld
Geht nach rechts in Feld (4|4) welches nicht markiert ist
4 > 4 => nein, geht nur noch nach rechts, bis auf Höhe des letzten markierten Felds.
Also im Prinzip ist eine normale Schleife zum nach rechts laufen, nur dass du innerhalb der Schleife noch vor dem laufen eine weitere allerdings bedinkte Aktion hast.
Die Bedingung ist im Endeffekt, dass das aktuelle Feld markiert ist. Allerdings musstest du es halt so ausdrücken, dass man es nur mit Hilfe der Koordinaten entscheiden kann und dort gilt halt, wenn die Zahl der Reihe größer ist als die der Spalte, ist das Feld markiert. Das gilt nicht für die unterste Reihe, aber dadurch, dass wir nicht die unterste Reihe durchlaufen ist es egal. Übrigens gilt die erwähnte Regel auch nicht für Spalte 5 bis 7.
Die zweite innere Schleife ist, damit du wieder bis nach links zurückläufst. Jetzt müsstest du noch gucken, wie du mit der äußeren Schleife bewirkst, dass das nicht nur in einer, sondern allen relevanten Reihe passiert.
Ich würde das komplette Feld ablaufen, aber von (1,10) starten, also vorher noch eins hochgehen. Dann mehrfach wiederholen verwenden:
- hoch
- wiederhole 8x
- wiederhole 8x
- falls (Bedingungen siehe unten) mache Färbe feld
- hoch
- wiederhole 8x
- runter
- rechts
Für den Check, ob du Färben willst, musst du dir jetzt die Bedingungen ausdenken. Da du beim Ablaufen nach dem Muster Zeile 1 und 10 und Spalte 10 und 11 nicht erreichst, kannst du die in der Betrachtung weglassen. Du brauchst für den Check den Vergleich (zwischen Zeile/Spalte und Zahl) und das UND/ODER Element mehrfach.
UND
- Zeile > Spalte
- ODER
- Spalte <5
- Spalte >7
Vom Ansatz her richtig. Aber:
- es gibt kein „runter“. Du musst zeilenweise nach oben laufen.
- Beide Schleifen müssen 9x laufen.
Hast recht, dann muss man die Richtung in den Schleifen ändern und die Bedingungen in meinem Fall auch tauschen. Das habe ich nicht gecheckt.
Alternativ kann man die Spalten schon innerhalb der äußeren Schleife prüfen und die Schleifen in den unteren Teil des Falls-Blocks reinrücken. Dadurch würden die Spalten 5 bis 7 erst gar nicht abgelaufen werden. Stattdessen würde der Roboter die inneren Schleifen überspringen und direkt weiter nach rechts gehen.
Hallo.
Du brauchst einen Denkanstoß? Das ist recht einfach. Stell dir vor das waren alles Räume in einem großen Haus. In manchen Räumen ist ein Schatz versteckt.
Du kannst nicht von oben in die Räume gucken, sondern müsstest du durch Türen in den nächsten Raum gehen. Jeder Raum hat zu jedem benachbarten Raum eine Tür, wobei du nur nach rechts, links und oben, aber nicht nach unten gehen kannst.
Wie würdest du vorgehen, wenn du jeden Schatz einsammeln (den Raum einfärben) möchtest? Natürlich willst du jeden Raum dabei absuchen. Nach welchem System würdest du vorgehen?
Reicht dir das als Denkanstoß?
LG
Das Problem ist ja, dass es die Information darüber, ob irgendwo ein Schatz liegt nur mit den Koordinaten verbunden ist, wenn man den Raum betritt, sieht man den Schatz quasi nicht, weil man keine Sensoren/Augen dafür hat.
Gibt es hierbei eine Abfrage, ob in dem Feld markiert ist?
Falls ja, läuft es Im Grunde so ab. Als Pseudocode:
- Wiederhole 10 mal: > Falls Feld markiert, färbe Feld. -> Gehe nach rechts
- Falls Reihe > 1, Gehe nach oben
- Wiederhole 10 mal: > Falls Feld markiert, färbe Feld. -> Gehe nach links
- Falls Reihe > 1, Gehe nach oben
Und das Schema führst du so lange fort, bist du bei Reihe 1, Spalte 11 angekommen bist.
LG
Nein, gibt es eben nicht. Das ist der springende Punkt. Der Prüfling kennt allerdings die zu markierenden Felder und soll daraus ein Algorithmus entwerfen. Die Schwierigkeit dieser Aufgabe liegt schlicht weg nicht darin einfach eine Art Matrix zu durchlaufen, sondern überhaupt erstmal eine Regel für das Auftreten der markierten Felder zu finden und dann herauszufinden, wie man diese Prüfung implementiert. Dabei muss man ganz auf Hilfsvariablen verzichten, was die Aufgabe erschwert. Das lässt sich aus den, im Blockbaukasten, zu Verfügung stehenden Blöcken erschließen.
Sorry, aber das ergibt wenig Sinn.
Zwar könnte man eine Art Musterdurchlauf generieren, aber nicht, wenn man den Schleifenkopf nicht entsprechend anpassen/verändern kann.
Zumal der Sinn der Übung nicht ersichtlich ist, wenn dem so wäre, wie du es darstellst.
Ich nahm die Tatsache dafür, dass die "10" innerhalb des Schleifenbausteins in so einer Box war als Indikator dafür, dass man die Schleifen sehrwohl anpassen kann. Denn auch das "==" befindet sich in so einer Box. Neben dem "==" ist so ein umgekehrtes "^" was impliziert, dass wohl auch andere Vergleiche gemacht werden können, wie ">=". Nun wenn man das einstellen kann, warum sollte man nicht den Schleifenkopf einstellen?
Da es sich um ein Informatik-Wettbewerb handelt, ergibt es auch Sinn, dass man hier ein kniffligeres Problem hat. Es ist eben keine Informatikhausaufgabe in der man lediglich etwas vergleichbares zu zweidimensionalen Arrays durchlaufen soll. Im Känguruwettbewerb wird wahrscheinlich auch keine reguläre Dreisatzaufgabe auftauchen.
Das erscheint mir alles doch ein bisschen merk- und fragwürdig.
Alleine dass du interpretierst, dass du mit 2x rechts bzw. links dann aus oben ein "unten" machen kannst, als hätte der Reiter eine Pfeil-Richtung. Würde man es dann statt "oben" nicht einfach "vorwärts" nennen?
Auch die Anpassung des Schleifenkopfs halte ich für merkwürdig, wo es doch immer genau 10 Schritte sind, die man für eine Zeile braucht. Zufall dass da ein fixer Wert eingetragen ist, der genau darauf abgestimmt zu sein scheint, man diesen aber vermeintlich anpassen kann, während die anderen Elemente frei anpassbar (leer) sind?
Und zu guter Letzt, wofür bräuchte man die Abfrage-Bedingungen, wenn man einfach nur ein vorgefertigtes Konstrukt aufbauen sollen, das nur genau für dieses eine Muster passt?
Wäre es nicht wesentlich sinnvoller, auch vom Lernfaktor her, wenn man eine allgemein gültige Lösung kreiert, die jede beliebige Anordnung von markierten Feldern passend einfärbt?
Sorry, ich bleibe dabei. Eine statische Lösung erscheint mir basierend auf den gerade genannten Argumenten unwahrscheinlich.
LG
Alleine dass du interpretierst, dass du mit 2x rechts bzw. links dann aus oben ein "unten" machen kannst, als hätte der Reiter eine Pfeil-Richtung. Würde man es dann statt "oben" nicht einfach "vorwärts" nennen?
So wollte ich das nicht vermitteln. Du hast recht, der Reiter dreht sich nicht. „Nach rechts” , sollte bedeuten, dass der Roboter seine Position um eine Spaltennummer erhöht. "Nach links" wäre das Gegenteil davon. Und mit "oben" und "unten" soll das Äquivalent für die Änderung der Reihennummer gemeint sein. In den Blockbaukasten wird das durch den Zusatz "gehe nach..." verdeutlicht. Es gibt also gar kein vorwärts, rückwärts oder drehen, da es anders als bei Phyton Turtle z.B. keinen Vektor gibt, der ein vorne beschreibt. Allerdings bin ich auch nie davon ausgegangen.
Auch die Anpassung des Schleifenkopfs halte ich für merkwürdig, wo es doch immer genau 10 Schritte sind, die man für eine Zeile braucht. Zufall dass da ein fixer Wert eingetragen ist, der genau darauf abgestimmt zu sein scheint, man diesen aber vermeintlich anpassen kann, während die anderen Elemente frei anpassbar (leer) sind?
Ich verstehe, dass die 10 ein naheliegender Wert ist und halte sie dennoch für einen Platzhalter. Die anderen frei anpassbaren Elemente sind nicht alle (leer) beispielsweise die Null ganz unten, welche du wahrscheinlich nicht als frei anpassbar bewerten würdest. Der Vergeleichsoperator ist allerdings leer, da es vorgesehen ist, dass man dort die passenden Blöcke reinzieht. Ich selbst habe mal am Jwinf teilgenommen und auch mit Scratch gearbeitet und weiß daher einfach, dass man diese Werte ändern kann. Wenn man sie nicht ändern könnte, würde diese explizite Markierung nicht dort sein.
Und zu guter Letzt, wofür bräuchte man die Abfrage-Bedingungen, wenn man einfach nur ein vorgefertigtes Konstrukt aufbauen sollen, das nur genau für dieses eine Muster passt?
Stelle dir vor, du müsstest in Phyton zehn mal "Hallo " + x ausgeben, wobei x die Zahlen 1 bis 10 sein soll, wäre es sinnvoller dafür manuell zehn print-Funktionen aufzurufen oder eine Schleife zu verwenden? Letzteres. Das Ziel ist es dennoch den Algorithmus für einen einzelnen Spalten Durchlauf zu erkennen. Das ganze Programm ist in der Tat kein Algorithmus und schafft es nur dieses spezifische Muster zu lösen, trotzdem ist ein Algorithmus in ihm enthalten.
Der Punkt bei der Sache ist, dass man eben KEINE Funktion/Methode hat, die man einfach in jedem Feld aufrufen kann und einem zurückgibt, ob das Feld markiert ist oder nicht. Ich habe wie gesagt schon Erfahrung mit den Aufgaben im Jwinf. Und auch im Blockbaukasten kannst du ja sehen, dass dar überhaupt nix auf das Vorhanden sein einer solchen Funktion/Methode hinweist.
Zudem gäbe es dann keinen Grund dafür die Felder genauso zu verteilen. Wieso sollten diese Felder nicht zufällig markieren. Möchte man die Teilnehmer auf die falsche Fährte locken? Nein, das ist eben nicht der Fall.
Übrigens im Jwinf gibt es zum Teil auch Aufgaben, die etwas allgemein gültiger sein sollen. Explizit in diesen Fällen, muss der Code auch auf anderen angegebenen Karten funktionieren. Hier ist das aber eben nicht der Fall, sonst hätten wir wie gesagt mehrere Karten. Darüberhinaus unterscheiden sich diese Karten dann auch noch in ihrer Größe, was noch die Position der "10" als festgelegten Wert schwächt.
Wäre es nicht wesentlich sinnvoller, auch vom Lernfaktor her, wenn man eine allgemein gültige Lösung kreiert, die jede beliebige Anordnung von markierten Feldern passend einfärbt?
Ja, es wäre vom Lernfaktor sinnvoll, hier einen Algorithmus zu fordern. Es ist sinnvoll eine zweidimensionale Datenstruktur vollständig zu durchlaufen, da dass auch ein Problem ist, dass man in der Informatik wiederfindet. Doch wie erwähnt, würde das hier gefordert werden, hätte man tatsächlich eine beliebige Anordnung gewählt.
An der Stelle nochmals der Vergleich zum Känguruwettbewerb: der jwinf ist schlicht weg nicht vergleichbar mit einer Klassenarbeit im Fach Informatik, genauso wie beim Känguruwettbewerb. Stattdessen steht ganz besonders das logisch-analytische Denken im Vordergrund. So wird im Känguruwettbewerb nicht danach gefragt, wie man die Nullstellen einer linearen Funktion bestimmt, sondern der Schüler gefördert neue Lösungsansätze zu finden, die bis dahin noch nicht gelehrt wurden. Ebenso ist es auch im jwinf, daher ist für mich naheliegend, dass deine Idee die Aufgabe nicht reicht, um die Aufgabe zu lösen.
Zu guter letzt zählt beim jwinf alles, was funktioniert als richtige Lösung. Und da meine Herangehensweise funktioniert, @iQa1x hat es in seiner Antwort nochmal direkter auf den Punkt gebracht, und deinerseits nur eine Lösung genannt wurde, bei der noch näher bestimmt werden muss woher der Roboter denn weiß welches Feld bemalt werden muss, bin ich weiterhin anderer Meinung. Es sei denn du schaffst, mit den auf den Bild zu sehenen Blöcken eine Lösung zu erstellen.
LG
Tut mir Leid, dass mit dem runter habe ich nicht ganz verstanden und sehe es jetzt erst. Du hast damit recht, dass ich nicht so durchlaufen kann. Stattdessen muss ich die Reihen durchlaufen. Wobei ich immer noch der Ansicht bin, dass man die Zeile am besten wieder nach links zurückläuft. Ansonsten würdest du ja auch Probleme mit den zehn durchläufen kriegen ;).
Stelle dir vor, du müsstest in Phyton zehn mal "Hallo " + x ausgeben, wobei x die Zahlen 1 bis 10 sein soll, wäre es sinnvoller dafür manuell zehn print-Funktionen aufzurufen oder eine Schleife zu verwenden? Letzteres.
Natürlich letzteres, aber wofür die Abfrage-Bedingung aka if (in dem Fall "falls ...")? Du brauchst sie doch schlichtweg nicht, von du vorher genau weißt, wie das Konstrukt aussieht und wo du die Felder auffüllen musst!!
Hmm, ich hatte doch geschrieben:
- Wiederhole 10 mal: > Falls Feld markiert, färbe Feld. -> Gehe nach rechts
- Falls Reihe > 1, Gehe nach oben
- Wiederhole 10 mal: > Falls Feld markiert, färbe Feld. -> Gehe nach links
- Falls Reihe > 1, Gehe nach oben
Und das Schema führst du so lange fort, bist du bei Reihe 1, Spalte 11 angekommen bist.
---------
Du fängst also unten links an, rennst die Reihe nach rechts durch, gehst einen nach oben, rennst die Reihe nach links durch, gehst einen nach oben und fängst die gleiche Schleife von vorne an ... 😉
Der Roboter weiß ja aber nicht, wo eine Markierung ist und mit der Abfrage, stellt man indirekt fest, ob die Koordinaten mit dem eines zu markierenden Feld übereinstimmen. Man könnte auch tatsächlich alle Felderkoordinaten als einzelne Bedingungen für das anmalen in den Code schreiben, bloß ist es effizienter zu sagen, dass es sich um alle Felder zwischen der 1. und 11. Reihe sowie der 0. und 10. Spalte handelt, die nicht in Spalte 5-7 sind und deren Reihenkoordinate größer als ihre Spaltenkoordinate handelt. Ansonsten müsste man die Schleife manuell umwandeln, weil die markierten Felder pro Reihe variabel, also nicht konstant, sind. Man kann halt, sobald man mit der Schleife arbeitet, nicht mehr Schritt für Schritt entscheiden, ob ein Feld markiert ist oder nicht, sondern muss für diese Entscheidung, eine automatische Lösung finden.
Der Roboter weiß ja aber nicht, wo eine Markierung ist und mit der Abfrage, stellt man indirekt fest, ob die Koordinaten mit dem eines zu markierenden Feld übereinstimmen.
Wie gesagt, wenn du weißt wo die Koordinaten sind, brauchst du keine Abfrage mehr ob der Roboter im richtigen Feld ist. Du würdest das Script so zusammenschustern, dass er einfach einen vorgefertigten Pfad läuft. Du weißt ja zu jeder Zeit wo der Roboter ist, wenn du den Weg exakt vorgibst.
Ich vermute eher, die Abfrage-Bedingung ist dafür da zu hinterfragen, ob das Feld markiert ist.
Und bevor ich keine Musterlösung sehe, die mir etwas anderes suggeriert, wird sich meine Meinung diesbezüglich auch nicht ändern. Die Gründe dafür habe ich detailliert erklärt. Es macht anders schlichtweg keinen Sinn meiner Meinung nach!
Es gibt kein runter ...