Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (ANSI-Standard) » n-Damenproblem (Aufgabe)

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 < [ 3 ]
010
08.01.2009, 12:37 Uhr
0xdeadbeef
Gott
(Operator)


Joa, sinnigerweise finge man so was wohl in Prolog (oder Vergleichbarem) an. Das Problem schreit geradezu nach deduktiver Programmierung.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 08.01.2009 um 12:38 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
08.01.2009, 14:01 Uhr
~Justin Sayne
Gast


achso, ich dachte, das was Operatoren von sich geben, ist auf jeden Fall immer richtig
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
08.01.2009, 15:41 Uhr
virtual
Sexiest Bit alive
(Operator)



Zitat von ~Justin Sayne:
achso, ich dachte, das was Operatoren von sich geben, ist auf jeden Fall immer richtig



Das trifft natürlich zu: Operatoren haben immer recht, sonst wären sie keine Operatoren. Ansonsten gilt eben der 1. Satz von Post 009.
--
Gruß, virtual
Quote of the Month
Ich eß' nur was ein Gesicht hat (Creme 21)
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
08.01.2009, 17:23 Uhr
0xdeadbeef
Gott
(Operator)


Operatoren haben immer recht, auch wenn das, was sie von sich geben, nicht richtig ist.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
08.01.2009, 19:45 Uhr
kronos
Quotenfisch
(Operator)


Vielen Dank, liebe Mitoperatoren, für eure Rückendeckung


Zitat von ~Justin Sayne:

Zitat:
Diesen Abschnitt würde ich ignorieren, einen Schachbrett-Array zu verwenden ist hier vollkommen unsinnig. Sinnvoller ist eine Liste von Damen-Koordinaten und eine Methode, die überprüft ob zwei dieser Damen sich bedrohen.


Warum denn? Ist die Listenmethode so viel schneller?

"Vollkommen unsinnig" war so dahergetippt, ich benutze immer Superlative wenn ich's eilig hab'. Der Brett-Array macht Sinn wenn man viele Lösungen sucht. Wenn man nur eine Lösung sucht (und so hatte ich das verstanden) dürfte ein Stack vor allem für große n günstiger sein.
--
main($)??<-$<='?'>>2?main($-!!putchar(
(("$;99M?GD??(??/x0d??/a:???;a"+'?'/4)
??($??)+'?'/3-2-1+$%2)??''?')):'?';??>

Dieser Post wurde am 08.01.2009 um 19:46 Uhr von kronos editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
08.01.2009, 19:55 Uhr
0xdeadbeef
Gott
(Operator)


Stack macht Sinn, aber ich würde hier keinen Stack im Sinne des abstrakten Datentyps verwenden - es ist völlig unnötig. Ein Versuchszustand lässt sich beispielsweise wunderbar als std::vector<std::pair<int, int> > auffassen, wobei jedes pair die Position einer Dame bezeichnet. Der vector kann gleichzeitig als Stack "missbraucht" werden, wobei das letzte Element das oberste ist - jeder Zustand beinhaltet ja implizit alle vorherigen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
016
08.01.2009, 20:28 Uhr
kronos
Quotenfisch
(Operator)


Jo, ging nur um's Prinzip. Implementieren lässt sich das sogar mit 'nem einfachen Array, da die eine Koordinate ja der Index ist.
--
main($)??<-$<='?'>>2?main($-!!putchar(
(("$;99M?GD??(??/x0d??/a:???;a"+'?'/4)
??($??)+'?'/3-2-1+$%2)??''?')):'?';??>
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
017
08.01.2009, 21:26 Uhr
0xdeadbeef
Gott
(Operator)


Im Hinblick auf mögliche größere Brettgrößen würde ich mir allerdings schon eine Liste noch verwendbarer y-Koordinaten vorhalten, um die Anzahl der zu behandelnden Fälle von n^n auf n! zu reduzieren. Bei einer Brettgröße von 8 ist das wohl noch nicht wirklich notwendig, aber selbst da ist ein Unterschied von 40.320 gegenüber 16.777.216 Fällen schon spürbar. Bei einer Brettgröße von 9 sieht das schon anders aus.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra

Dieser Post wurde am 08.01.2009 um 21:26 Uhr von 0xdeadbeef editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
018
08.01.2009, 22:06 Uhr
FloSoft
Medialer Over-Flow
(Administrator)



Zitat von 0xdeadbeef:
Im Hinblick auf mögliche größere Brettgrößen würde ich mir allerdings schon eine Liste noch verwendbarer y-Koordinaten vorhalten, um die Anzahl der zu behandelnden Fälle von n^n auf n! zu reduzieren. Bei einer Brettgröße von 8 ist das wohl noch nicht wirklich notwendig, aber selbst da ist ein Unterschied von 40.320 gegenüber 16.777.216 Fällen schon spürbar. Bei einer Brettgröße von 9 sieht das schon anders aus.

wenn man überlegt das NQueens@Home erst bei Feldgröße 26 ist aber gut, die suchen auch ALLE möglichen lösungen, nicht nur eine
--
class God : public ChuckNorris { };

Dieser Post wurde am 08.01.2009 um 22:06 Uhr von FloSoft editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
019
08.01.2009, 23:01 Uhr
0xdeadbeef
Gott
(Operator)


Naja, fakultatives Wachstum ist nicht zu unterschätzen. Bei einer Brettgröße von 8 ist aber auch das Suchen aller möglichen Lösungen in sehr kurzer Zeit machbar. Ab etwa Brettgröße 14 kannst du vor einem Heimcomputer aber schon eine Weile sitzen.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 < [ 3 ]     [ C / C++ (ANSI-Standard) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: