Ho deciso di provare a scrivere un programma che giochi a scacchi. Per
quanto riguarda la "documentazione" non ci sono molti problemi: ho trovato
parecchio sulla rete. Vorrei pero' un consiglio sul linguaggio di
programmazione da usare: C (con cui so scrivere _solo_ per DOS) o
VisualBasic 5.0 ???
Grazie e ciao.
--
Stefano Costa
^^^^^^^^^^^^^
sco...@enjoy.it
cos...@odino.unipv.it
Caro Stefano,
...vuoi fare una cosa davvero ardua! In effetti pensavo a questo problema
tempo fa, durante un viaggio in treno, e sono giunto ad una conclusione molto
interessante. Se il motore del programma, ovvero la logica che prende le
decisioni e che gioca, lo implemento a modo mio, il risultato e' un programma
che gioca come me, quindi una buona chiavica! Utilizzando una logica, diciamo,
"ufficiale", ovvero algoritmi piu' o meno standard, su cui si possono effettuare
vari gradi di rifinitura, beh... il risultato e' sicuramente migliore.
Come linguaggio, il 'C' ti offre la massima flessibilita' per la gestione
della memoria, nonche' la massima velocita'. Visto che un programma di scacchi
opera con una marea di dati, dinamicamente variabili, piu' vicino sei al
hardware e meglio e'. Non ho benchmark sul Visual Basic, pero' un amico che usa
entrambi mi dice che VB e' piu' lento. Potrei consigliarti di imparare (fattelo
spiegare da qualcuno!) a creare un frame con il VC++ e magari per adesso butta
giu' il nucleo del programma. A rifinirlo esteticamente ci sei sempre...
In libreria c'e' un libro edizioni Mursia, "I giocatoli artificiali", che
seppur datato, offre delle dritte su come implementare dei semplici motori.
Ciao,
Julian//
A partire dalla versione 5 Visual Basic e' in grado di compilare in codice
nativo e ,se non sbaglio, usa proprio lo stesso compilatore e linker del
'fratello' Visual C++. Questo ha aumentato non poco la velocità di VB per quanto
riguarda il calcolo puro ma, ahime', non e' ancora ai livelli di altri
linguaggi piu' a basso livello (scusa il bisticcio di parole).
Personalmente e' da molto che cerco il tempo per provare a portare in VB uno dei
tanti motori freeware che si trovano completi di sorgenti (il mio candidato
attuale e' Faile 0.6, i cui source sono compatti e chiari anche per chi
mastica solo database e gestionali come me); purtroppo non sono ancora partito
per cui non posso darti nessun termine di paragone; se pero' hai dimestichezza
con entrambi i linguaggi potresti isolare le funzioni di ricerca e valutazione
in una dll scritta in C (la tua conoscenza "solo DOS" dovrebbe comunque darti
modo di cavartela) e il resto in VB.
Ciao.
--
o o
o / \ / \ o Luca Dormio
\ - - / ldo...@tin.it (real email address)
=====
Chess.net ID: Luca_b3
FICS ID: LarsenB
Grazie,
Vedo che di cose ne sono saltate fuori. Io a questo punto avrei una
proposta, spero, interessante da fare: perche' non scriviamo *insieme* un
programma che giochi a scacchi?
Io non so scrivere in C++, quindi niente Borland Builder, ma c'e' chi lo sa
fare. Altri hanno gia' fatto qualcosa per quanto riguarda la grafica.
Potremmo suddividerci i compiti, rispettando gli impegni di studio e/o
lavoro di ciascuno, in modo da potrare avanti il tutto assieme. Mettendo
assieme le idee potrebbe venire fuori anche qualcosa di buono.
Fatevi sentire. Ciao,
Salve, mi chiamo Emanuele.
Io ho scritto un paio d'anni fà un programma di scacchi (il linguaggio che
ho usato è il Borland Pascal 7.0 in modalità protetta, appunto per
scavalcare i fatidici 640K), ora stò cercando di migliorarlo. Se vuoi
possiamo scambiare due idee.
Ciao.
> Grazie per i consigli. Il difetto maggiore dello scrivere sotto DOS e' il
> limite dei 640K.
> Provero' comunque a scrivere delle DLL in C e ad utilizzarle con il VB5
> (che come avete detto e' molto piu' veloce delle versioni precedenti: del
> 200% sulle funzioni matematiche...), anche se ritengo che un utilizzo
> corretto degli algoritmi di ricerca e valutazione delle posizioni possa in
> qualche modo non far rimpiangere troppo il C o l'ASM.
> A questo proposito ho pensato (!) ad un paio di funzioni (per la ricerca e
> la valutazione) che mi sembrano "inedite" da quello che ho potuto vedere in
> giro per i siti dei programmatori. Potete farmi sapere se c'e' qualcuno nel
> NG che si diverte a programmare ed interessato a verificare con me queste
> idee?
>
> Grazie,
Stefano... e ciao anche ad Emanuele,
onestamente con 640Kb (realmente diciamo 600 o poco meno) si possono fare
cose da pazzi!! Nel senso che l'algoritmo che calcola le mosse ... e' piccolo...
quello che potrebbe "fottere" un bel po' di memoria e' il libro d'apertura e le
tabelle di trasposizione... ma queste cose non si caricano in RAM... bensi' si
indicizzano per benino sul disco in modo da poterli ampliare a dismisura.
Gli altri blocchi di logica (come li chiamo io....) sono pure abbastanza
piccoli. Il mese scorso ho buttato giu' in Java un Viewer --ovvero un programma
che ti mostra una scacchiera ed offre cmd tipo mostra_pezzo( tipo, posizione )
oppure elimina_pezzo(...) e sposta_pezzo( da..a) -- una sorta di plug in visivo;
questo per avere l'indipendenza della scacchiera dalla 'logica di gioco'. Il
programma che gioca non riesco a finirlo (--veramente non riesco proprio a
cominciarlo x mancanza di risorsa_tempo_per_fare_un_prg_di_scacchi)...
Cmq, puoi contare su di me---anche come tuo beta-tester o anche scambiarci
informazioni e consigli... Per il VB... ti dico solo ARGG.. non ti limitare
cosi'... vai direttamente al visual C++ -- dove potresti anche cominciare a
scrivere l'applicativo come se fosse C standard selezionando dal wizard *create
console application* che in pratica e' un programma che _gira_ in una finestra
dos... Per la grafica, come ti dicevo, poi avresti tutto il tempo per imparare a
disegnare in un semplicissimo Frame. Poi col C rimani in sintonia con i tempi...
Le varianti del Basic che usano gli oggetti... beh... non aggiungo altro!
VisualBasic versus VisualC... quando si tratta di calcoli --e con gli
scacchi sono veramente tanti!-- la velocita' non basta mai/// quante volte ho
ripensato indietro dicendomi, tra me e me, ..>"Casso--potevo usare
l'assembler!!".......
...torno al lavoro,
byezzz,
Julian//
ciao,
Sono curiosissimo anche sull'applet java posso vederlo?
p.s. se poi voleste guadagnare dei soldi programmando, provate a fare un programma
di go, c'è una taglia di un milione di dollari , dicono che sia facilissimo, fare un
buon programma di go ^_^
ciao.
"Julian E. Spina" ha scritto:
> ..... [snip] ..... una volta avevo cominciato a disegnare in basic la
> scacchiera, e i pezzi, quando vidi nero muovere il pedone fuori dalla scacchiera
> andando verso il basso, piantai tutto ^_^ credo che lanciai un urlo gutturale, molto
> gutturale.
> (avevo disegnato i pezzi punto per punto ^_^)
>
...!!!!!!!!hahahhahahaha!!!!!!!!favoloso!!!!!!!!!!
..........il programmino java (che e' un JPanel... per trasformarlo in applet -mi pare
che lo sai- devo aggiungere uno/due righe di codice) stampa a video la scacchiera ed i
pezzi per ora sono le lettere T-D-A-etc... in effetti il metodo disegnaPezzi(tipo, x,y)
si puo' "estrarre" ed inserire il disegnaPezzi(tipo,x,y) che disegna i cerchietti (---la
prima versione di prova che ho fatto!!)...oppure inserire un
disegnaPezzi(...soliti_parametri) che valuta il par. tipo_pezzo e carica l'icona
apposita. In effetti.. ho scaricato i bitmap con tutti i pezzi Bianchi e Neri...ma mi
secca un po' doverli ritagliare a mano... senno' gestire la stampa di un bitmap sul
video grafico e' semplice in Java. L'interessante, dal punto di vista programmazione- e'
che la scacchiera (il Viewer) e' un pezzo indipendente che viene notificato dai
programmi applicativi del movimento dei pezzi... (tramite eventi);
...ummm... mi sa che lo mando in newsgroup pero' dovrei prima ripulirlo un po'---non so
manco a che punto l'ho lasciato...!!!
"manco" e' italiano?
byezzz,
Julian//
>A questo proposito ho pensato (!) ad un paio di funzioni (per la ricerca e
>la valutazione) che mi sembrano "inedite" da quello che ho potuto vedere in
>giro per i siti dei programmatori.
Io ho utilizzato l'algoritmo NEGASCOUT per la ricerca della mossa.
Sono arrivato alla conclusione che per migliorare la forza di gioco devo
perfezionare il "calcolo" della quiescenza.
Considero quiescente una mossa quando non dà scacco al re avversario, il Re
non è minacciato da un pezzo avversario, non mangia alcun pezzo avversario
e, nel caso fosse un pedone a muovere, non sia prossimo alla promozione.
Ordino le mosse analizzando per prime le mosse che mangiano l'ultimo pezzo
avversario mosso poi quelle che danno scacco al re e infine le prese (dalla
presa più grande a quella più piccola).
ummm..... veramente interessante come algoritmo... e in quanto a calcoli (o
meglio a numero di iterazioni) su che cifre stiamo ?
Quindi NEGASCOUT (...faro una ricerca come riesco a smaltire un po' di
lavoro...)... fa dei passi tipo:
[pseudocodice]
--Partendo da una posizione dei pezzi
--AnalizzaPosizione()
--Re minacciato ? Si-->(altro codice)
--Calcola_tutte_le_mosse a profondita' 1
--[ciclo] Trova_mossa_migliore..tra tutte quelle calcolate
----Prossima mossa = Promo_Pedone? Si-->(altro codice)
----Prossima mossa = Da scacco al Re avversario ? Si-->(altro codice)
----Prossima mossa = Puo' mangiare pezzo avversario ? Si-->(altro codice)
----Esegui qualche_sorta di valutazione e genera un valore indice
--[fine ciclo]
--Qual e' la mossa con indice migliore ?
--Fai quella.
....
Direi che qualcosa insieme potremmo farla... Il newsgroup mi sembra un buon
punto d'incontro...
Sarebbe favorevole secondo me... a parte fare il nostro buon codice e le ns
buone comunicazioni in testo... buttare giu' logica ;-> pero' che sia anche
disegnata (=in grafica) , in modo che se qualcuno entra in ng... puo' guardare
magari un diagramma -un blocco di logica- che valuta la posizione e dire....
cazzo.. ma io lo faccio meglio (o diverso) --- cosi' possiamo ottimizzarlo o
migliorarlo --tutti insieme--............... che ne dite?
In ogni caso in giro sulla rete si trova di tutto ed anche in
sorgente...quindi non c'e' niente che sia "il mio codice" o "il suo codice"...
gli algoritmi ci stanno (e sono per tutti)... mettiamoli qui OnLine
-discutiamone- chiediamo pareri autorevoli- e miglioriamoli se ci riusciamo...
Creaiamo un centro di documentazione *pubblico* dove discutiamo, sviluppiamo, e
non solo in testo (ovvero anche con un po' di grafica...).
Io programmo in assembler ed al momento scrivo in Java, mettiamoci daccordo
--- qualche giorno per trovare dei punti in comune ci servono pure---
prepariamoci un po' di materiale -- anche semplici idee fanno da materiale -- ed
(io personalmente) per settimana entrante sono anche disposto a cominciare
attivamente_
Oak?
Julian
> Emanuele wrote:
>
> > Stefano Costa ha scritto nel messaggio
> > <01bea091$e7ab0700$319078c3@default>...
> >
> > >A questo proposito ho pensato (!) ad un paio di funzioni (per la ricerca e
> > >la valutazione) che mi sembrano "inedite" da quello che ho potuto vedere in
> > >giro per i siti dei programmatori.
> >
.......scriviamo la logica su "carta" ed organizziamoci... o'.... dammi qualche
dritta per trovare qualcosa di pronto online... anche se una buona ricerca la voglio
c(o)m(un)q(ue) fare... Facciamogli vedere che sappiamo fare da queste parti.........
;------)
Julian//
P.S.
le funzioni che dici, xche' non le commenti e le cataloghi come documentazione? Con
il contributo di tutti... potremmo fare Italian_Chess 1.0 ...
> Grazie per i consigli. Il difetto maggiore dello scrivere sotto DOS e' il
> limite dei 640K.
> Provero' comunque a scrivere delle DLL in C e ad utilizzarle con il VB5
> (che come avete detto e' molto piu' veloce delle versioni precedenti: del
> 200% sulle funzioni matematiche...), anche se ritengo che un utilizzo
> corretto degli algoritmi di ricerca e valutazione delle posizioni possa in
> qualche modo non far rimpiangere troppo il C o l'ASM.
> A questo proposito ho pensato (!) ad un paio di funzioni (per la ricerca e
> la valutazione) che mi sembrano "inedite" da quello che ho potuto vedere in
> giro per i siti dei programmatori. Potete farmi sapere se c'e' qualcuno nel
> NG che si diverte a programmare ed interessato a verificare con me queste
> idee?
Io ho già scritto un programma per giocare a scacchi (e anche uno per giocare a
dama ed uno per giocare a bridge), anche se non l'ho completato in funzione del
gioco di partita, concentrandomi invece sui problemi di matto e sulla generazione
di database di finali (ci vogliono altro che 640 kb per generare i file!).
L'interesse da cui ero partito era quello di vedere quanti livelli di mosse
potevano essere esaminati completamente, ricorrendo solo a criteri matematici e
non scacchistici di esclusione delle mosse, e quindi ho sviluppato moltissimi
trucchi per ottimizzare il codice rispetto alla velocità.
Per scrivere i programmi ho utilizzato il linguaggio C (compilatore gcc e g++)
sotto Linux (per chi non lo conosce è un clone freeware di Unix) che è molto più
veloce in esecuzione di altri compilatori e non presenta problemi per utilizzare
l'intera memoria centrale (vi è anche la memoria virtuale, ma non è il caso).
Non ho verificato se l'uso dell'assembler limitato alle subroutine più frequenti,
migliori la velocità rispetto al C ottimizzato. Se fai qualche tentativo in
questo senso ti suggerisco di utilizzare al massimo i registri al posto delle
variabili locali. Infatti ho avuto un miglioramento del 10 % da un'opzione di
compilazione in C (-fomit-frame-pointer) che aggiungeva una variabile "register"
in più a quelle normalmente usate.
Sono comunque molto interessato a scambiare idee e suggerimenti e anche a
partecipare per sviluppare un programma comune.
Ciao, Guido
--
Posted from mta4.iol.it [195.210.91.154]
via Mailgate.ORG Server - http://www.mailgate.org
> > Stefano Costa ha scritto:
> > Provero' comunque a scrivere delle DLL in C ........[cut]..........
> .......Potete farmi sapere se c'e' qualcuno nel
> > NG che si diverte a programmare ed interessato a verificare con me queste
> > idee?
...io mi diverto un mondo (notturno!) a programmare...
> ......[cut]..........
> Non ho verificato se l'uso dell'assembler limitato alle subroutine più frequenti,
> migliori la velocità rispetto al C ottimizzato. Se fai qualche tentativo in
> questo senso ti suggerisco di utilizzare al massimo i registri al posto delle
> variabili locali. Infatti ho avuto un miglioramento del 10 % da un'opzione di
> compilazione in C (-fomit-frame-pointer) che aggiungeva una variabile "register"
> in più a quelle normalmente usate.
>
Usare un registro per contenere un intero anziche' una locazione di RAM e'
sicuramente efficiente.
Avviene cosi':
- quando il programma parte... abbiamo (supponiamo) 1000 interi che usiamo per i
nostri (diabolici!) scopi;
- le 1000 var. sono tutte allocate in RAM
- nel momento in cui si arriva ad un pezzo di codice C dove la variabile e'
dichiarata "register", l'accesso alla var. non avviene piu' in RAM
- quindi la var. viene spostata in un registro (dove pero' non puo' stare per
molto--- i registri servono anche al processore!)
---- piu' sono le operazioni sulla var. e meglio e' (nota: il registro e' fisicamente
nella CPU... se era in RAM il processore doveva richiederne il
valore al MMU (un circuito) spendendo molto (ma molto..) piu' tempo)
- fine operazioni... la var. e' rispostata in RAM
>
> Sono comunque molto interessato a scambiare idee e suggerimenti e anche a
> partecipare per sviluppare un programma comune.
>
sei dei nostri...
>
> Ciao, Guido
>
> --
> Posted from mta4.iol.it [195.210.91.154]
> via Mailgate.ORG Server - http://www.mailgate.org
...buono... ti aggiungo alla lista...mi sembri in gamba!
usando il calcolo combinatorio "puro" per le posizioni, negli scacchi, e' un po' come
un hackeraggio con la tecnica "brute force"---ovvero... le provo tutte con ... la
forza bruta!!.. il bello degli scacchi che possiamo giocare molto con la logica
---riducendo di molto i calcoli... aumentando pero' la complessita'...
Il Gromit ad esempio costantemente esegue un calcolo sulla posizione attuale dei
pezzi, che inizialmente e' uguale a zero per entrambi, Bianco e Nero. Ad ogni mossa
ricalcola dei parametri che si basano su bonus positivi e negativi, avendo
all'interno una tabella di meriti, demeriti come segue...
- Bonus, Torre che inchioda un pezzo (che e' a difesa del Re) +11
- Bonus, due Torri attaccano su colonna aperta +10
- Bonus, due Torri attaccano su colonna h +10
- Bonus, Torre su colonna che sta per aprirsi +6
-...
- Bonus, Re guadagna opposizione in finale +4
-...
- Bonus, e' possibile arrocco lato Donna +7
- Bonus, e' possibile arrocco lato Re +12
-...
- Penalita', casella vuota avanti al Re -4
- Penalita', pezzo nemico avanti al Re -13
- Penalita', pedone su e2/d2 e' bloccato -18
Mi sembra uno strumento (questo dei bonus +/-) valido.
...Pero'... ricordati che non sono gli algoritmi che occupano RAM... ma i dati... Un
database di finali diciamo di 300MB non sta in RAM! Anche se io dico sempre....
"scriviamolo il programma, ad ottimizzarlo ci siamo sempre"
Julian//
Tra i suggerimenti che ti sono arrivati, ti mando anche il mio :)
Il miglior lavoro che tu possa fare (a mio modesto parere) a livello di
prestazioni e portabilita` lo ottieni in ANSI C/C++ con compilatore Gcc (Cygnus)
sotto Windows (o il buon vecchio DJGPP sotto DOS, sempre a 32 bit) o sotto UNIX.
Per non sbatterti troppo sull'interfaccia puoi appoggiarti senza problemi a
Winboard/Xboard come fanno gran parte degli altri programmatori.
Il fatto che sia portabile e`, secondo me, molto importante per la diffusione
del programma ma, in primo luogo, per il test ... hai piu` persone che possono
usarlo e testarlo.
Buon lavoro!
Regards,
Blade Spammer
----------------------------------------------
AntiSpam Net-Runner Unit
" I've seen SPAMs you people wouldn't believe.
Time to shutdown. "
----------------------------------------------
Real E-Mail <iw6dgm@REMOVE_NOSPAM_16278.freemail.it>
--
Posted from ro...@ascu.unian.it [193.205.128.30]
Ti ringrazio della spiegazione, ma avendo in passato programmato in Assembler la cosa mi
era perfettamente nota tanto che avevo cercato l'opzione -fomit-frame-pointer tra un
centinaio di altre opzioni che non servivano allo scopo. Io intendevo dire che i
compilatori C e C++ attuali sono talmente efficienti, soprattutto se spinti alla massima
ottimizzazione, che l'utilizzo dell'Assembler, suggerito da qualcuno, non dà praticamente
vantaggi, salvo forse per il motivo accennato.
> sei dei nostri...
>
Ti ringrazio e spero di essere utile.
> usando il calcolo combinatorio "puro" per le posizioni, negli scacchi, e' un po' come
> un hackeraggio con la tecnica "brute force"---ovvero... le provo tutte con ... la
> forza bruta!!.. il bello degli scacchi che possiamo giocare molto con la logica
> ---riducendo di molto i calcoli... aumentando pero' la complessita'...
>
> Il Gromit ad esempio costantemente esegue un calcolo sulla posizione attuale dei
> pezzi, che inizialmente e' uguale a zero per entrambi, Bianco e Nero. Ad ogni mossa
> ricalcola dei parametri che si basano su bonus positivi e negativi, avendo
> all'interno una tabella di meriti, demeriti come segue...
>
> - Bonus, Torre che inchioda un pezzo (che e' a difesa del Re) +11
> -...
> -...
> - Penalita', pedone su e2/d2 e' bloccato -18
>
> Mi sembra uno strumento (questo dei bonus +/-) valido.
Anch'io ero giunto alla conclusione che si riducono i casi da analizzare, se si esaminano
le mosse di ciascun giocatore seguendo l'ordine a bontà decrescente della mossa e quindi
lo strumento bonus è certamente utile purché non abbia un costo eccessivo in termini di
tempo. Il limite massimo di riduzione, senza scartare alcuna alternativa con criteri
scacchistici, dovrebbe essere pari all'incirca alla radice quadrata del numero delle
combinazioni brute.
> ...Pero'... ricordati che non sono gli algoritmi che occupano RAM... ma i
> dati... Un database di finali diciamo di 300MB non sta in RAM!
> Anche se io dico sempre....
> "scriviamolo il programma, ad ottimizzarlo ci siamo sempre"
Concordo con te che gli algoritmi occupano poco spazio anche se è conveniente usare molte
tabelle per aumentare le prestazioni, ma queste occupano kb non Mb.
Riguardo invece al problema dei database non sono d'accordo: sia la generazione dei
database che il loro utilizzo richiedono in certi momenti il loro caricamento in memoria,
pena una crescita inaccettabile dei tempi di esecuzione che praticamente renderebbe
impossibile la soluzione del problema. L'unico caso in cui non è necessario tenere in
memoria il database è quando la partita è entrata nel finale e quindi si deve effettuare
una sola lettura da disco per trovare la mossa giusta.
Ma quando si ha qualche pezzo in più rispetto al finale e si devono analizzare le
possibili mosse entrando molte volte nel database?
Se il progetto procede avremo modo di discutere questo problema e spero di essermi
sbagliato.
Ciao, Guido
--
Posted from mta4.iol.it [195.210.91.154]
> Buon lavoro!
..............[cut]..................
Blade, conto sulla tua esperienza e sul tuo contributo (in qualsiasi forma anche
non esplicita!) per il neo-progetto. Ci 6?
Il nuovo thread comincia piu' giu' "Un programma per gli scacchi: parte II". E'
l'inizio ufficiale.
Fase 1. Chi siamo a partecipare.
Fase 2. Come ci distribuiamo.
Fase 3. Ci sincronizziamo.
Fase 4. Sviluppiamo.
..........
Fase x. Pacchetto che distrugge il Rebel! (*joke*)
byezzz,
Julian//
Ci sono, ci sono. Io metto l'esperienza acquisita su piattaforme UNIX affinche`
si possa creare un programma multipiattaforma. Inoltre, per UNIX sono
disponibili tantissimi sorgenti di programmi di scacchi da qui trarre spunti
interessanti (ex. algoritmo di gestione delle tavole dei finali di Nalimov).
Paolo Buratti stava lavorando alla creazione di un database per partite di
scacchi dal formato alternativo a quello (proprietario e non free) della
ChessBase; sarebbe interessante tenerlo a mente per la gestione di database
d'apertura e libri di partite in generale.
Regards,
Blade Spammer
----------------------------------------------
AntiSpam Net-Runner Unit
" I've seen SPAMs you people wouldn't believe.
Time to shutdown. "
----------------------------------------------
Real E-Mail <iw6dgm ( at ) freemail.it>
--
Posted from ro...@ascu.unian.it [193.205.128.30]