Ktorá metóda je rýchlejšia pre testovanie možných ťahov na šachovnici?

Postav to na OOP a dedicnosti. Pak kazda figurka bude vedet, kam a jestli muze tahnout.
Jen provedes:
if Figurka.TahniNa('B6') then ...

Bude ti jdno, jestli to bude kral nebo strelec. Figurka si osetri, jestli tam muze jit a pokud dojde k sebrani souperovy figurky, muze vyvolat nejakou udalost.

Dobre, tak sa o tom rozpíšem viac.

Ak napíšem toto, tak za každú figúrku budem musieť prejsť celú šachovnicu a teda ak na šachovnici bude povedzme 35 ťahov pre danú stranu, tak prejdem šachovnicu toľkokrát, koľko mám figúrok a dostanem 35 ťahov. Ak by som to postavil na testovaní podľa figúrok a priamo ich možné ťahy, tak prejdem vybrané miesta na šachovnici toľkokrát, koľko je figúrok. Zdanlivo je to rýchlejšie, ale pri tomto musím testovať priamo vhodné polia a niekde vyexportovať možné ťahy. To by nebol problém, akurát, že musím vedieť koľko ťahov je maximum, čiže nevýhoda. Nespomalí mi teda prebehnutie celej šachovnice toľkokrát koľko je figúrok program?

Ted jsem trochu na rozpacich...
Chces zkontrolovat tah figurky nebo hledat optimalni tah pocitace ?

Hľadať optimálny ťah počítača metódou Minimax, Alfa Beta a podobne, aby to zabralo čo najmenej strojového času. Dokonca myslím, v tom prípade môžem na OOP kompletne zabudnúť, pretože OOP je ďalší slimáks káblovou televíziou a širokopásmovým Internetom v ulite.

Pak bude asi nerychlejsi, kdyz si po kazdem tahu figurky vybudujes seznam poli, na ktera muze tahnout. Pak budes prochazet pouze seznam poli, ktera pripadaji v uvahu. Rychleji to asi nepujde...

Dobre a teraz ohľadne jazdca (v prípade veže to nie je až tak nutné) mám dať mantinel a nekontrolovať, či je rozmer mimo šachovnice alebo otestovať rozmer a potom, či je ťah možný? Osobne si myslím, že test s kontrolou je rýchlejší. Toto je vlastne otázka, ktorú som položil na začiatku.

OMG ved pise ze najrychlejsie je ak si pred testovanim tahov vytvoris nejake pole v ktorom budu mozne cielove policka danej figurky. Tie sa daju urobit jednoducho pre kazdu figurku (pre kazdu osobitny algoritmus).
Zavisi co presne potrebujes mat rychle.

Dilemovat ze ci urobit if(x>8) alebo if(dx==dy) je uplne nepodstatne, su casovo rovnocenne.

P.S. "mantinel" z figurok je nezmysel, kon by ti to mohol preskocit. Celkovo na to ides nejako moc divne.

P.S.2. nemusi to byt ani pole moznych tahov v RAM, staci ak to budes robit v cykle pre kazdu figurku tahy. Napr.
testuj_tahy()
{
for(x=0; x<8; x++)
for(y=0; y<8; y++)
switch(sachovnica[x,y])
{
case VEZA:
tu si v cykle vytvoris mozne tahy veze z x,y
a zavolas OhodnotTah(novex, novey)
apod.
}
}

... este k tomu vytvaraniu tahov, u veze budes zvysovat/znizovat x alebo y, podla nejakej stavovej premennej (ze ktorym smerom s vezou prave tahas). Testovat mantinel asi najlepsie pri tom zvysovani/znizovani x alebo y, napr.
if(++x > 8) break
apod.
Jedno if je uplne nepodstatne, mantinel z figurok by bol blbost ptz. musis testovat aj tah na figurku (vyhodenie figurky), takze by si testoval aj tah mimo sachovnicu

Presne rovnako uvažujem aj ja. Len mi ide o to, čo je rýchlejšie.

No a na toto potrebujem vedieť, ktorá metóda je rýchlejšia. Už rozumieš?

Jaka metoda?
Ved pisem ze hranice sachovnice musis testovat tak ci tak, vytvorit mur z figuriek "mimo" sachovnice sa neda, ptz. a)na kona by to neplatilo a b)musis testovat aj tahy na pole kde je figurka (kvoli vyhodeniu tej figurky), a teda testoval by si aj ten "mur" figurieek. T.j. je len jedna metoda.
Inac cela ta logika pohybu a testovania tahov figurok je tak zlozita, ze toto na co sa pytas je uplne nepodstatne, jedno jednoduche if ti rychlost nijak neovplyvni.
Alebo nechapem na co sa pytas...

