Programm wird frühzeitig beendet

xyt4n

Aktives Mitglied
Hallo, ich hab das oben genannte Problem.
Durch den Befehl print(bubblesort(a3)); wird mein Programm frühzeitig beendet. Aber wieso?? Irgendwie ist mein Eclipse auch auf einmal so lahm. Vlt habe ich irgendwo eine Endlosschleife gebaut...

Vielen Dank schon mal im Voraus!
Hier der Code:

Java:
public class Praesenz03 {

	public static void main(String[] args) {
		int[] a1 = { 1, 2, 4, 3 };
		int[] a2 = { 4, 2, 3, 1 };
		int[] a3 = { 1, 2, 3, 4 };
		int[] a4 = { 2, 3, 1, 4 };
		int[] b1 = { 4, 3, 2, 1 };
		int[] b2 = { 2, 3, 1, 4 };
		int[] b3 = { 4, 3, 2, 1 };
		int[] b4 = { 2, 3, 1, 4 };
		print(insertionsort(a1));
		print(insertionsort(b1));
		print(selectionsort(a2));
		print(selectionsort(b2));
		print(bubblesort(a3));
		print(bubblesort(b3));
		print(mergesort(a4));
		print(mergesort(b4));
	}

	public static int[] insertionsort(int[] a) {
		int w;
		int n = 0;
		int j;
		for (int i = 1; i < a.length; i++) {
			j = i;
			w = a[i];
			while (j > 0 && a[j - 1] > w) {
				a[j] = a[j - 1];
				j--;
				n++;
			}
			a[j] = w;
		}
		System.out.println("Anzahl der Schritte: " + n);
		return a;
	}

	public static int[] selectionsort(int[] a) {

		int k = 0;
		int n = 0;
		for (int i = 0; i < a.length - 1; i++) {
			int min = i;
			for (int j = i + 1; j < a.length; j++) {
				if (a[min] > a[j])
					min = j;
				n++;
			}
			k = a[i];
			a[i] = a[min];
			a[min] = k;
		}
		System.out.println("Anzahl der Schritte: " + n);
		return a;
	}

	public static int[] bubblesort(int[] a) {
		int h;
		int n = 0;
		boolean swapped;
		do {
			swapped = false;
			for (int i = 0; i < a.length - 1; i++) {
				if (a[i] > a[i + 1]) {
					h = a[i];
					a[i] = a[i + 1];
					a[i + 1] = h;
					n++;
					swapped = true;
				}
			}
		} while (swapped = true);

		System.out.println("Anzahl der Schritte: " + n);
		return a;
	}

	public static int[] mergesort(int[] a) {

		return a;
	}

	public static void print(int[] a) {
		for (int x : a)
			System.out.print(a[x - 1]);
		System.out.println();
	}
}
 
[JAVA=74]} while (swapped = true);[/code]

Ich sehe da etwas ganz Böses. 😀

PS: Deine Print-Funktion ist sehr fraglich. Entweder du machst das mit einer richtigen for-Schleife oder du nutzt
Code:
System.out.println(Arrays.toString(a));
.
 
[JAVA=74]} while (swapped = true);[/code]

Ich sehe da etwas ganz Böses. 😀

PS: Deine Print-Funktion ist sehr fraglich. Entweder du machst das mit einer richtigen for-Schleife oder du nutzt
Code:
System.out.println(Arrays.toString(a));
.

Den Fehler mache ich immer wieder 🙁

Wieso ist meine Print Methode fraglich?
 
Weil die ja nur funktioniert, weil die erste Zahl immer 1. ist. Ein anderes Array könntest du damit nicht ausgeben. Man stelle sich nur einmal vor, es wären negative Zahlen im Array. 😀
 
also egal ob bool = true oder bool == true ... wer auf true prüft gehört geschlagen ... genau so all die die auf false prüfen ...


hier noch mal ganz primitiv

auf true : if(bool) / while(bool)

auf false : if(!bool) / while(!bool)

wobei man eigentlich nie auf false prüfen sollte denn das benötigt immer eine operation mehr ... leiber sollte man seinen code schreiben das man nach möglichkeit nur direkt auf true , also if(bool) prüft ... denn if(!bool) und if(bool==false) sind gleich und gleich schlecht ...
 
wobei man eigentlich nie auf false prüfen sollte denn das benötigt immer eine operation mehr ...

Irgendwie finde ich diese Aussage gewagt und auch nur schwer durch Tests belegbar 😉

Aber
Code:
== true
oder
Code:
== false
könnte natürlich den Eindruck Anfänger erwecken... Aber später wird man diese längere Schreibweise ohnehin nicht mehr machen...
 
wobei man eigentlich nie auf false prüfen sollte denn das benötigt immer eine operation mehr ... leiber sollte man seinen code schreiben das man nach möglichkeit nur direkt auf true , also if(bool) prüft ... denn if(!bool) und if(bool==false) sind gleich und gleich schlecht ...

Besser natürlich so was schreiben:

Java:
if(hallo)
{
    //do nothing
}
else
{
    //do something
}

Denn, wenn man dann erst mal anfängt auf false zu prüfen, das wird die Laufzeit jedes Programms in den Keller treiben.
 
wobei man eigentlich nie auf false prüfen sollte denn das benötigt immer eine operation mehr
Die Begründung ist hier natürlich Käse, ich würde aber wirklich wen es geht den Code immer so schreiben, dass man auf positives Überprüft. Einfach weil Verneinungen einen ticken schwerer zu verstehen sind. Das geht dann aber eher über den Namen der Variablen, als über leer if-Blöcke 😉
 
Besser natürlich so was schreiben:

Java:
if(hallo)
{
    //do nothing
}
else
{
    //do something
}

