Erste Schritte while-Schleife

[auroNpls]

Hallo Leute,

ich hätte eine Frage zu while-Schleifen. Ich möchte in diesem Fall eine Zahl (eingegeben vom Benutzer) unter der Variablen "n" speichern. Diese Zahl muss ohne Rest durch 3 und durch 4 teilbar sein und positiv sein. Ich habe das wie folgt gelöst:

while(((n % 4) & (n % 3) )!= 0 ) {
        n = IOTools.readInteger("Bitte geben Sie eine Zahl ein: ");
        if (n < 0) {
            n = IOTools.readInteger("Bitte geben Sie eine Zahl ein: ");
        } else
            break;
    }

Wenn ich nun z.B. "5" eingebe, bricht die Schleife ab.

Könnte mir jemand den richtigen Denkanstoß geben?
Vielen Dank!

Liebe Grüße

 

[Tarrew]

Für sowas eigenen sich do-while Schleifen:

        int n;
        do {
            n = IOTools.readInteger("Bitte geben Sie eine Zahl ein: ");
        } while (n < 0 || !(n % 4 == 0 && n % 3 == 0));

 

[Lucaaa]

Könnte mir jemand den richtigen Denkanstoß geben?

Du möchtest einfach nur Prüfen ob die Zahl durch 3 und 4 teilbar, und > 0 ist? Wenn ich das richtig verstanden habe, könntest du das folgendermaßen machen:

public static void main(String[] args) {
  System.out.println("Du hast eine "+ leseZahl() + " eingegeben!");
 }
 public static int leseZahl() {
  int n;
  Scanner scan = new Scanner(System.in);
 
  System.out.println("Gib eine Zahl ein!");
  n = scan.nextInt();
  scan.close();
 
  if(n%3==0 && n%4==0 &n>0) {
   return n;
  } else {
   leseZahl();
  }
 
  return 0;
 
 }

Aber wieso bricht deine Schleife ab?
Nun du tust folgendes:

solange(n%3 und n%4 nicht 0 ist)

So. An der Stelle fängt das Problem an. Du nutzt ein einfaches &.
bitweises "und", wenn beide Operanden 1 sind, wird ebenfalls eine 1 produziert, ansonsten eine 0
was du brauchst ist ein &&:
Und, true, genau dann wenn beide Argumente true sind

Das ganze müsste also so aussehen:

solange(n%3 !=0 && n%4!=0)

soweit erstmal...

 

[looparda]

So. An der Stelle fängt das Problem an. Du nutzt ein einfaches &.
bitweises "und", wenn beide Operanden 1 sind, wird ebenfalls eine 1 produziert, ansonsten eine 0
was du brauchst ist ein &&:
Und, true, genau dann wenn beide Argumente true sind

Was? So wie ich es kenne unterscheidet sich & und && nur darin, dass ersteres alle Bedingungen prüft und && abbricht, sobald eine Bedingung bereits false ist. Da die Bedingungen hier keine Nebeneffekte haben gehe ich stark davon aus, dass sowohl & und && das gleiche Ergebnis liefern werden bzw. beide keine Nebeneffekte haben.

 

[Wurstkopp]

Was? So wie ich es kenne unterscheidet sich & und && nur darin, dass ersteres alle Bedingungen prüft und && abbricht, sobald eine Bedingung bereits false ist. Da die Bedingungen hier keine Nebeneffekte haben gehe ich stark davon aus, dass sowohl & und && das gleiche Ergebnis liefern werden bzw. beide keine Nebeneffekte haben.

Korrekt. Nennt sich Short-circuit evaluation und macht in diesem Beispiel keinen Unterschied. https://de.wikipedia.org/wiki/Kurzschlussauswertung

Das Problem in der Ursprungsabfrage ist, dass 2 Zahlen per & verknüpft werden und nicht wie hier benötigt 2 boolsche Ausdrücke.

 

[Xyz1]

Diese Zahl muss ohne Rest durch 3 und durch 4 teilbar sein und positiv sein. Ich habe das wie folgt gelöst

Suchst du vielleicht das hier:

    int n;
    do {
        n = new Scanner(System.in).nextInt();
        if ((n % 3 | n % 4) + 1 == Integer.signum(n)) {
            System.out.println("ja");
        } else {
            System.out.println("nein");
        }
    } while (n != 123);

