URL: https://www.overclockers.at/coding-stuff/c_gcc_segmentation_fault_core_dump_186732/page_1 - zur Vollversion wechseln!
sers
ich bin hier gerade am C coden, unter ubuntu, und hab ein problem bei einem rekursiven Algorithmus.
ist ein algorithmus zur berechnung von schachzügen.
habe zwei versionen davon, die erste eruiert ob ein gewisser zug (man gibt koordinaten und züge an) in den angegebenen zügen möglich ist.
die variante macht keine probleme. der zweite teil der aufgabe ist es nun, das man die minimalen züge ausfindig machen soll, und im prinzip isses der selbe code, nur eine abbruchbedingung wurde ein bissl verändert.
wenn ich jetzt mit einem springer zb. von 1/1 auf 2/3 springe, geht alles noch. er sagt mirt minimal = 1. von 1/1 auf 3/5 gehts auch, minimal=2, 1/1 auf 4/7 geht auch, minimal = 3.
aber wenn ich zb 1/1 -> 7/4 springen lassen will kommt
"Segmentation fault (core dumped)"
pls help
Ganz ohne Code oder Algorithmus werden wir kaum helfen können
bool Horsejump(int x, int y, int count) {
if (x < 1 || x > MAX || y < 1 || y > MAX || (count > n && n!=0)) { return false; }
else if(x == xtarget && y == ytarget && (count < n || n == 0)) {
n=count;
return true; };
return Horsejump(x+1, y+2, count+1) || Horsejump(x-1, y+2, count+1) ||
Horsejump(x+1, y-2, count+1) || Horsejump(x-1, y-2, count+1) ||
Horsejump(x+2, y+1, count+1) || Horsejump(x-2, y+1, count+1) ||
Horsejump(x+2, y-1, count+1) || Horsejump(x-2, y-1, count+1);
}
das is der markante code.
n, xtarget und ytarget == globale vars
// sry doppelpost
/// wenn ich die core datei aufmachen mitn GDB dann sagt er mir das der error bei einem aufruf liegt, und zwar is da der count schon bei 280000. ich vermute dass das das problem ist oder? ich verstehs net wieso er soweit geht. und wieso er trotz den 280000 nicht weitermacht.
Das Programm hängt ja für immer in der Rekursion fest, falls das IF Schwachsinn liefert! (Endlosschleife)
Die Abfrage am Anfang funktioniert?
EDIT: Was passiert, wennst du das return Horsejump.... in den else-Zweig des 2. if gibst?
nein, liefert keinen schwachsinn. funktioniert ja im anderen programm auch. ich befürchte das es daran liegt das die rekursion zu tief reingeht und er das nicht dareisst. kanns daran liegen? kann ich das beheben?
Für was ist das n und count da? Habs gerade bei mir reinkopiert, jetzt brauch ich noch normale Werte. Dann kömma schauen, ob wir was zusammen bringen
also n ist der globale counter, wo mitgeschrieben wird wiviele sprünge schon getätigt worden sind, wenn der gesuchte fleck erreicht wird. count ist der counter für doe "lokale" rekursion, also es wird da mitgezählt wie oft gesprungen wird, bis (oder eben bis nicht) das ziel erreicht wird.
wird das ziel erreicht wird verglichen ob der weg bis hierher lürzer war als der vorige weg, wenn ja wird n überschieben da das ja die minimale sprungdauer angeben soll.
hoffe das hilft ein bisschen
EDIT: Bin mir nicht mehr sicher, ob das Programm so zu lösen ist! Er geht das 1. Mal in Horsejump --> Es wird 8x aufgerufen. Wenn 1 der 8 nicht passt, geht er bei dem 1 wieder 8x ins Horsejump. Wenn 8 nicht passen, geht er 8x8 ins Horsejump usw.
hehe, interessant bei mir spinnt er bei 8/7 erst..
wenn du was findest, wäre ich dir sehr dankbar
Bei Target 4/4 bekomm ich schon einen StackOverflow.
EDIT: Bei negativen Sprüngen hab ich immer einen Fehler! Egal, wie weit die Position entfernt ist!
Was hindert das Programm, ständig zwischen den selben 2 Positionen hin- und herzuspringen, solange n noch == 0 ist?
Ich hab in diesem Delphi-Forum auch so ein Springerproblem gefunden:
http://www.delphi-forum.de/viewtopi...8f16681be605fcb
Werd noch ein bisschen weiterschauen, vielleicht find ich was oder iich hab noch einen Geistesblitz
EDIT: Noch schöner: http://www.hackerboard.de/thread.ph...=18267&sid=
er springt ständig auf alle möglichkeiten, das is ihm zuviel glaub ich. verdammt, was soll ich dagegen machen.
Merk dir wo du schon warst.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025