Mit break aus for(..;..;..) raus?
-
Hallo,
ein Online-Fremdwörterbuch ( http://services.langenscheidt.de/fremdwb/fremdwb.html ) sagt dazu:
va·li'die·ren 1. RECHT etwas für rechtsgültig erklären 2. die Gültigkeit eines wissenschaftlichen Ergebnisses überprüfen
MfG
Edit: übrigens:
ma·the'ma·tisch die → Mathematik betreffend, auf ihr beruhend, zu ihr gehörend, mit ihrer Hilfe
Ma·the·ma'tik, die; -, keine Mehrzahl 1.Wissenschaft von den Zahlen- und Raumgrößen 2.(1) als Lehrfach
-
Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

edit: Wenn ihr der Meinung seid, die Definition sei damit ausreichend klar, dann könntet ihr ja mal zu meiner zweiten Frage kommen.
-
hm...dachte mir eh schon dass es hier ziemlich gespaltene meinungen gibt...
ich werd nach wie vor boolflags so gestalten dass möglichst alle abbruchbedingungen im schleifenkopf stehen...
und ggf. werd ich wohl auch mal break verwenden wenn ich damit die (meist) großen if-ummantelungen umgehen kann!!
danke jedenfalls mal für die vielen antworten!

-
Ich versuchs mal. Jede Schleife hat eine Vorbedingung und eine Nachbedingung. Desweitere hat jede Schleife ein Invariante. Die Invariante muss entweder zu jedem Zeitpunkt gueltig sein oder zumindest zu bestimmten Zeitpunkten (totale und partielle Korrektheit). Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.
EDIT: Argh! Quetscht sich da einer dazwischen!
-
Jester schrieb:
Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

Falls Du mich meintest: Habe ich irgendwo behauptet mit meinem Post Deine Definitionsfrage zu beantworten? ... Also nörgel nicht rum.
Aber wenn man nicht zum allgemeinen Begriffsverständnis beitragen soll, kann ich das in Zukunft auch lassen! *BockigInDerEckeSteh*
-
Apollon schrieb:
Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.
Ja, das könnte sein. Allerdings ist dann entweder das Programm oder die Nachbedingung (oder beides) falsch. Ist das Programm korrekt, so sehe ich kein Problem darin, die Nachbedingung so abzuändern, dass sie das Programm auch korrekt beschreibt. Programme, die nicht zu einer gegebenen Spezifikation passen lassen sich schließlich auch ohne break schreiben.
-
Kolumbus schrieb:
Jester schrieb:
Es ist schier unglaublich, was manche hier unter einer Definition verstehen...

Falls Du mich meintest: Habe ich irgendwo behauptet mit meinem Post Deine Definitionsfrage zu beantworten? ... Also nörgel nicht rum.
Oh, entschuldige. Ich werde in Zukunft davon ausgehen, dass Du einfach so zusammenhangslos irgendwelche Sachen in Threads reinkopierst.
Aber wenn man nicht zum allgemeinen Begriffsverständnis beitragen soll, kann ich das in Zukunft auch lassen! *BockigInDerEckeSteh*
Was hilft das denn bitte für's Verständnis? Das hilft ungefähr so viel wie "Was ist ein Vektorraum?" -- "Ein Raum mit/von/aus Vektoren!".
-
Jester schrieb:
Apollon schrieb:
Was ich mir jetzt vorstellen kann ist, dass ein break die Schleife zu einem Zeitpunkt verlaesst, an dem die Invariante nicht gilt und somit eine laut Vorbedingung gueltige Eingabe nicht derart verarbeitet, dass die Nachbedingung gilt.
Ja, das könnte sein. Allerdings ist dann entweder das Programm oder die Nachbedingung (oder beides) falsch. Ist das Programm korrekt, so sehe ich kein Problem darin, die Nachbedingung so abzuändern, dass sie das Programm auch korrekt beschreibt. Programme, die nicht zu einer gegebenen Spezifikation passen lassen sich schließlich auch ohne break schreiben.
Nicht, dass wir uns an dieser Stelle falsch verstehen. Ich bin kein Gegner von break und von dem Verifikationsproblem im Zusammenhang mit break hoere ich hier zum ersten Mal. Ich vertrete nur die Meinung, dass es immer ohne geht. Durch diesen Thread faellt mir nur auf, dass ich break sehr selten benutze ohne dabei den Code bewusst so zu gestalten, dass break unnoetig ist.
Ich bin jetzt auch nicht in der Lage, ein nichttriviales Beispiel zu geben, weil Invariantenbestimmung keine einfache Sache ist. Ueberhaupt gehe ich davon aus, dass irgendwannmal irgendjemand einen Fall gefunden hat, wo break tatsaechlich dazu fuehrte, dass die Schleife nich verifizierbar war. Er wurde dann in einem Paper publiziert und seit dem glaubt man das einfach.

-
Apollon schrieb:
Ueberhaupt gehe ich davon aus, dass irgendwannmal irgendjemand einen Fall gefunden hat, wo break tatsaechlich dazu fuehrte, dass die Schleife nich verifizierbar war. Er wurde dann in einem Paper publiziert und seit dem glaubt man das einfach.

Daran glaube ich eher nicht. Ich sehe keinen Grund, warum man die Nachbedingung nicht auch so formulieren können sollte, dass sie auch im break-Fall korrekt ist.
Ob man break nun verwendet oder nicht ist mir eigentlich ebenfalls herzlich egal.
Nur wenn es tatsächlich handfeste Gründe gibt es nicht zu tun, dann würde ich das gerne wissen. Deswegen frage ich hier nach.
-
Vielleicht solle mal jemand eine Schleife posten, die ohne "break" nicht auskommt. Deshalb denke ich mir mal schnell eine aus :
#include <stdlib.h> #include <stdio.h> int main () { randomize (); int i; for ( i = 0; i < 100; i++ ) { if ( (rand () % 100) > 90 ) break; printf("%d ", i); } return 0; }Wie kann man jetzt prüfen, ob die For-Schleife von i = 0 bis i = 99 korrekt arbeitet ?
P.S.: Auskommentieren gilt nicht !

-
merker schrieb:
Wie kann man jetzt prüfen, ob die For-Schleife von i = 0 bis i = 99 korrekt arbeitet ?
indem man die werte kennt, die von rand() kommen. das sind ja immer dieselben

-
merker schrieb:
Vielleicht solle mal jemand eine Schleife posten, die ohne "break" nicht auskommt.
So eine Schleife gibt es nicht.
-
merker schrieb:
Vielleicht solle mal jemand eine Schleife posten, die ohne "break" nicht auskommt. Deshalb denke ich mir mal schnell eine aus :
Ich habe sie mal ein wenig modifiziert.
#include <stdlib.h> #include <stdio.h> int main () { randomize (); int i; for ( i = 0; i < 100 && rand() % 100 > 90; i++ ) { printf("%d ", i); } return 0; }Wie finix bereits sagte, solch eine Schleife existiert nicht.
-
Ähem, vielen Dank für die Antworten.

Ich wollte mit meiner Schleife nur folgendes klarmachen :
Schleifen mit mehr als einer Laufbedingung sind nicht validierbar !
Deshalb erübrigt sich die Frage, ob man eine Schleife mit "break" verlassen darf oder ob man besser den "Schleifenkörper :-)" umformuliert.
-
merker schrieb:
Schleifen mit mehr als einer Laufbedingung sind nicht validierbar !
und warum nicht?
-
Weil die Laufbedingungen voneinander unabhängig sind obwohl sie zusammen eine Schleife (Einheit, Kontrollstruktur) bilden.
Würde man zu "Testzwecken" eine oder mehrere Laufbedingungen auskommentieren, würde man "irgendwas" aber nicht die Schleife testen.
-
EDIT: Hat Apollon schon gemacht.
-
ich hab jetzt die ersten paar seiten gelesen und da hat keiner geschrieben, dass man dieschleife in ne funktion paken und dann return machen kann, darum schreibich es jetzt mal.
-
merker schrieb:
Weil die Laufbedingungen voneinander unabhängig sind obwohl sie zusammen eine Schleife (Einheit, Kontrollstruktur) bilden.
aber ist das nicht egal?
wenn beide bedingungen vorhersehbar sind, kann man doch ganz genau bestimmen, wie sich die schleife verhalten wird.
es sei denn die eine bedingung ist echt zufällig, aber an 'rand()', wie in dem beispiel, ist ja nun wirklich gar nichts zufällig...

-
also schrieb:
ich hab jetzt die ersten paar seiten gelesen und da hat keiner geschrieben, dass man dieschleife in ne funktion paken und dann return machen kann, darum schreibich es jetzt mal.
Hättest mal bis zur 4. lesen sollen:
pale dog schrieb:
Jester schrieb:
Simon2 schrieb:
while(irgendeine Bedingung && !(erste Operation erfolgreich)) zweite OperationWieso nicht ?
Mach bitte aus erste Operation was zwei- oder dreizeiliges.

bool erste_operation_erfolgreich() { ... }4 zeilen

:p

Gruß,
Simon2.