Hat etwas gedauert bis mir das einfiel

 

[auroNpls]

Für sowas eigenen sich do-while Schleifen:

        int n;
        do {
            n = IOTools.readInteger("Bitte geben Sie eine Zahl ein: ");
        } while (n < 0 || !(n % 4 == 0 && n % 3 == 0));

Wieso kann ich hier nicht anstelle von

while (n < 0 || !(n % 4 == 0 && n % 3 == 0));

while (n < 0 || (n % 4 != 0 && n % 3!= 0));

verwenden?

Wenn ich für letzteres die Zahl "4" eingebe, bricht die schleife erneut ab.

 

[Xyz1]

n < 0

vor allem ist < 0 auch falsch, wenn explizit nach

und positiv sein.

gefragt ist....

Aber ich wette hier liegt wieder mal ein klarerer Fall von meine Beiträge nicht lesen vor

 

[Meniskusschaden]

Du möchtest einfach nur Prüfen ob die Zahl durch 3 und 4 teilbar, und > 0 ist? Wenn ich das richtig verstanden habe, könntest du das folgendermaßen machen:

public static void main(String[] args) {
  System.out.println("Du hast eine "+ leseZahl() + " eingegeben!");
}
public static int leseZahl() {
  int n;
  Scanner scan = new Scanner(System.in);
  System.out.println("Gib eine Zahl ein!");
  n = scan.nextInt();
  scan.close();
  if(n%3==0 && n%4==0 &n>0) {
   return n;
  } else {
   leseZahl();
  }
  return 0;
}

Das Programm enthält noch Fehler. Erstens schließt du den Scanner, welcher dann auch System.in schliesst, obwohl es für den neuen Scanner im rekursiven Aufruf von leseZahl() im Falle einer Fehleingabe noch gebraucht wird. Zweitens reichst du das Ergebnis des rekursiven Aufrufes nicht zurück, so dass nach eine Fehleingabe und einer korrekten Eingabe immer 0 heraus kommt.

 

[Meniskusschaden]

Wenn ich für letzteres die Zahl "4" eingebe, bricht die schleife erneut ab

Weil 4 % 4 == 0 ist. Also ist der Teilausdruck 4 % 4 != 0 falsch und somit auch die gesamte UND-Verknüpfung.

 

[Xyz1]

Sag mal kapierst Du das nicht? Die Schleife muss heißen

        while ((n % 3 | n % 4) + 1 != Integer.signum(n)) {
           
        }

damit sie nur verlassen werden wird, wenn n durch 3 und 4 teilbar ist und positiv....

positiv bedeutet (nebenbei) nicht nicht-negativ, DAS HEIßT 0 zählt nicht dazu und bei 0 darf die auch noch nicht verlassen werden.

Einige Grundlagen lernen

(statt des Signum würde auch zweiter Vergleich gehen )

 

[Meniskusschaden]

damit sie nur verlassen werden wird, wenn n durch 3 und 4 teilbar ist und positiv....

Und bei -2.

 

[Xyz1]

Und bei -2.

Ach Scheiße, hatte nur von -1 bis 25 getestet.

Ja dann lass Signum weg, schalte zweiten Vergleich vor und prüfe auf 0.

 

[Lucaaa]

Nun aber:

import java.util.Scanner;
public class ZahleingabeFuerJavaForum {
 
 
 public static void main(String[] args) {
 
  System.out.println("Du hast eine "+ leseZahl() + " eingegeben!");
 }
 
 
 
 public static int leseZahl() {
  
  int n;
  
  do {
   Scanner scan =new Scanner(System.in);
   
   System.out.println("Gib eine Zahl ein!");
   n = scan.nextInt();
   
   
   
  } while (!(n%3==0 && n%4==0 && n>0 ));
  
  return n;
 }
}

 

[Xyz1]

Nun aber:

Nein,

while (n<1 || (n % 3 | n % 4) != 0) {
        }

 

[Meniskusschaden]

Nun aber:

Nein,

Wieso "Nein"? Das ist doch richtig und auch gut lesbar.

 

[Xyz1]

Wieso "Nein"? Das ist doch richtig und auch gut lesbar.

Mache doch mal einen Benchmark....

 

[Meniskusschaden]

Mache doch mal einen Benchmark....

