Schleifeninvariante....

Orbit

Erfahrenes Mitglied
Hallo.
Folgender Code:
Code:
public class Faden {
	public static long teilungen(int n){
		if(n<=0)return 0;
		if(n==1)return 1;
		if(n==2)return 2;
		int i=3;
		long a = 2;
		long b=1;
		while(i<=n){
			long next = a+b;
			i++;
			b=a;
			a=next;
		}
		return a;
	}
	public static void main(String[] atgs){
		for(int i = 0;i<20;i++){
			System.out.println(teilungen(i));
		}
	}
}
Zu der Schleife soll eine Schlewifeninvariante gefunden werden...
ich hab einfach keine idee wuie ich da dran gehen soll.
Ich will NICHT die Lösung, nur nen allgemienen Ansatz, weil ich da grad einfach voll nich durchsteig..
Hoffe ihr könnt mir helfen,
Orbit

EDITUM:
Das programm soll die anzahl der möglichen teilungen eines Fadens der länge n in die Teilstücke 1 und 2 ausgeben...
 
Zuletzt bearbeitet:
Hi.

Überleg dir mal was für die Variablen a, b, i die in der Schleife verändert werden vor und nach jedem Schleifendurchlauf gilt.

Was gilt direkt nach der Initialisierung, also vor dem ersten Schleifendurchlauf? (für a und b in Bezug zu i, und für i in Bezug zu n)?

Außerdem sollte nachdem die Schleife terminiert ist aus der Invariante folgen, dass die Nachbedingung (Postcondition) wahr ist.

Gruß
 
Hi,

und es ist unschön mehr als ein return zu haben. Bessere wäre es einfach die Werte in eine Variable zu speicherung un diese dann wieder zurück zu geben
gruß

lex
 
In der Tat wird oft erzählt, mehr als ein Return sei schlecht, aber das gilt nur unter bestimmten Annahmen, die in der Theorie gemacht werden. In der Praxis kann es sich genau andersherum verhalten, nämlich dann, wenn man innerhalb von großen Methoden höhere Verschachtelungstiefen in Schleifen oder if-Anweisungen erreicht. Das ist ganz besonders unübersichtlich und schadet der Wartbarkeit. In solchen Fällen sind mehrere Returns, die sauber und ordentlich in jeweils eigenen Zeilen stehen, besser für die Architektur.

Abgesehen davon kostet die Speicherung von Rückgabewerten in Extra-Variablen viel Zeit (schreibende Speicherzugriffe sind teuer). In vielen Fällen ist es zeitlich egal, ob man einen Speicherzugriff mehr oder weniger macht, in bestimmten Schleifen jedoch beeinflusst das die Gesamtlaufzeit enorm. Solche Dinge sind nicht nebensächlich oder egal.

Außerdem muss zusätzlich dazu noch eine Menge anderer Code ausgeführt werden, zusammen mit mehreren Abfragen, die den Abbruch der Schleifen erkennen, bis endlich das Ende der Methode mit dem rettenden Return erreicht ist. Solcher Code ist sehr fehleranfällig.

An dieser Stelle zeigt sich wie so oft, dass man -- gerade in der Programmierung, wo das leider immer wieder gemacht wird -- eben nicht verallgemeinernde Parolen ausgeben kann, auch wenn Anfänger das gerne so hätten. (Die schlimmsten Sätze beginnen oft mit "Mein Informatiklehrer hat gesagt..." Es ist geradezu schockierend, was ich anschließend so zu hören bekomme.) Man muss wirklich dahintersteigen und verstehen, worum es geht, um die richtige Entscheidung treffen zu können.

-Gawayn
 

Neue Beiträge

Zurück