P.S. Ak testujes len vsetky svoje tahy tak ti mantinel je mozno vyhodnejsi, ale to ti zvladne dnesny CPU za miliontinu sekundy, problem s rychlostou nastane az akonahle zacnes testovat aj vsetky mozne superove dalsie tahy atd. a to potom chcem vidiet ako ti pomoze mantinel z tvojich figurok na superove tahy...
Metoda 1. je normalna, logicka, a da sa napisat aj optimalne (ale nie v delphi ktore ti strka do kodu testy indexu pri kazdom pristupe k polu, a teraz mas dilemu s jednym if, akych delphi nastrka do kodu milion).

Mantinel bol jednou vetou spomenutý na jednej stránke (neviem teraz adresu, niekde mi to Google našiel). Farba hráča by bola uložená ako nastavený bit v hodnote poľa šachovnice. Biely by dostal 7, bit, čierny 6. a mantinel je hotový. Lenže počítať rozmer poľa je podľa mňa pomalšie ako priamo otestovať na hodnotu mimo šachovnice. Ide o to, že pri testovaní do hĺbky väčšieho množstva ťahov to môže o niečo urýchliť "rozmýšľanie".

if su len 2instrukcie CPU, delphi ti takych napcha do kodu kopec. Pre kazdy tah mas tam omnoho viac narocnejsich operacii ako jedno if. Ak ide o rychlost treba to brat komplexne a optimalizovat to ako celok (vcetne algoritmu). Zalozit optimalizaciu na 3hodinovom rozmyslani o jednom if je pre mna dost divne, navyse ak vobec spominas delphi.
To if ktore je len porovnanie registra, a bude maximalne vykonane 8x oproti jednemu pristupu na "mantinel" - a to mas prepocet adresy do pola, pristup k pamati, testovanie ci to je figurka hraca (tu dost zavisi ako konkretne ten test napises), plus zabera nieco to vacsie pole (pre vnorene tahy to znamena vytvaranie kopie vacsieho pola v pamati), atd. Nakoniec to vyjde mozno plusminus nastejno. Je omnoho dolezitejsie ako konkretne to napises a v com to budes robit, ako jedno if. Ak by si isiel do extremnej optimalizacie tak by malo vyznam aj jedno if, ale u extremnej opimalizacie nema co hladat ani pristup do pola cez pole[x,y] ale namiesto toho efektivne pouzivany smernik alebo rovno to napisat v assembleri

Ja te nechapu. Kdyz tahnu fugirkou, tak si po dokonceni tahu vytvorim novy seznam poli, kam muze figurka tahnout. Zrovna tak si vytvorim novy seznam pol pro figurky, ktere svym tahem ovlivnila.
Pri vyhodnocovani projdes pole moznych tahu bez jakehokoliv testovani.

Pokud chces hledat opravdu tah za pocitac, potrebujes si nastudovat teorii her a budes muset kazde pole ohodnotit z pohledu vsech figur - to znamena nekolikere prochazeni.

On ma dilemu prave pri tom vytvarani "pola moznych tahov", ze ci ma pri teste (ci je tah mozny) testovat okraje sachovnice, alebo len mantinel z figurok (tah na vlastnu figurku nie je mozny) a netestovat okraje sachovnice.

Už dilemu nemám. Mantinel prehral, zdal sa mi pomalší, takže to vyhráva if. Tiež som uvažoval o tom, že pri mantinely je zbytočné počítanie adresy pola, kontrola obsahu a podobne a if to urýchli. Pre Jazdca bude teda if a ostatné figúrky nepotrebujú mantinel.

ostatne figurky nepotrebuju mantinel ?

Nie, lebo testovať budem postupne po koniec šachovnice, ale pri jazdcovi sa testujú priamo polia, kam môže ísť, keďže on figúrky preskakuje. Tak to bolo myslené.

A myslis ze ak testujes "po koniec sachovnice", ze tam nie je test (if) na hranice sachovnice? Co robi "for" pri kazdom prechode cyklom?