Ist hier völlig irrelevant. Dafür ist sein Code der Aufgabenstellung angemessen und deiner nicht. Bei dir würde ich zwei Punkte abziehen. Einen für die suboptimale Wahl des Schleifentyps und einen für die Einführung des unpassenden Abstraktionsniveaus. Warum soll man sich mit internen Bit-Repräsentationen befassen, wenn man die Bedingungen direkt auf dem Level der Aufgabenstellung formulieren kann?
Für die Benchmark-Begründung würde ich einen dritten Punkt abziehen, weil durch den Versuch solcher Mikrooptimierungen an der Stelle überhaupt kein Nutzen entsteht.

 

[Xyz1]

Ist hier völlig irrelevant. Dafür ist sein Code der Aufgabenstellung angemessen und deiner nicht. Bei dir würde ich zwei Punkte abziehen. Einen für die suboptimale Wahl des Schleifentyps und einen für die Einführung des unpassenden Abstraktionsniveaus. Warum soll man sich mit internen Bit-Repräsentationen befassen, wenn man die Bedingungen direkt auf dem Level der Aufgabenstellung formulieren kann?
Für die Benchmark-Begründung würde ich einen dritten Punkt abziehen, weil durch den Versuch solcher Mikrooptimierungen an der Stelle überhaupt kein Nutzen entsteht.

Das ist reiner Blödsinn. Von @auroNpls wurde nach solch einem Schleifentyp und solch einer Schleifenformulierung gefragt....
Sie ist besser, schneller und besser lesbar für jeden der ein bisschen Boolesche Ausdrücke versteht.

Aber drei Punkte kannst Du Dir sonstwo....

Zugutehalten kann man Dir nur dass Du mich bei der ursprünglichen Formulierung auf einen Fehler aufmerksam gemacht hast

 

[Lucaaa]

Nein,

Doch!
Die Schleife wird erneut ausgeführt, wenn n NICHT positiv, NICHT %3 oder %4 0 ergibt.
Bei gültigen Zahlen wie bspw. 12 oder 24 wird n zurückgegeben und ausgegeben

 

[Meniskusschaden]

Das ist reiner Blödsinn. Von @auroNpls wurde nach solch einem Schleifentyp und solch einer Schleifenformulierung gefragt....

An der Stelle ging es um die Begründung, warum der von dir verschmähte Lösungsvorschlag von @Lucaaa deinem vorzuziehen ist.

Sie ist besser

Hinsichtlich welcher Kriterien?

schneller

Das ist hier das unwesentlichste Qualitätsziel. Leider fokussiert du ausgerechnet darauf. Für diese Fehlbeurteilung der bereits erwähnte dritte Punktabzug.

und besser lesbar für jeden der ein bisschen Boolesche Ausdrücke versteht

Das ist ja gerade die Kritik, dass man eben nicht nur - wie in beiden Lösungen - etwas von Booleschen Ausdrücken verstehen muss, sondern zusätzlich etwas von Bit-Operationen und der internen Darstellung von integer-Werten. Das ist ein ganz anderes Abstraktionsniveau und gehört deshalb nicht auf diese Ebene. Allerdings wurde dieses Defizit tatsächlich nicht von dir eingeführt, sondern bereits von @auroNpls. Das hatte ich inzwischen vergessen.

Ich habe übrigens auch gar nicht so viel dagegen, es so zu lösen, sondern richte mich in erster Linie gegen dein "Nein" zur Lösung von @Lucaaa .

 

[Lucaaa]

Mache doch mal einen Benchmark....

Die Kriterien von @auroNpls lauteten:

Zahl muss ohne Rest durch 3 und durch 4 teilbar sein und positiv sein

Ich habe hier eine funktionierende Lösung präsentiert! Ich gehe mal davon aus, dass @auroNpls
noch relativ neu hier ist (Bezogen auf java, oder generell Programmierung). Er möge mich korrigieren falls ich falsch liege.
--> Er sucht nach einer Lösung, nicht nach der schnellsten etc.
.

 

[mihe7]

Vielleicht bin ich etwas benebelt, ansonsten würde sich sagen:
"muss ohne Rest durch 3 und durch 4 teilbar sein und positiv sein" => "muss ohne Rest durch 12 teilbar und positiv sein" =>

do {
} while (n % 12 != 0 || n < 1);

 