Die Begründung ist hier natürlich Käse, ich würde aber wirklich wen es geht den Code immer so schreiben, dass man auf positives Überprüft. Einfach weil Verneinungen einen ticken schwerer zu verstehen sind. Das geht dann aber eher über den Namen der Variablen, als über leer if-Blöcke 😉

Also so: (?)
Java:
if(notHallo)
{
    //do something
}
Weil es einfach zu lesen ist als: (?)
Java:
if(!hallo)
{
    //do something
}
Halte ich genauso für... naja... "nicht richtig"...
 
Java:
if (unfriendly) {
...
}

Statt vor den Namen der Variable einfach ein not zu setzen würde ich versuchen, stattdessen einen Namen zu finden der im die Verneinung ohne ein not ausdrückt. Aus !true wird false und nicht notTrue. Lässt sich aber sicher nicht immer 100%ig anwenden, klar.
 
ich meinte das mit "eine OP mehr" so :

if(bool) : ist "bool" wahr
if(!bool) : ist es wahr das "bool" nicht wahr ist

zum vergleich

if(bool==true) : ist es wahr das "bool" wahr ist
if(bool==false) : ist es wahr das "bool" nicht wahr ist

die wirklich "kürzeste" OP ist nun mal direkt "if(bool)"

natürlich kommt es auch immer auf den kontext an ...
wenn man sowas wie folgt hätte

if(3<4)

im vergleich zu

if(!(3<4))

sollte der compiler eigentlich in der lage sein dem VM-cpu daraus dann sinnvollerweise die passenden JMP-befehle zu erzeugen
fürs erste also JLT und fürs zweite JGT ...

für moderne CPUs ... und ich nehme auch an für die java-VM-cpu sowie den compiler sind solche dinge schon sinnvoll machbar ... aber im source sieht es halt einfach komisch aus ...

sicher ... auch leere if-blöcke ergeben wenig sinn ... aber wie angemerkt kann es manchmal einfacher sein zu prüfen ob ein bestimmter zustand vorliegt anstatt zu prüfen ob dieser eben nicht vorliegt und danach zu entscheiden was der zustand nun ist ...

natürlich kann man sich hier wirklich drum schlagen was nun besser ist und performanter (wobei mikro-benchmarks eh für den ***** sind) ... es gehört halt auch teilweise zum persönlichen stil ... (wobei ich jetzt gar nicht weis ob es in den conventions hier für ein konkretes beispiel gibt)
 
Java:
if (unfriendly) {
...
}

Statt vor den Namen der Variable einfach ein not zu setzen würde ich versuchen, stattdessen einen Namen zu finden der im die Verneinung ohne ein not ausdrückt. Aus !true wird false und nicht notTrue. Lässt sich aber sicher nicht immer 100%ig anwenden, klar.

Aber spätestens bei
Java:
if (!untrustworthy) {
...
}
wirds dann unübersichtlich (nicht übersichtlich 😉 ). Außerdem, wie schon gesagt, lässt sich nicht jedes Adjektiv vorweg mit einem un/in/etc. verneinen.

Also es ist nicht schneller und eigentlich auch nicht besser lesbar.

Außerdem (etwas OT, nicht schlagen 😀 ) sind NAND-Gatter auch preisgünstiger und werden vorzugsweise verwendet:
Wikipedia hat gesagt.:
Dadurch, dass sich mit diesem Baustein alle anderen ersetzen lassen, wird eine Schaltung wesentlich preisgünstiger.
 
Also ich habe schon Codingvorlagen bekommen, wo man genau sowas machen musste ;-)
Java:
if(hallo){
    //do nothing
}else{
    //do something
}
 
@Cola_Colin: Kleinkariert nicht, aber dMn müsste man jetzt schon zwei Methoden schreiben, wobei die eine das Ergebnis der anderen einfach nur negiert. Das kann gar nicht sinnvoll sein
 
Zuletzt bearbeitet von einem Moderator:
Ich mache das meistens so, dass ich boolean-Variablen so benenne (passend zur Semantik), dass ihre "Standardwerte" (also die Werte, die z.B. ein existierender oder gedachter Konstruktor unabhängig von anderen Werten festlegen würde)
Code:
false
sind. Manchmal klappt das natürlich nicht, aber meistens. 😉

Und ob
Code:
if(x) {wenn();} else {sonst();}
schneller ist als ein
Code:
if(!x) {sonst();} else {wenn();}
ist hauptsächlich eine Sache des verwendeten Laufzeit-Compilers und sehr stark von der Mikroarchitektur des ausführenden Prozessors abhängig. Am Ende vom if-Block (falls ein nichtleerer else-Block existiert) steht nämlich ein unbedingter Sprung, bei der Überprüfung der Bedingung ein bedingter Sprung. Einer der beiden Sprünge muss auf jeden Fall gemacht werden (Sachen wie
Code:
return
oder
Code:
throw
mal ausgenommen). Also müsste man jetzt vergleichen, wie oft der if-Zweig und wie oft der else-Zweig genommen wird, und dies mit den Taktzyklen für einen unbedingten bzw. bedingten Sprung ins Verhältnis setzen. Da hier aber bei vielen Prozessoren noch eine Sprungvorhersage mit reinspielt, kann sich die Vertauschung von if- und else-Zweig (ergo: Invertieren der Bedingung) als kontraproduktiv erweisen. Mal davon abgesehen, können die meisten Prozessoren sowohl "falls" springen als auch "falls nicht".

Insofern ist jegliche Performanceoptimierung dahingehend mehr Spekulation als alles andere (wie gerade aufgezeigt). Eine saubere Benennung der Variablen ist sehr viel mehr wert und sehr viel wichtiger.

Ark
 

Zurück
Oben