Naštudovanú teóriu ťahu počítača v šachu už mám približne natoľko, že sa do toho môžem pustiť. Možno nejaké úpravy algoritmu nechám okomentovať poradňou. Ide o hlavne o rýchlosť a tiež aj jednoduchosť (aby som nemusel určité veci písať 2x, keď to netreba.

Abys urcite veci nemusel pocitat 2 a vicekrat a abys to mohl jednoduse pouzivat, tak presne k tomu slouzi tebou odsuzovane OOP.

Ja by som ho použil, ale sa bojím, že pri použití OOP bude počítač rozmýšľať 10 sekúnd a bez neho 3 sekundy. Je to tak alebo sa mýlim?

Nechapu, jaky by k tomu mel duvod.
Rychlost zalezi na tom, jak kvalitne napises kod, ne jestli pouzijes nebo nepouzijes OOP.

Pokud OOP nepouzijes, budes mit program plny podminek, kde se budes rozbocovat podle druhu figurky.

Predstav si ze to udelas nejak takto:
Udelas tridu figura, nadefinujes ji vlastnosti a metody, jako mozne tahy, barva, jmeno, ...
Od ni odvodis jednotlive figurky, prepises jim metodu pro tah. Jmeno nastavis v jejim konstruktoru.

Pak si vzpomenes, ze potrebujes ke vsem figurkam pridat jejich vahu. V OOP to pridas predkovi a v constructoru nastavis.
V proceduralnim programovani to znamena upravy parametru funkci a zmeny na spouste mist.

To znie je zlé. O OOP uvažujem, ale z hľadiska zjednodušenia. Pohyb by som vedel jednoducho riešiť aj bez OOP a to tak, že každý pohyb bude mať bitovú váhu:

Bity:
0-pešiak
1-jazdec
2-strelec
3-veža
4- kráľ
5-biely
6-čierny (dá sa aj zrušiť v prípade, že nemám (a ja nedám) mantinel)
7-pre vlastnú potrebu (možno využijem, možno nie)

Dáma nie je potrebná, tá bude mať nastavené bity 2 a 3, čiže figúrky budú:
1-pešiak
2-jazdec
4-strelec
8-veža
12-dáma

Pohyb figúrok je takto nezávislý od metódy, pretože metóda ani nespozná, či má vežu alebo dámu. Akurát sa pohyb rozvetví pri dáme aj pri podmienke na strelca.

No, doufam, ze ten sachovy program pak uvolnis jako Freeware. Bez OOP se v tomhle moc nechytnes, propripade se zachvili ztratis ve svem vlastnim zdrojaku.

No vlastne aj OOP sa dá s týmto skombinovať. Urobím vlastne objekt figúrka a priradím im "hodnosť" a ťahy sa budú hľadať podľa hodnosti. Osobne sa mi moc nevidí robiť povedzme dámu ako potomka strelca a čo potom v vežou. Multidedičnosť v Delphi nie je? Myslím, že nie, ale aj tak neviem ako by som dokázal multidedičnosť skombinovať. Okrem toho Pešiak sa môže zmeniť na dámu a tým by som musel zrušiť objekt a vytvoriť nový, takto univerzálnemu objektu zmením vlastnosť. No a poprosím konštruktívnu kritiku, ako by to bolo ešte lepšie.

Proc bys delal takove silenosti typu Dama potomek Strelce?
Dama je jako ostatni potomek tridy Figura

To bolo len tak akože. Mne sa skôr najlepšie vidí varianta, kde figúrke nastavím vlastnosť, ktorá bude znamenať jej hodnosť. Čiže objekt figúrky a vlastnosť hodnosti. Je to jednoduchšie naprogramovateľné a pešiak sa pri dosiahnutí poslednej pozície len zmení a nemusí sa vytvárať nový objekt. Alebo tento nápad je nevhodný?

Pridani property do objektu ti neovlivni zbytek programu.
Pridani property do predka = property je dostupna ve vsech potomcich.
Pridani parametru do procedury znamena opravovani na hodne mistech.

Objekt figúrky by mal danú vlastnosť. Figúrka by bol univerzálny objekt. Niečo ako TBitBtn s vlastnosťou Kind.

Videl bych to tak (laicky):

Trida Figura - ta by obsahovala mimojine atribut zda je dana figura cerna nebo bila.
Tridy Pesec, Vez, Jezdec, Dama, Kral, Strelec - potomci tridy figura, navic atributy ohodnote figury.

Pokud jde o promenu pesce, tak tam bych to resil asi tak, ze kdyz by dany objekt presec zanikl (dorazil na posledni radu), tak by se vytvorila nova instance tridy nektere figurky na miste pesce.

No pak by asi byly jeste treba tridy Sachovinice a Policko, pak nejaka trida Engine, kde by byla ulozena sachova logika.

Triedu policko by som radsej vynechal, nech to nerata jeden tah pol minuty.. Sachovnica by mala mat IMHO nejako optimalne ulozene udaje, pole tried a podobne orangutany nepovazujem za optimalne.

Aniž bych pozorně četl tuto diskuzi, házím sem odkaz

chess

který by se možná msx. hodil.

Zdrojáky KC Chess ve čtivém Pascalu, dobře okomentované...

Vyzerá to dobre, ďakujem za link. Ale prekvapilo ma, že keď som začal hrať, dostal som sa k možnosti brania mimochodom. Hra mi to umožnila, ale čierny pešiak ostal (či len opticky alebo fyzicky, to netuším).