[Xyz1]

Ja oder so

@Lucaaa Wenn da steht, zeige für alle positiven Zahlen, dass, dann musst du bei 1 anfangen nicht bei 0.... Manchmal wird das erwähnt manchmal nich

Die Römer taten sich glaube ich auch schwer mit der 0

@mihe7 Bei einer Gleichverteilung der Eingangszahlen wäre es dann aber nicht schneller n < 1 nach vorne zu ziehen....

@Meniskusschaden Das mit den Punkten kannst Du weglassen, ich habe mich ja nicht zu einer Prüfung bei Dir registriert

BEARBEITUNG: Dann ist auch wieder das mit dem Signum möglich

 

[mihe7]

Bei einer Gleichverteilung der Eingangszahlen wäre es dann aber nicht schneller n < 1 nach vorne zu ziehen....

Selbstverständlich habe ich das Ergebnis tiefenpsychologischer Beobachtungen berücksichtigt: wer gibt schon gerne negative Zahlen ein?

OK, ernsthaft: den Nicht-Positiv-Fall habe ich nur der Vollständigkeit halber erwähnt. Im Kern ging es mir natürlich um die Verkürzung auf n % 12.

 

[Meniskusschaden]

@Lucaaa Wenn da steht, zeige für alle positiven Zahlen, dass, dann musst du bei 1 anfangen nicht bei 0....

Hat er doch gemacht. 1 ist nämlich neuerdings die kleinste Ganzzahl auf die n>0 zutrifft.

@Meniskusschaden Das mit den Punkten kannst Du weglassen, ich habe mich ja nicht zu einer Prüfung bei Dir registriert

Deswegen habe ich den Konjunktiv benutzt. Aber man wird sowieso ständig von irgend jemandem beurteilt. Auch wenn man nicht darum gebeten hat.

 

[Tarrew]

Nein,

while (n<1 || (n % 3 | n % 4) != 0) {
        }

Mache doch mal einen Benchmark....

Weil mir dein Gelaber mal wieder auf die Nerven gegangen ist, habe ich mal einen Benchmark gemacht:

Spoiler

public class Test {

    private static final int MAX = Integer.MAX_VALUE / 2;

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder().forks(2).warmupIterations(5).mode(Mode.AverageTime).build();
        new Runner(opt).run();
    }

    @Benchmark
    public static int lucaa(){
        int result = 0;

        for(int i=0; i<MAX; i++) {
            if (!(i % 3 == 0 && i % 4 == 0 && i > 0)) result+= i;
        }
        return result;
    }

    @Benchmark
    public static int derWissende(){
        int result = 0;

        for(int i=0; i<MAX; i++) {
            if(i<1 || (i % 3 | i % 4) != 0)result += i;
        }

        return result;
    }
}

Ergebnis:

Und damit du jetzt nicht mit Branch-Prediction oder sowas ankommst, das Ganze nochmal mit zufälligen Zahlen:

Spoiler

public class Test {

    private static final int[] RANDOM_NUMBERS = new Random().ints(Integer.MAX_VALUE / 4, -1000000, 1000000).toArray();

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder().forks(2).warmupIterations(5).mode(Mode.AverageTime).build();
        new Runner(opt).run();
    }

    @Benchmark
    public static int lucaa() {
        int result = 0;

        for (int i : RANDOM_NUMBERS) {
            if (!(i % 3 == 0 && i % 4 == 0 && i > 0)) result += i;
        }
        return result;
    }

    @Benchmark
    public static int derWissende() {
        int result = 0;

        for (int i : RANDOM_NUMBERS) {
            if (i < 1 || (i % 3 | i % 4) != 0) result += i;
        }

        return result;
    }
}

Ergebnis:

Bitte hör in Zukunft einfach auf so viel Müll zu labern und mach das nächste Mal lieber selbst nen Benchmark, wenn du schon mit so einem Argument kommst. Du machst dich hier regelmäßig lächerlich.

Insgesamt macht es bei dieser pissiligen Operation natürlich überhaupt keinen Sinn irgendetwas optimieren zu wollen. Aber du toppst echt alles. Kommst erst mit ner falschen Lösungen um die Ecke, machst dann andere Lösungen runter, die angeblich langsamer sind und hast am Ende selbst die langsamste Lösung.

 

[Xyz1]

@Tarrew
rofl Wenn man unfähig ist einen Benchmark durchzuführen sollte man es lassen
Oder ich formulier's mal anders: Endlich kann die Blockierliste mal eingesetzt werden....

Oder auch nochmal anders: Selber es falsch machen aber anderen Fehlern vorwerfen das ist eine edle Tugend

 

[Tarrew]

@Tarrew
rofl Wenn man unfähig ist einen Benchmark durchzuführen sollte man es lassen
Oder ich formulier's mal anders: Endlich kann die Blockierliste mal eingesetzt werden....

Oder auch nochmal anders: Selber es falsch machen aber anderen Fehlern vorwerfen das ist eine edle Tugend

Dann kläre uns doch bitte auf, warum der Benchmark deine Version langsamer "erscheinen" lässt und das in echt nicht so ist Oder haste keine Argumente?

 

[Xyz1]

Mh, dafür müsste ich Dir unterstellen while-Schleifen zu verstehen.... das mache ich aber nich.

 

[Tarrew]

Ich kann das Ganze gerne nochmal mit einer while-Schleife wiederholen, ich könnte wetten, dass der Byte-Code fast identisch ist und sich auch die Messwerte nicht ändern werden. Willste die Wette eingehen?

 

[Meniskusschaden]

Dann kläre uns doch bitte auf, warum der Benchmark deine Version langsamer "erscheinen" lässt und das in echt nicht so ist Oder haste keine Argumente?

Das ist doch immer wieder das Schöne an den Diskussionen mit @DerWissende. Sobald er den Versuch startet, begründete Argumente mit unbegründeten Gegenteilsbehauptungen zu widerlegen, weiß man, dass man richtig liegt. Das ist ein ziemlich zuverlässiger Indikator

 

[Xyz1]

Ich bin nicht verpflichtet irgendwas falsches zu widerlegen, beispielsweise so etwas

} while (n < 0 || !(n % 4 == 0 && n % 3 == 0));

Schönen Abend noch

 

[Tarrew]

Du musst es echt schwer im Leben haben, wenn du dir nie eingestehen kannst, dass du nicht Recht hattest

Arbeitest du im echten Leben nicht mit Leuten zusammen? Mit deiner Einstellung kann das eigentlich nicht gut gehen.

 

[Xyz1]

Hat @Tarrew oder ich mit den Beleidigungen angefangen????

Und nur um das mal klarzustellen, das machste einmal dann fliegst du - verstehst du?

Dort draußen gibt es kein Kuscheln wie in der Uni.

 

[Javinner]

Wäre es schön, wenn @DerWissende seine Idee zu einem Benchmark hier als Code veröffentlicht hätte, alleine der Vielfalt der Lösungswege zuliebe. Dann noch eine fachliche Diskussion mit einigen Sichtweisen und eventuell Erklärungen warum und weshalb.. Ehrlich, das Gezanke geht mir ziemlich auf den Geist, weil es dem Thread sicher nicht zugute kommt und das Niveau des Forums, welches ich als sehr hoch halte, doch schon runter zieht.
Das sieht nicht gut aus, Freunde!

 

[Tarrew]

Das Problem bei solchen Diskussionen ist immer, dass @DerWissende sich nie eingestehen kann, dass er oft nicht halb so wissend ist, wie er immer vorgibt zu sein.

Es gab hier unter anderem eine Lösung von lucaa, von der DerWissende behauptet, dass diese nicht 'richtig' sei, weil angeblich zu langsam. Man solle doch bitte einen Benchmark machen.
Ich mache einen Benchmark, und es stellt sich heraus, dass DerWissende Unrecht hat. Anstatt sich das dann einfach einzugestehen wird mir dann vorgeworfen, ich wüsste nichts über while-Schleifen, das ist schon ziemlich lächerlich.
Wer ernsthaft behauptet, eine while-Schleife performt in dem Benchmark in irgendeiner Form anders, als die for-Schleife, dem ist wirklich nicht mehr zu helfen.

Von daher warte ich immer noch auf einen Benchmark von @DerWissende, der dann zeigt, dass seine Bedingung schneller läuft, als die von lucaa. Dieser Benchmark wird aber vermutlich nie kommen, weil DerWissende mal wieder nur haltlose Behauptungen in den Raum wirft. Anstatt einen anderen Benchmark zu liefern, der zeigt, dass seine Bedingung angeblich schneller läuft wird mir nur vorgeworfen ich könnte keinen Benchmark schreiben.

Hat @Tarrew oder ich mit den Beleidigungen angefangen????

Und nur um das mal klarzustellen, das machste einmal dann fliegst du - verstehst du?

Dort draußen gibt es kein Kuscheln wie in der Uni.

Wann hab ich dich denn beleidigt? Du warst doch nur beleidigt weil du meine sachliche Argumentation nicht sachlich widerlegen konntest, sondern nur unspezifisch "du hast keine Ahnung von while-Schleifen" in den Raum gerufen hast. Dann liefer uns doch endlich einen sachlichen Gegenbeweis. Aber @Meniskusschaden hatte schon Recht mit seiner Aussage.

Und wovon fliege ich? Aus dem Forum oder was? Bist du seit neustem Moderator? Ehrlich gesagt wundert es mich viel mehr, dass du bis jetzt noch nicht geflogen bist.

Übrigens arbeite ich seit einiger Zeit bei einem der größten IT-Unternehmen in Europa, ich weiß also durchaus wie es "dort draußen" zugeht. Und dazu gehört auch, sich Fehler eingestehen zu können, um es in Zukunft besser zu machen. Ich kann mir keine Firma der Welt vorstellen, in der du mit deiner "ich hab immer Recht, aber keine Argumente dafür"-Einstellung die Probezeit überstehen würdest. Ein Teamplayer bist du ganz sicher keiner.

 

[Xyz1]

Ein Teamplayer bist du ganz sicher keiner.

Kollegen beleidigen und unkollegiales Verhalten findet niemand gut - nur hier traust Du Dich das, draußen nicht.

Aber gut das sei auch der letzte Satz von mir in diesem Thema.

Ah - ein Link sei noch gestattet : https://www.wirtschaftswissen.de/pe...rhalten-und-wie-sie-darauf-reagieren-koennen/ .

 

[Tarrew]

Kollegen beleidigen und unkollegiales Verhalten findet niemand gut - nur hier traust Du Dich das, draußen nicht.

Aber gut das sei auch der letzte Satz von mir in diesem Thema.

Ah - ein Link sei noch gestattet : https://www.wirtschaftswissen.de/pe...rhalten-und-wie-sie-darauf-reagieren-koennen/ .

Danke, damit hast du nun jedem gezeigt, dass du leider kein sachliches Gegenargument zu meinem Benchmark hast und du definitiv daneben lagst. Nächstes mal gestehe es dir doch bitte direkt ein anstatt mir mangelnde Programmierkenntnisse vorzuwerfen, dann kann man sich die ganze Diskussion hier ersparen.

Ich kann übrigens immer noch nicht sehen, wo ich dich beleidigt haben soll, aber gut. Der einzige, der bis jetzt beleidigend geworden ist bist du, als du mir auf Grund mangelnder Gegenargumente prinzipielle Unkenntnis vorgeworfen hast. Aber um das zu erkennen, braucht es natürlich etwas Selbstreflexion.

Und nochmal zu deinem Link:

3. Unkollegiales Verhalten: Feedback wegzuwischen

Das trifft auf dich zu. Mein Feedback hast du einfach weggewischt und als Schwachsinn abgetan, anstatt mal sachliche Gegenargumente zu liefern.

Und ebenso trifft auf dich zu:

4. Unkollegiales Verhalten: unterbrechen und andere Meinungen nicht ernst nehmen

Geh nochmal ein paar Seiten zurück und guck dir an, wie du die richtigen Lösungen anderer Forenmitglieder hier nicht ernst genommen hast und als "falsch" tituliert hast, obwohl diese durchaus richtig waren.

Das ausgerechnet du mit so einem Link ankommst ist schon etwas befremdlich. Erkennst du dich selbst in den Punkten garnicht wieder?

Ich hab ja mehrfach versucht beim Thema zu bleiben, aber da du keine Argumente zu haben scheinst, wirst du einfach persönlich und schreibst hier irgendwelche unspezifischen Sachen. Es ist ja nicht das erste Mal, dass hier mehrere Leute ein Problem mit deiner Diskussionsweise haben, das sollte dir doch mal zu denken geben. Denk mal drüber nach